All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever III <chuck.lever@oracle.com>
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Anna Schumaker <anna.schumaker@netapp.com>
Subject: Re: [RFC 1/2] xprtrdma: xdr pad optimization revisted again
Date: Tue, 31 Aug 2021 16:11:56 +0000	[thread overview]
Message-ID: <9B16F1E6-62E1-4A54-930D-7D6B0C2E5857@oracle.com> (raw)
In-Reply-To: <CAN-5tyGVv1dpoifdaH-R2AdmyfuzFDaBeQEq2gozr1Cd93megQ@mail.gmail.com>


> On Aug 31, 2021, at 11:58 AM, Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote:
> 
> On Tue, Aug 31, 2021 at 10:33 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
>> 
>> Since RFC 8666 says "SHOULD NOT", the spec mandates that the client

This should say "RFC 8166."


>> has to expect there might be a server that will RDMA Write the XDR
>> pad, so the Linux client really should always provide one. Having
>> a persistently registered spot to use for that means we have a
>> potential no-cost mechanism for providing that extra segment. The
>> whole "pad optimization" thing was because the pad segment is
>> currently registered on the fly, so it has a per-I/O cost.
> 
> I just can't reconcile in my head the logic that rfc 8666 "SHOULD NOT"
> allocate and rfc 8166 that says server "MUST NOT" write the XDR
> padding, to mean that client should allocate memory.

 3.4.6.2.  Write Chunk Roundup

   When provisioning a Write chunk for a variable-length result data
   item, the Requester SHOULD NOT include additional space for XDR
   roundup padding.  A Responder MUST NOT write XDR roundup padding into
   a Write chunk, even if the Requester made space available for it.
   Therefore, when returning a single variable-length result data item,
   a returned Write chunk’s total length MUST be the same as the encoded
   length of the result data item.

RFC 8166-compliant servers MUST NOT write padding. pre-8166 servers
sometimes do write it. I would like the Linux client to interoperate
with both because not interoperating with pre-8166 servers would be
a regression.


> How can we assess that there are any old Solaris server out there for
> which we are keeping this around? Are we expected to keep this
> forever? Sorry the answers are probably not what I want to hear and
> I'm just more expressing frustration.

There's no way to know how many pre-RFC 8166 servers there are out
there. But that's now moot, since we have a solution that makes it
basically free to support them.

--
Chuck Lever




  reply	other threads:[~2021-08-31 16:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 16:53 [RFC 0/2] revisit RMDA XDR padding management Olga Kornievskaia
2021-08-30 16:53 ` [RFC 1/2] xprtrdma: xdr pad optimization revisted again Olga Kornievskaia
2021-08-30 17:04   ` Chuck Lever III
2021-08-30 17:24     ` Olga Kornievskaia
2021-08-30 17:34       ` Trond Myklebust
2021-08-30 18:02         ` Chuck Lever III
2021-08-30 18:18           ` Trond Myklebust
2021-08-30 20:37             ` Chuck Lever III
2021-08-31 14:33               ` Chuck Lever III
2021-08-31 15:58                 ` Olga Kornievskaia
2021-08-31 16:11                   ` Chuck Lever III [this message]
2021-08-31 15:54               ` Olga Kornievskaia
2021-08-31 16:02                 ` Chuck Lever III
2021-08-30 17:35       ` Chuck Lever III
2021-08-30 16:53 ` [RFC 2/2] xprtrdma: remove re_implicit_roundup xprt_rdma_pad_optimize Olga Kornievskaia
2021-08-30 16:57   ` Chuck Lever III
2021-08-30 16:55 ` [RFC 0/2] revisit RMDA XDR padding management Olga Kornievskaia

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=9B16F1E6-62E1-4A54-930D-7D6B0C2E5857@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=olga.kornievskaia@gmail.com \
    --cc=trondmy@hammerspace.com \
    /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.