On Tue, Oct 27, 2020 at 09:24:54AM -0400, Chuck Lever wrote: > 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. Can the client can detect the server's lack of support and fall back, or does the server's incompleteness violate the RFC in some way that can actually cause a failure to interoperate? --b. > 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 > >
