All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH 00/20] NFSD support for multiple RPC/RDMA chunks
Date: Tue, 27 Oct 2020 09:24:54 -0400	[thread overview]
Message-ID: <DAC657D8-D254-452C-9B21-3053F70C8C73@oracle.com> (raw)
In-Reply-To: <20201027060823.GF4821@unreal>

Hi Leon-

> On Oct 27, 2020, at 2:08 AM, Leon Romanovsky <leon@kernel.org> 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




  reply	other threads:[~2020-10-27 13:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 18:53 [PATCH 00/20] NFSD support for multiple RPC/RDMA chunks Chuck Lever
2020-10-26 18:53 ` [PATCH 01/20] SUNRPC: Adjust synopsis of xdr_buf_subsegment() Chuck Lever
2020-10-26 18:54 ` [PATCH 02/20] svcrdma: Const-ify the xdr_buf arguments Chuck Lever
2020-10-26 18:54 ` [PATCH 03/20] svcrdma: Refactor the RDMA Write path Chuck Lever
2020-10-26 18:54 ` [PATCH 04/20] SUNRPC: Rename svc_encode_read_payload() Chuck Lever
2020-10-27 20:53   ` J. Bruce Fields
2020-10-28 13:16     ` Chuck Lever
2020-10-26 18:54 ` [PATCH 05/20] NFSD: Invoke svc_encode_result_payload() in "read" NFSD encoders Chuck Lever
2020-10-26 18:54 ` [PATCH 06/20] svcrdma: Post RDMA Writes while XDR encoding replies Chuck Lever
2020-10-26 18:54 ` [PATCH 07/20] svcrdma: Clean up svc_rdma_encode_reply_chunk() Chuck Lever
2020-10-26 18:54 ` [PATCH 08/20] svcrdma: Add a "parsed chunk list" data structure Chuck Lever
2020-10-26 18:54 ` [PATCH 09/20] svcrdma: Use parsed chunk lists to derive the inv_rkey Chuck Lever
2020-10-26 18:54 ` [PATCH 10/20] svcrdma: Use parsed chunk lists to detect reverse direction replies Chuck Lever
2020-10-26 18:54 ` [PATCH 11/20] svcrdma: Use parsed chunk lists to construct RDMA Writes Chuck Lever
2020-10-26 18:54 ` [PATCH 12/20] svcrdma: Use parsed chunk lists to encode Reply transport headers Chuck Lever
2020-10-26 18:55 ` [PATCH 13/20] svcrdma: Support multiple write chunks when pulling up Chuck Lever
2020-10-26 18:55 ` [PATCH 14/20] svcrdma: Support multiple Write chunks in svc_rdma_map_reply_msg() Chuck Lever
2020-10-26 18:55 ` [PATCH 15/20] svcrdma: Support multiple Write chunks in svc_rdma_send_reply_chunk Chuck Lever
2020-10-26 18:55 ` [PATCH 16/20] svcrdma: Remove chunk list pointers Chuck Lever
2020-10-26 18:55 ` [PATCH 17/20] svcrdma: Clean up chunk tracepoints Chuck Lever
2020-10-26 18:55 ` [PATCH 18/20] svcrdma: Rename info::ri_chunklen Chuck Lever
2020-10-26 18:55 ` [PATCH 19/20] svcrdma: Use the new parsed chunk list when pulling Read chunks Chuck Lever
2020-10-26 18:55 ` [PATCH 20/20] svcrdma: support multiple Read chunks per RPC Chuck Lever
2020-10-27  6:08 ` [PATCH 00/20] NFSD support for multiple RPC/RDMA chunks Leon Romanovsky
2020-10-27 13:24   ` Chuck Lever [this message]
2020-10-27 17:25     ` J. Bruce Fields
2020-10-27 17:29       ` Chuck Lever
2020-10-28  7:16     ` Leon Romanovsky
2020-10-28 13:10       ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DAC657D8-D254-452C-9B21-3053F70C8C73@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=leon@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.