[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADCXZ1z-gg_VsN4kjf325HvWRxL1irhUC76B_erggm5+A7qQ7g@mail.gmail.com>
Date: Thu, 5 Feb 2026 11:24:42 -0500
From: Antoine Tenart <atenart@...hat.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Jesper Dangaard Brouer <hawk@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, bpf@...r.kernel.org,
horms@...nel.org, jiri@...nulli.us, edumazet@...gle.com,
xiyou.wangcong@...il.com, jhs@...atatu.com, carges@...udflare.com,
kernel-team@...udflare.com
Subject: Re: [PATCH net-next RFC v1 0/3] net: sched: refactor qdisc drop
reasons into dedicated tracepoint
On Thu, Feb 05, 2026 at 03:46:29PM +0100, Toke Høiland-Jørgensen wrote:
> Antoine Tenart <atenart@...hat.com> writes:
>
> > I'm wondering why not using the drop reason subsys logic to combine the
> > qdisc specific enum while not conflicting with drop reasons and allowing
> > to inject the qdisc reasons into drop reason enabled helpers as well?
>
> See this prior discussion for how the proposal came to be:
>
> https://lore.kernel.org/all/6be17a08-f8aa-4f91-9bd0-d9e1f0a92d90@kernel.org/
>
> Basically, figuring out which qdisc a drop came from is not possible
> with the current drop_reason code.
>
> So it's not just new drop reasons, it's a separate tracepoint with more
> information available (qdisc handle, name, etc). So you'll get two
> events for qdisc drops with this series (from patch 1):
>
> + trace_qdisc_drop(q, txq, dev, skb, reason);
> + kfree_skb_reason(skb, SKB_DROP_REASON_QDISC_DROP);
Right and that's fine. Using the drop reason subsys logic you could turn
the above into:
+ trace_qdisc_drop(q, txq, dev, skb, reason);
+ kfree_skb_reason(skb, (u32)reason);
You can look at enum skb_drop_reason_subsys and how that is used within
OvS (net/openvswitch/drop.h) for example.
Antoine
Powered by blists - more mailing lists