Re: [PATCH net-next 2/2] net/sched: fq_codel: local packets no longer count against memory limit

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Eric Dumazet <edumazet@google.com> writes:

> On Tue, May 12, 2026 at 5:11 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Eric Dumazet <edumazet@google.com> writes:
>>
>> > Commit 95b58430abe7 ("fq_codel: add memory limitation per queue")
>> > claimed that the 32Mb default was "reasonable even for heavy duty usages."
>> >
>> > In practice, this is not the case.
>>
>> Well, the assumption lasted a decade, so that's pretty good? :)
>>
>> > Packets that are associated with local sockets sk_wmem_alloc
>> > do not really need additional memory control.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > ---
>> >  net/sched/sch_fq_codel.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
>> > index 1b1de693d4c64a1f5f4e9e788371829dea91740e..71107dc52be799a14f370f2ad74d2eadd93992c1 100644
>> > --- a/net/sched/sch_fq_codel.c
>> > +++ b/net/sched/sch_fq_codel.c
>> > @@ -212,7 +212,7 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> >               q->new_flow_count++;
>> >               WRITE_ONCE(flow->deficit, q->quantum);
>> >       }
>> > -     get_codel_cb(skb)->mem_usage = skb->truesize;
>> > +     get_codel_cb(skb)->mem_usage = is_skb_wmem(skb) ? 0 : skb->truesize;
>> >       q->memory_usage += get_codel_cb(skb)->mem_usage;
>>
>> Only one concern here: q->memory_usage is exposed to userspace in the
>> stats, so this will look like the packets queued are zero-length to
>> anyone watching, which may end up confusing folks? Also, there will be
>> no way to see how many bytes are actually in the qdisc.
>
> Standard qdisc stats show the amount of bytes and packets.
>
> None of the other qdiscs seem to care (except cake which copy/pasted fq_codel)

Right, the cake stats was why I asked. Pretty sure there are people who
watch these; but now that you mention it, I may have confused the
standard backlog_bytes stat field with this one...

>> Should we keep a separate counter so we can still accurately report the
>> memory usage to userspace?
>
> Only purpose of mem usage counter was to have an idea of how close of
> the 32Mb limit we were, this is still reported for forwarded packets
> (router workload)
>
> All these counters take precious resources, I would rather not add another one.

Right, fair (and see above). In that case:

Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>