Re: [PATCH net 1/2] net/sched: pfifo_fast: cap ring size and account to memcg

On Sat, Aug 22, 2026 at 7:02 PM Jakub Kicinski <[email protected]> wrote:
>
> On Sat, 22 Aug 2026 18:14:49 -0400 Jamal Hadi Salim wrote:
> > > On Thu, 20 Aug 2026 05:57:41 -0400 Jamal Hadi Salim wrote:
> > > > +     if (qlen > 65535) {
> > > > +             pr_warn_ratelimited("pfifo_fast: capping ring size %u to 65535 for dev %s\n",
> > > > +                                 qlen, qdisc_dev(qdisc)->name);
> > > > +             qlen = 65535;
> > > > +     }
> > >
> > > Why not a hard cap?
> >
> > sorry, where to put the hard cap and what would it be?
> > Or maybe you misspoke and intended to say "why put a hardcap"?
> >
> > Or maybe in this case probably safer to just reject the change if > hard cap?
>
> The latter, I'm asking why not:
>
> if (qlen > 64k)
>         return -EINVAL;
>
> To be clear I didn't dig into the code, just read the commit msg, so
> maybe you have a reason. But the "normal behavior" for out of range
> params should be to return an error rather than silently clamp() into
> the allowed range?

No real concreate reason other than the thought that it's a device
param as opposed to a pfifo one.

I am going to send a v2. Will switch to similar to what virtio does:

  if (qlen > S16) {
      //extack here
      return -E2BIG;
  }

The followup as identified by sashikos is on tun/tap - i have a rough
patch, untested but there are others ahead of that i need to send out
first.

cheers,
jamal