Subject: [nfsv4] RPC/RDMA read chunk round-up when inline content follows

From: Chuck Lever <[email-masked]>
Date: Tue, 30 Dec 2014 12:53:58 -0500

Hi-

It turns out that Linux is the only NFS client that supports RDMA and
adds an operation (GETATTR) after WRITE in an NFSv4 compound.

Linux sends the part of the compound before the opaque file data
via RDMA SEND. The opaque file data is put into the read list. Then
the GETATTR operation is put in the read list after the file data.

Existing NFS/RDMA servers are able to receive and process this
request correctly.

First question: does the Linux client comply with RFCs 5666 and 5667
when it sends an NFSv4 WRITE compound in this way, or should it be
changed?

The intention of RFC 5667 appears to be that the GETATTR belongs
inline, following the front of the compound. Only the file data
payload belongs in the read list, if NFSv4 Direct is to be consistent
with NFSv2 and NFSv3

Now suppose the Linux client is changed to place the GETATTR operation
inline, following the front of the compound.

When the opaque file data requires round-up because it’s length is not
divisible by four, should there be a pad? if so, where does it belong?

To put it another way: Since inline data does not have a “position”
field, should the receiver assume that inline content following the
read list begins right at the end of the rounded-up chunk? or should
the receiver assume the inline content begins at the next XDR position
after the end of the chunk?

If the former, that would require inserting a zero pad before the
inline content. But that pad would cause the following inline content
to be sent unaligned, since a zero pad is always shorter than 4 bytes
long.

By implication, then, the receiver MUST conclude that round-up is
present in the case when inline data remains to be decoded (ie, the
following inline content always begins at the next XDR position). The
sender MUST NOT send a pad inline in this case. Is this correct?

I’ve read RFC 5666 section 3.7. Paragraph 4 seems most relevant, but
it doesn’t discuss the case where there is additional inline content
following a chunk list.

Thanks for reading!

--
Chuck Lever