Re: [PATCH 4/6] nfsd: allocate new session-based DRC slots on demand.

Chuck Lever
2024-11-20T00:32:16Z

On Wed, Nov 20, 2024 at 09:27:51AM +1100, NeilBrown wrote:
> On Wed, 20 Nov 2024, Chuck Lever wrote:
> > On Tue, Nov 19, 2024 at 11:41:31AM +1100, NeilBrown wrote:
> > > If a client ever uses the highest available slot for a given session,
> > > attempt to allocate another slot so there is room for the client to use
> > > more slots if wanted. GFP_NOWAIT is used so if there is not plenty of
> > > free memory, failure is expected - which is what we want. It also
> > > allows the allocation while holding a spinlock.
> > >
> > > We would expect to stablise with one more slot available than the client
> > > actually uses.
> >
> > Which begs the question "why have a 2048 slot maximum session slot
> > table size?" 1025 might work too. But is there a need for any
> > maximum at all, or is this just a sanity check?
>
> Linux NFS presumably isn't the only client, and it might change in the
> future. Maybe there is no need for a maximum. It was mostly as a
> sanity check.
>
> It wouldn't take much to convince me to remove the limit.

What's the worse that might happen if there is no cap? Can this be
used as a DoS vector?

If a maximum should be necessary, its value should be clearly
labeled as "not an architectural limit -- for sanity checking only".

> > > Now that we grow the slot table on demand we can start with a smaller
> > > allocation. Define NFSD_MAX_INITIAL_SLOTS and allocate at most that
> > > many when session is created.
> >
> > Maybe NFSD_DEFAULT_INITIAL_SLOTS is more descriptive?
>
> I don't think "DEFAULT" is the right word. The client requests a number
> of slots. That is the "Default". The server can impose a limit - a
> maximum.
> Maybe we don't need a limit here either?

I see. Well I don't think there needs to be a "maximum" number of
initial slots. NFSD can try to allocate the number the client
requested as best it can, until it hits our sane maximum above.

I think sessions should have a minimum number of slots to guarantee
forward progress (or IOW prevent a deadlock). I would say that
number should be larger than 1 -- perhaps 2 or even 4.

The problem with a small initial slot count is that means the
session has a slow start heuristic. That might or might not be
desirable here.

--
Chuck Lever