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

[Chuck Lever <cel@kernel.org>]

On 5/7/25 3:42 AM, Christoph Hellwig wrote:
> On Tue, May 06, 2025 at 09:52:06AM -0400, Chuck Lever wrote:
>>> Are you going to wire this up to a config file in nfs-utils that
>>> gets set before the daemon starts?
>>
>> That's up to SteveD -- it might be added to /etc/nfs.conf.
> 
> Well, you should be talking to him or even include a patch.

On this list, we post nfs-utils patches separately, once the kernel API
is nailed. Steve doesn't pull such changes until the kernel changes
have been merged.

But see below: I'm still not convinced this is a tunable that is worth
going to that level of trouble for.


>>> Because otherwise this is a pretty horrible user interface.
>>
>> This is an API that has existed forever.
> 
> Huh?  It is a brand new file added by this patch.

/proc/fs/nfsd/max_block_size was added by commit 596bbe53eb3a ("[PATCH]
knfsd: Allow max size of NFSd payload to be configured") in 2006.

Or are you referring to something else?


>> I don't even like that this maximum can be tuned. After a period of
>> experimentation, I was going to set the default to a higher value and
>> be done with it, because I can't think of a reason why it needs to be
>> shifted up or down after that.
> 
> Why not?  A tiny desk NAS box has very different resources available
> compared to say a multi-socket enterprise AI data server.

I don't believe system memory size is a concern.

a. max_block_size is automatically reduced on small memory systems. See
   nfsd_get_default_max_blksize().

b. The extra memory allocation is per thread, so a smaller server can
   reduce the standing memory requirements by lowering the number of
   nfsd threads.

c. we're now removing rq_vec, so there's already less memory to allocate
   than before.


-- 
Chuck Lever