Re: [RFC] knfsd: per-client fair scheduling to prevent single-client starvation

On 12 Jun 2026, at 20:55, NeilBrown wrote:

> On Fri, 05 Jun 2026, Benjamin Coddington wrote:
>> On 4 Jun 2026, at 17:16, NeilBrown wrote:
>>
>>> On Wed, 03 Jun 2026, Benjamin Coddington wrote:
>>>> On 2 Jun 2026, at 23:44, Chuck Lever wrote:
>>>>
>>>>> On Tue, Jun 2, 2026, at 3:53 PM, NeilBrown wrote:
>>>>
>>>>>> Idle clients will get pushed back to 1 slot, active client will tend
>>>>>> towards a "fair" share based on how comparatively busy they are.
>>>>>>
>>>>>> This wouldn't help for v3 of course but I don't think we need these
>>>>>> advanced features for v3.
>>>>>
>>>>> Ben’s employer might disagree with that :-)
>>>>
>>>> Yes - v3 is pretty important to us here.
>>>
>>> Can you remind me why v3 is important for you?  Is it the lower
>>> state-management overhead, or something else?
>>
>> Flexfiles uses v3 in its data plane, and..
>>
>>> Is there some way would could improve the v4 implementation or protocol
>>> to make it comparable to v3 for your use case?
>>
>> I don't think so - the stateless nature of v3 gives it distinct advantages
>> (and disadvantages) over v4 for some use cases.  That property can't be
>> added to v4.
>
> v4 already has the anonymous stateid which seems perfect for a data
> plane.
> You can read/write with it just like v3 (i.e.  access check on every IO
> etc), but there is no state to recover.
> You still get client-state and session-state when can be used for flow
> control, but these don't need to be recovered so they don't impose the
> same costs as open state.
>
> I wonder if flex-files can be updated to allow v4 with anonymous stateid.
> We would have to enhance the Linux NFS client to have a "stateless"
> mount option, or similar.
>
>>
>> Also, because knfsd doesn't have different resource pools for each version
>> we're going to want to continue to balance the pool for all versions
>> exported.
>
> But it could if we wanted it to and had a coherent model of how that
> would work.  We could parse out the RPC program and version before
> queuing for a thread, much like we already parse out the TCP message
> size.
>
> We could even do that today: create a separate net-namespace for the
> separate pool, and add some iptables rules to redirect select traffic to
> that namespace.  iptables cannot switch on RPC version, but it could
> switch on source-IP if we knew which clients used v3 and which didn't.

Doable, but I'd rather not split the pool by version: the point for us is
that one shared pool stays fair regardless of which version a client
speaks.  Per-version pools just relocate the unfairness from "client with
N connections" to "version with N connections."

Ben