Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: NeilBrown <neil@brown.name>
Cc: Jeff Layton <jlayton@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v3 11/11] NFSD: Remove NFSSVC_MAXBLKSIZE from .pc_xdrressize
Date: Sat, 26 Apr 2025 11:08:28 -0400	[thread overview]
Message-ID: <80975590-d320-4420-adfb-7e7e3ad25f6a@kernel.org> (raw)
In-Reply-To: <174564186264.500591.13673906323063582835@noble.neil.brown.name>

On 4/26/25 12:31 AM, NeilBrown wrote:
> On Thu, 24 Apr 2025, cel@kernel.org wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> The value in the .pc_xdrressize field is used to "reserve space in
>> the output queue". Relevant only to UDP transports, AFAICT.
>>
>> The fixed value of NFSSVC_MAXBLKSIZE is added to that field for
>> NFSv2 and NFSv3 read requests, even though nfsd_proc_read() is
>> already careful to reserve the actual size of the read payload.
>> Adding the maximum payload size to .pc_xdrressize seems to be
>> unnecessary.
> 
> I believe it is necessary.
> 
> svc_reserve() (and svc_reserve_auth) only ever reduces the size of the
> reservation.
> ->rq_reserved is initialised to serv->sv_max_mesg, then reduced to
> .pc_xdrressize once the proc is known, then possibly reduced further by
> code in the proc.
> So .pc_xdrressize must be (at least) the largest possible size.

Hrm. I instrumented this code path. It seemed to be doing exactly
what I expected. The behavior of xdr_reserve_space() is to /increase/
buffer space reservation, so svc_reserve() seems to behave in the
opposite way, then?

So if the maximum payload size is no longer a constant, these
pc_xdrressize values still have to add the largest payload size that
NFSD can support (probably will be 8MB), not the max-payload-size
setting in effect for that nfsd thread pool.


>> Also, instead of adding a constant 4 bytes for each payload's
>> XDR pad, add the actual size of the pad for better accuracy of
>> the reservation size.
> 
> Could we instead change svc_reserve() to add the pad, and remove all the
> manual padding?

The padding is needed only for a few certain operations; READ and
READLINK, I think that's it. NFSv4 GETATTR might need it too.

IOW the common case is that no padding is needed.

The largest payload, even if it needs an XDR pad, will be
NFSSVC_MAXBLKSIZE.


> But pc_xdrressize is in xdr units - it is multiplied by 4 before passing
> to svc_reserve.  So these changes don't do what you think they do...

Fair enough. I can drop "NFSD: Remove NFSSVC_MAXBLKSIZE from
.pc_xdrressize" and "NFSD: Remove NFSD_BUFSIZE".

I find the name NFSSVC_MAXBLKSIZE confusing, though. NFS is a file
protocol, so I'm not clear what a "block" is in this context.

Also, am I correct that the only transport that cares about this
send buffer reservation is UDP?


> NeilBrown
> 
> 
>>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>  fs/nfsd/nfs3proc.c | 4 ++--
>>  fs/nfsd/nfsproc.c  | 4 ++--
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/nfsd/nfs3proc.c b/fs/nfsd/nfs3proc.c
>> index 372bdcf5e07a..dbb750a7b5db 100644
>> --- a/fs/nfsd/nfs3proc.c
>> +++ b/fs/nfsd/nfs3proc.c
>> @@ -202,7 +202,7 @@ nfsd3_proc_read(struct svc_rqst *rqstp)
>>  	 */
>>  	resp->count = argp->count;
>>  	svc_reserve_auth(rqstp, ((1 + NFS3_POST_OP_ATTR_WORDS + 3) << 2) +
>> -			 resp->count + 4);
>> +			 xdr_align_size(resp->count));
>>  
>>  	fh_copy(&resp->fh, &argp->fh);
>>  	resp->status = nfsd_read(rqstp, &resp->fh, argp->offset,
>> @@ -921,7 +921,7 @@ static const struct svc_procedure nfsd_procedures3[22] = {
>>  		.pc_argzero = sizeof(struct nfsd3_readargs),
>>  		.pc_ressize = sizeof(struct nfsd3_readres),
>>  		.pc_cachetype = RC_NOCACHE,
>> -		.pc_xdrressize = ST+pAT+4+NFSSVC_MAXBLKSIZE/4,
>> +		.pc_xdrressize = ST+pAT+3,
>>  		.pc_name = "READ",
>>  	},
>>  	[NFS3PROC_WRITE] = {
>> diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c
>> index 6dda081eb24c..a95faf726e58 100644
>> --- a/fs/nfsd/nfsproc.c
>> +++ b/fs/nfsd/nfsproc.c
>> @@ -219,7 +219,7 @@ nfsd_proc_read(struct svc_rqst *rqstp)
>>  	/* Obtain buffer pointer for payload. 19 is 1 word for
>>  	 * status, 17 words for fattr, and 1 word for the byte count.
>>  	 */
>> -	svc_reserve_auth(rqstp, (19<<2) + argp->count + 4);
>> +	svc_reserve_auth(rqstp, (19<<2) + xdr_align_size(argp->count));
>>  
>>  	resp->count = argp->count;
>>  	fh_copy(&resp->fh, &argp->fh);
>> @@ -739,7 +739,7 @@ static const struct svc_procedure nfsd_procedures2[18] = {
>>  		.pc_argzero = sizeof(struct nfsd_readargs),
>>  		.pc_ressize = sizeof(struct nfsd_readres),
>>  		.pc_cachetype = RC_NOCACHE,
>> -		.pc_xdrressize = ST+AT+1+NFSSVC_MAXBLKSIZE_V2/4,
>> +		.pc_xdrressize = ST+AT+1,
>>  		.pc_name = "READ",
>>  	},
>>  	[NFSPROC_WRITECACHE] = {
>> -- 
>> 2.49.0
>>
>>
> 
> 


-- 
Chuck Lever

      reply	other threads:[~2025-04-26 15:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 15:21 [PATCH v3 00/11] Allocate payload arrays dynamically cel
2025-04-23 15:21 ` [PATCH v3 01/11] sunrpc: Remove backchannel check in svc_init_buffer() cel
2025-04-23 15:21 ` [PATCH v3 02/11] sunrpc: Add a helper to derive maxpages from sv_max_mesg cel
2025-04-23 15:21 ` [PATCH v3 03/11] sunrpc: Replace the rq_pages array with dynamically-allocated memory cel
2025-04-23 15:21 ` [PATCH v3 04/11] sunrpc: Replace the rq_vec " cel
2025-04-23 15:21 ` [PATCH v3 05/11] sunrpc: Replace the rq_bvec " cel
2025-04-23 15:21 ` [PATCH v3 06/11] sunrpc: Adjust size of socket's receive page array dynamically cel
2025-04-23 15:21 ` [PATCH v3 07/11] svcrdma: Adjust the number of RDMA contexts per transport cel
2025-04-23 15:21 ` [PATCH v3 08/11] svcrdma: Adjust the number of entries in svc_rdma_recv_ctxt::rc_pages cel
2025-04-23 15:21 ` [PATCH v3 09/11] svcrdma: Adjust the number of entries in svc_rdma_send_ctxt::sc_pages cel
2025-04-23 15:21 ` [PATCH v3 10/11] sunrpc: Remove the RPCSVC_MAXPAGES macro cel
2025-04-23 15:21 ` [PATCH v3 11/11] NFSD: Remove NFSSVC_MAXBLKSIZE from .pc_xdrressize cel
2025-04-26  4:31   ` NeilBrown
2025-04-26 15:08     ` Chuck Lever [this message]

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=80975590-d320-4420-adfb-7e7e3ad25f6a@kernel.org \
    --to=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox