Hi Leon- > On Oct 27, 2020, at 2:08 AM, Leon Romanovsky <leon@xxxxxxxxxx> wrote: > > On Mon, Oct 26, 2020 at 02:53:53PM -0400, Chuck Lever wrote: >> This series implements support for multiple RPC/RDMA chunks per RPC >> transaction. This is one of the few remaining generalities that the >> Linux NFS/RDMA server implementation lacks. >> >> There is currently one known NFS/RDMA client implementation that can >> send multiple chunks per RPC, and that is Solaris. Multiple chunks >> are rare enough that the Linux NFS/RDMA implementation has been >> successful without this support for many years. > > So why do we need it? Solaris is dead, and like you wrote Linux systems > work without this feature just fine, what are the benefits? Who will use it? The Linux NFS implementation is living. We can add the ability to provision multiple chunks per RPC to the Linux NFS client at any time. Likewise any actively developed NFS/RDMA implementation can add this feature. The RPC/RDMA version 1 protocol does not have the ability to communicate the maximum number of chunks the server will accept per RPC. Other server implementations do support multiple chunks per RPC. The Linux NFS/RDMA server implementation has always been incomplete in this regard. And the Linux NFS server implementation (the non-transport specific part) already supports multiple data payloads per NFSv4 COMPOUND. Restoring a little more of the cover letter: >> Along with multiple chunk support, this series adds the following >> benefits: >> >> - More robust input sanitization of RPC/RDMA headers >> - An internal representation of chunks that is agnostic to their >> wire format The Linux NFS/RDMA server implementation does need to have better input sanitization. And there is a version 2 of RPC/RDMA under active development: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-version-two/ Having some protocol version agnosticism in our transport might be necessary eventually. -- Chuck Lever