> On Aug 31, 2021, at 11:58 AM, Olga Kornievskaia <olga.kornievskaia@xxxxxxxxx> wrote: > > On Tue, Aug 31, 2021 at 10:33 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> 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
