Re: [PATCH v4 14/14] SUNRPC: Bump the maximum payload size for the server

[Chuck Lever <cel@kernel.org>]

On 4/28/25 5:08 PM, Jeff Layton wrote:
> On Mon, 2025-04-28 at 15:37 -0400, cel@kernel.org wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> Increase the maximum server-side RPC payload to 4MB. The default
>> remains at 1MB.
>>
>> To adjust the operational maximum, shut down the NFS server. Then
>> echo a new value into:
>>
>>   /proc/fs/nfsd/max_block_size
>>
>> And restart the NFS server.
>>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>  include/linux/sunrpc/svc.h | 14 +++++++-------
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
>> index e27bc051ec67..b449eb02e00a 100644
>> --- a/include/linux/sunrpc/svc.h
>> +++ b/include/linux/sunrpc/svc.h
>> @@ -119,14 +119,14 @@ void svc_destroy(struct svc_serv **svcp);
>>   * Linux limit; someone who cares more about NFS/UDP performance
>>   * can test a larger number.
>>   *
>> - * For TCP transports we have more freedom.  A size of 1MB is
>> - * chosen to match the client limit.  Other OSes are known to
>> - * have larger limits, but those numbers are probably beyond
>> - * the point of diminishing returns.
>> + * For non-UDP transports we have more freedom.  A size of 4MB is
>> + * chosen to accommodate clients that support larger I/O sizes.
>>   */
>> -#define RPCSVC_MAXPAYLOAD	(1*1024*1024u)
>> -#define RPCSVC_MAXPAYLOAD_TCP	RPCSVC_MAXPAYLOAD
>> -#define RPCSVC_MAXPAYLOAD_UDP	(32*1024u)
>> +enum {
>> +	RPCSVC_MAXPAYLOAD	= 4 * 1024 * 1024,
>> +	RPCSVC_MAXPAYLOAD_TCP	= RPCSVC_MAXPAYLOAD,
>> +	RPCSVC_MAXPAYLOAD_UDP	= 32 * 1024,
>> +};
> 
> I guess the enum is so that the symbol names remain in debuginfo?

My impression is these days enum is preferred over #define for
this kind of symbolic constant. This part of the change is merely
clean up.


>>  extern u32 svc_max_payload(const struct svc_rqst *rqstp);
>>  
> 
> Reviewed-by: Jeff Layton <jlayton@kernel.org>

Thanks for the review!

-- 
Chuck Lever