[Cake] Re: [PATCH net-next v2 0/4] Multi-queue aware sch_cake

[Cong Wang <xiyou.wangcong@gmail.com>]

On Sat, Nov 29, 2025 at 10:25:02AM +0100, Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
> 
> > On Fri, 28 Nov 2025 23:33:26 +0100 Toke Høiland-Jørgensen wrote:
> >> Jakub Kicinski <kuba@kernel.org> writes:
> >> > On Thu, 27 Nov 2025 20:27:49 +0100 Toke Høiland-Jørgensen wrote:  
> >> >> Yeah; how about I follow up with a selftest after this has been merged
> >> >> into both the kernel and iproute2?  
> >> >
> >> > Why is iproute2 a blocker? Because you're not sure if the "API" won't
> >> > change or because you're worried about NIPA or.. ?  
> >> 
> >> No, just that the patch that adds the new qdisc to iproute2 needs to be
> >> merged before the selftests can use them. Which they won't be until the
> >> kernel patches are merged, so we'll have to follow up with the selftests
> >> once that has happened. IIUC, at least :)
> >
> > You can add a URL to the branch with the pending iproute2 changes
> > when you post the selftests and we'll pull them in NIPA, or post 
> > the patches at the same time (just not in one thread).
> 
> Ah, cool.
> 
> Given the likely impending merge window, how would you feel about
> merging this series as-is and taking the selftests as a follow-up? Would
> be kinda neat to get it in this cycle :)

A followup is definitely okay.

Maybe it is time to think about getting rid of such dependence on
iproute2? I am thinking about replacing those iproute2 commands with
libnl (or other netlink libraries). I know this is a lot of work, but
we have AI today, so perhaps it would just take AI a few days.

Another benefit of this is we would avoid parsing with regex, which has
been a headache even for me.

Anyway, it is a long-term thing.

Regards,
Cong