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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Chuck,

On Tue, Jan 10, 2017 at 5:02 PM, Chuck Lever <[e-mail]> wrote:

>
> > 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.


I had forgotten that detail. Thanks for the wake-up call!


> 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.
>

I'm thinking the guy who's missing something is me ;-)

I think we're good to go on this document.

Spencer (S), would you agree?

Spencer (D)