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

[Jakub Kicinski <kuba@kernel.org>]

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.