Re: [PATCH RFC 0/4] nfsd: per-client fair-queue dispatch

On Thu, Jun 4, 2026, at 9:08 AM, Benjamin Coddington wrote:
> That turns the one open parameter into "how many RPCs is an interactive
> cycle" (N).  I'd rather not make it an admin knob either:
>
>   - a generous fixed default - over-provisioning costs almost nothing, since
>     a sustained stream never idles to collect it, and under-provisioning just
>     lets the tail of an unusually large command fall back to bulk;
>   - measure it - track per-connection burst size between idle gaps;
>   - borrow the v4.1 slot count as a per-connection hint (v3 would need a
>     fallback).

If we can get away with a single mechanism rather than an additional
fallback, that will keep things "no more complicated than necessary"
and easier to test.

> Does a burst-sized allowance fit how you were picturing the sparse tier, or
> were you thinking the single-RPC jump was enough and the rest should just
> share bulk?  That's the main fork I see.

It's a good open question. Why not prototype a burst-sized allowance and
then we can examine the behavior using your test harness to see how much
of a difference it makes.


-- 
Chuck Lever