netdev - Re: [PATCH net-next v1] net: sched: sfq: add detailed drop reasons for monitoring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260120162616.463c8af1@kernel.org>
Date: Tue, 20 Jan 2026 16:26:16 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, Eric Dumazet
 <eric.dumazet@...il.com>, "David S. Miller" <davem@...emloft.net>, Paolo
 Abeni <pabeni@...hat.com>, Toke Høiland-Jørgensen
 <toke@...e.dk>, carges@...udflare.com, kernel-team@...udflare.com
Subject: Re: [PATCH net-next v1] net: sched: sfq: add detailed drop reasons
 for monitoring

On Fri, 16 Jan 2026 11:40:06 +0100 Jesper Dangaard Brouer wrote:
> On 15/01/2026 13.23, Jesper Dangaard Brouer wrote:
> > Add specific drop reasons to SFQ qdisc to improve packet drop observability
> > and monitoring capabilities. This change replaces generic qdisc_drop()
> > calls with qdisc_drop_reason() to provide granular metrics about different
> > drop scenarios in production environments.
> > 
> > Two new drop reasons are introduced:
> > 
> > - SKB_DROP_REASON_QDISC_MAXFLOWS: Used when a new flow cannot be created
> >    because the maximum number of flows (flows parameter) has been
> >    reached and no free flow slots are available.
> > 
> > - SKB_DROP_REASON_QDISC_MAXDEPTH: Used when a flow's queue length exceeds
> >    the per-flow depth limit (depth parameter), triggering either tail drop
> >    or head drop depending on headdrop configuration.  
> 
> I noticed commit 5765c7f6e317 ("net_sched: sch_fq: add three 
> drop_reason") (Author: Eric Dumazet).
> 
>   SKB_DROP_REASON_FQ_BAND_LIMIT: Per-band packet limit exceeded
>   SKB_DROP_REASON_FQ_HORIZON_LIMIT: Packet timestamp too far in future
>   SKB_DROP_REASON_FQ_FLOW_LIMIT: Per-flow packet limit exceeded
> 
> Should I/we make SKB_DROP_REASON_QDISC_MAXDEPTH specific for SFQ ?
> Like naming it = SKB_DROP_REASON_SFQ_MAXDEPTH ?

FWIW FLOW_LIMIT is more intuitive to me, but I'm mostly dealing with 
fq so probably because that's the param name there.

I'd prefer the reuse (just MAXDEPTH, I don't see equivalent of
MAXFLOWS?). We assign multiple names the same values in the enum to
avoid breaking FQ users.