[nfsv4] rfc5667bis open issues

[Chuck Lever <[e-mail]>]

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.

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