Re: [nfsv4] rfc5667bis open issues

[Chuck Lever <[e-mail]>]

> On Sep 22, 2016, at 3:10 PM, Chuck Lever <[e-mail]> wrote:
> 
> I'm preparing a new revision of rfc5667bis, and a couple of issues have
> arisen:
> 
> 1. Reporting RPC-over-RDMA decoding errors on NFSv4
> 
> The current text says the NFS server can return an RPC GARBAGE_ARGS
> reply, or an RPC-over-RDMA level ERR_CHUNK reply.
> 
> Does this count as a dropped RPC reply, such that an NFSv4 server
> would have to drop the connection?
> 
> When an NFS server returns one of these responses, does it have to
> enter the reply in its DRC ? What if any implications are there for
> an NFSv4.1 session (slot retired? ignored?)
> 
> 
> 2. Skipping Write chunks in an NFSv4 COMPOUND
> 
> The current text of rfc5666bis (Section 5.3.2) suggests that when
> multiple Write chunks are provided for an RPC, and the responder
> doesn't use one of them, it should use that chunk for the next
> DDP-eligible XDR data item.

The problematic text is actually this part of rfc5666bis:
 
4.4.6.2.  Unused Write Chunks

   There are occasions when a requester provides a Write chunk but the
   responder is not able to use it.

   For example, an Upper Layer Protocol may define a union result where
   some arms of the union contain a DDP-eligible data item while other
   arms do not.  The responder is REQUIRED to use requester-provided
   Write chunks in this case, but if the responder returns a result that
   uses an arm of the union that has no DDP-eligible data item, the
   Write chunk remains unconsumed.

   If there is a subsequent DDP-eligible data item, it MUST be placed in
   that unconsumed Write chunk.  The requester MUST provision each Write
   chunk so it can be filled with the largest DDP-eligible data item
   that can be placed in it.


> This could be a problem for READ_PLUS. The client has no way of
> predicting whether the server will return a CONTENT_DATA arm (which
> would consume a Write chunk) or a CONTENT_HOLE arm (which would not).
> 
> I think a better approach would be for the binding to specify that
> if a Write chunk is provided for a READ_PLUS operation, the server
> consumes that chunk:
> 
> - by returning CONTENT_DATA in that chunk
> 
> - by returning an empty chunk for CONTENT_HOLE
> 
> If the client provides an empty chunk in that position, the
> READ_PLUS result is returned inline.
> 
> Opinions?

--
Chuck Lever