Re: [PATCH v6 5/5] svcrdma: Mark Read chunks

[Chuck Lever <cel@kernel.org>]

On 10/22/25 5:25 PM, Mike Snitzer wrote:
> On Wed, Oct 22, 2025 at 03:22:08PM -0400, Chuck Lever wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> The upper layer may want to know when the receive buffer's .pages
>> array is guaranteed to contain only an opaque payload. This permits
>> the upper layer to optimize its buffer handling.
>>
>> NB: Since svc_rdma_recvfrom.c is under net/, we use the comment
>> style that is preferred in the networking layer.
>>
>> Reviewed-by: Jeff Layton <jlayton@kernel.org>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>  net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>> index e7e4a39ca6c6..b1a0c72f73de 100644
>> --- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>> +++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>> @@ -815,6 +815,11 @@ static void svc_rdma_read_complete_one(struct svc_rqst *rqstp,
>>  	buf->page_len = length;
>>  	buf->len += length;
>>  	buf->buflen += length;
>> +
>> +	/* Transport guarantees that only the chunk payload
>> +	 * appears in buf->pages.
>> +	 */
>> +	buf->flags |= XDRBUF_READ;
>>  }
>>  
>>  /* Finish constructing the RPC Call message in rqstp::rq_arg.
>> -- 
>> 2.51.0
>>
>>
> 
> This patch header leaves me unclear on your thinking for upper layer
> optimization that would look for XDRBUF_READ.
> 
> I see rpcrdma_marshal_req() is checking XDRBUF_READ but...
> 
> I'm left hoping for a clearer payoff on this change's benefit (and
> relation to the rest of the patchset).

There's no pay-off yet. You asked me to provide a mechanism that
indicates when the transport is certain that buf.pages contains /only/
the write payload.

That's all that's happening here -- it paves the way for you to
construct the optimization in nfsd_vfs_write(). We don't have to commit
this change until you have a patch that can take advantage of it.

It could be that I misunderstood your request.


-- 
Chuck Lever