Re: [nfsv4] AD Evaluation for draft-ietf-nfsv4-rpcrdma-bidirection-05

[Chuck Lever <[e-mail]>]

> On Jan 10, 2017, at 5:13 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Chuck,
> 
> On Tue, Jan 10, 2017 at 3:47 PM, Chuck Lever <[e-mail]> wrote:
> Again, thanks for your review! Responses below.
> 
> Oh, thank YOU. You responded while I still have this draft in my solid state memory :-) ...
> 
> It looks like we're good except for the last point.
>  
> > On Jan 10, 2017, at 4:32 PM, Spencer Dawkins at IETF <[e-mail]> wrote:

[ snipped ]

> > In this text,
> >
> >    When message direction is not fully determined by context (e.g.,
> >    suggested by the definition of the RPC-over-RDMA version that is in
> >    use) or by an accompanying RPC message payload with a call direction
> >    field, it is not possible for the receiver to tell with certainty
> >    whether the header credit value is a request or grant.  In such
> >    cases, the receiver MUST NOT use the header's credit value.
> >
> > does RDMA work at all, if the credit value can't be used?
> 
> What this means is the receiver MUST NOT update its credit accounting
> based on the information in this header. These foggy situations should
> be exceptionally rare.
> 
> "MUST ignore" might be more appropriate.
> 
> I think what I was thinking about, is whether this situation can lead to deadlock.

The credit grant value has to be ignored whenever the forward and backward
grants are not the same value (which is typical in current implementations).

With the current set of protocols, the only case like this is RDMA_ERROR,
which is almost never used. Ignoring the credit value for those messages
doesn't seem problematic.

If the backward credit grant (which is likely to be smaller) is suddenly
used in the forward direction, for that one message, the forward requester
would wait for any outstanding replies before sending more requests. The
next message from the responder would restore the forward credit grant to
its correct value.

I don't think a deadlock could occur unless the grant value went to zero,
and that is already forbidden by rfc5666bis.

Another way to address this I suppose would be to ensure the grant values
in both directions are always the same.


> I guess I should back up and ask a more basic question, which is whether you'd be able to recognize that this situation applies from looking at the definition of the RPC-over-RDMA version, so you could just say "I'm not going to do bidirectional" when a transport connection is established, rather than trying to figure out that there's a problem during request processing.

An implementer would be able to tell where these corner cases are, since
her implementation has to ignore the credit value in those cases. But
maybe I'm missing something.


--
Chuck Lever