Re: [PATCH net-next RFC v1 0/3] net: sched: refactor qdisc drop reasons into dedicated tracepoint

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

Jesper Dangaard Brouer <hawk@kernel.org> writes:

> On 05/02/2026 04.04, Jakub Kicinski wrote:
>> On Wed, 04 Feb 2026 18:02:49 +0100 Jesper Dangaard Brouer wrote:
>>> RFC: Seeking feedback on this refactoring approach.
>>>
>>> This series refactors qdisc drop reason handling by introducing a dedicated
>>> enum qdisc_drop_reason and trace_qdisc_drop tracepoint, providing qdisc
>>> layer drop diagnostics with direct qdisc context visibility.
>> 
>> I like this!
>
> Awesome, then I will continue in this direction :-)
>
>> It will presumably require existing users to migrate over
>> but sooner we do it the fewer users that have to move?
>
> I agree. Existing users will loose some details, but the patchset
> results in fallback to SKB_DROP_REASON_QDISC_DROP as a drop reason,
> which existing tools/users will still handle.
> (The more specific drop reason is now avail via trace_qdisc_drop).
>
> Eric and Toke is this acceptable for your users?

I like it! My only concern is that drop monitor tools will see two
events for each qdisc drop. I guess that could be relatively
straight-forwardly deduplicated in the tool, though? +Antoine who works
on Retis to give him a chance to complain if not :)

> In patch 1/3 I kept the qdisc "name" as part of the enum for FQ and
> CAKE. IMHO this should be changed for next patchset, but I offer you the
> chance to review and suggest generic naming (else I will choose).

You mean you'd just name it something like QDISC_DROP_FLOOD_PROTECTION
instead of QDISC_DROP_CAKE_FLOOD? No strong objections to that...

-Toke