Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-06

[David Noveck <[e-mail]>]

> RFC 5667 Section 4 says:

> > Similarly, a single RDMA Read list entry MAY be posted by the client
> > to supply the opaque file data for a WRITE request or the pathname
> > for a SYMLINK request.

Part of the problem here is that, as you discuss later, this statement is
ambiguous, as the meaning of "read list entry" is not clear.

> > The server MUST ignore any Read list for
> > other NFS procedures,

As I understand it, this statement cannot apply to PZRCs, and rfc5666bis
has already dealt with that issue.  So, if one tried to maintain this
paragraph,
in something like the RFC5667-form, some modification would have been
necessary to avoid essentially preventing any use of PZRCs

> > as well as additional Read list entries beyond
> > the first in the list.

> I take "Read list entry" to mean Read chunk, composed of
> multiple list entries that share the same XDR position.
> This comports with similar language describing Write
> chunks where a single list entry is indeed allowed to
> have multiple segments.

Makes sense to me.

> However, the original intent might have been "single
> Read segment".

It might have been but there is no way to be sure.  In some
cases, one might look to how existing implementations behave,
to come up with an interpretation even though it might not
have been what the author intended.

> In that case, this language clearly states
> that Legacy clients can send only one contiguous memory
> region

I think you mean that,  if that were the case, this language would
mean that.

> in Legacy NFS READ and SYMLINK requests.

I think we are talking about WRITE and SYMLINK, given
that read chunks are mentioned.

While I can easily believe that existing implementations
limit SYMLINKs to a single contiguous buffer, I have trouble
believing the same about WRITEs.

> At your behest I replaced the RFC 5667 language with
> just the definitions of which XDR data items are DDP
> eligible, and removed the discussion about Read list
> entries.

One benefit of that is that we now know what the spec says, while,
as with the section 4 text you quoted, we weren't.

> This new language permits a Legacy client to reduce the
> Payload stream of an NFS READ or SYMLINK request and put
> that stream into a Position-Zero Read chunk. The client
> would then send the PZRC and the non-zero position chunk:
> two distinct Read chunks, which is not allowed by the
> RFC 5667 language discussing NFS READ or SYMLINK.

It is not clear that section 4 would disallow that.  Beyond the
uncertainty about what "read list entry" means and a possible need
to treat PZRCs separately as done in rfc5666bis, the issue is that
you are only supposed to ignore "additional Read list entries beyond
the first in the list."  To me, this would allow a PZRC, if it is the first
in the
list, which it might well be.

Anyway, your view and my view of this obscure text doesn't really
count.  We have to work off the behavior of implementations.  If existing
implementations did or didn't do something because of this presumed
restriction, that would provide an answer.  Unfortunately, I don't think
this
provides an answer either,

> To remain interoperable with RFC 5667-compliant
> implementations, only one Read chunk is allowed, which
> excludes the use of reduced Payload streams in a PZRC,
> even though RPC-over-RDMA Version One allows this
> construction.

True but it is not clear to me me how this situation could ever
arise given:

   - The XDR of legacy NFS protocols
   - The definition of what is DDP-eligible in the ULB


> There isn't a need to support sending a reduced Payload
> stream this way in these NFS versions, so I added the new
> paragraph to forbid it explicitly.

If there is no way for this situation to arise, there is no need to
forbid it explicitly.

> This should now have
> the same basic meaning as Section 4 of RFC 5667.

As the meaning of that section is so unclear, I can't
be sure.

On Sat, Feb 25, 2017 at 12:48 PM, Chuck Lever <[e-mail]>
wrote:

>
> > On Feb 25, 2017, at 4:57 AM, David Noveck <[e-mail]> wrote:
> >
> > 3.  Upper Layer Binding for NFS Versions 2 and 3
> > The penultimate paragraph in this section is new in this version and I
> don't understand the need for a new version 2/3 restriction so late in the
> game.
>
> RFC 5667 Section 4 says:
>
> > Similarly, a single RDMA Read list entry MAY be posted by the client
> > to supply the opaque file data for a WRITE request or the pathname
> > for a SYMLINK request.  The server MUST ignore any Read list for
> > other NFS procedures, as well as additional Read list entries beyond
> > the first in the list.
>
> I take "Read list entry" to mean Read chunk, composed of
> multiple list entries that share the same XDR position.
> This comports with similar language describing Write
> chunks where a single list entry is indeed allowed to
> have multiple segments.
>
> However, the original intent might have been "single
> Read segment". In that case, this language clearly states
> that Legacy clients can send only one contiguous memory
> region in Legacy NFS READ and SYMLINK requests.
>
> At your behest I replaced the RFC 5667 language with
> just the definitions of which XDR data items are DDP
> eligible, and removed the discussion about Read list
> entries.
>
> This new language permits a Legacy client to reduce the
> Payload stream of an NFS READ or SYMLINK request and put
> that stream into a Position-Zero Read chunk. The client
> would then send the PZRC and the non-zero position chunk:
> two distinct Read chunks, which is not allowed by the
> RFC 5667 language discussing NFS READ or SYMLINK.
>
> To remain interoperable with RFC 5667-compliant
> implementations, only one Read chunk is allowed, which
> excludes the use of reduced Payload streams in a PZRC,
> even though RPC-over-RDMA Version One allows this
> construction.
>
> There isn't a need to support sending a reduced Payload
> stream this way in these NFS versions, so I added the new
> paragraph to forbid it explicitly. This should now have
> the same basic meaning as Section 4 of RFC 5667.
>
> RFC 5667 does not restrict sending a Write chunk and a
> Reply chunk together. However IIRC current implementations
> do not support this (at least with NFSv2 and NFSv3) and
> there shouldn't ever be a need to for these NFS versions.
>
>
> > If this is not a new restriction, the intent would be clearer if it was
> rewritten as follows:
> > The structure of the NFS version 2 and  3 protocols and limitations on
> DDP-eligible data items given above are such that:
> >       • It is impossible for a Legacy  NFS client to validly send a
> reduced Payload stream in a Long Call.
> >       • It is impossible for a Legacy  NFS client to validly enable a
> Legacy NFS server to send a reduced Payload stream in a Long Reply.
>
>
> --
> Chuck Lever
>
>
>
>