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 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:
> >
> > Hi, Spencer (S),
> >
> > I think this catches me up on nfsv4 AD Evaluations ...
> >
> > Again, this draft was pretty clear to me, but I did have some questions
> about wording, that I'd like people to look at, before requesting IETF Last
> Call.
> >
> > Spencer (S), could you let me know when this draft is good to go?
> >
> > Thanks!
> >
> > Spencer (D)
> >
> > --- AD Evaluation
> >
> > Could you spell out "Parallel NFS" on first use of pNFS? Or whatever
> pNFS stands for :-)
>
> Will do.
>
>
> > Probably just for my benefit, but since you mention NAT routers in this
> text,
> >
> >    To facilitate operation through NAT routers, all NFSv4.1 transport
> >    connections are initiated by NFSv4.1 clients.  Therefore NFSv4.1
> >    servers send callbacks to clients in the backward direction on
> >    connections established by NFSv4.1 clients.
> >
> > is it obvious which end has responsibility for NAT binding keep-alives?
> I'm guessing that's a client responsibility, but that's just a guess.
>
> I don't understand what NAT binding keep-alive means, exactly, but
> based on a naive assumption, I think the client is responsible here.
> If anyone knows of a cite-able summary of the NFSv4.1 backchannel
> redesign goals, I can reference it here.
>
>
> > In Sections 4.3.1 and 4.3.2, I THINK you're saying that clients and
> servers both need to pre-post more receive buffers to accommodate
> bidirectional operation, but that's more clear in 4.3.1,
> >
> >    To receive incoming backward direction Calls, an RPC-over-RDMA client
> >    endpoint must pre-post enough additional receive buffers to match its
> >    advertised backward direction credit value.  Each outstanding forward
> >    direction RPC requires an additional receive buffer above this
> >    minimum.
> >
> > than the corresponding text in 4.3.2,
> >
> >    To receive incoming backward direction replies, an RPC-over-RDMA
> >    server endpoint must pre-post a receive buffer for each backward
> >    direction Call it sends.
> >
> > because "additional" appears twice in the text on 4.3.1, but doesn't
> appear at all in 4.3.2. If this is as symmetrical as I'm thinking it is,
> perhaps it's clearer to use similar wording in both places.
>
> I will use similar wording in both places.
>
>
> > 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.

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.

Thanks,

Spencer