[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a505b3dt.fsf@toke.dk>
Date: Sat, 29 Nov 2025 10:21:34 +0100
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>, Jamal Hadi Salim
<jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko
<jiri@...nulli.us>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>
Cc: Jonas Köppeler <j.koeppeler@...berlin.de>,
cake@...ts.bufferbloat.net,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/4] net/sched: sch_cake: Add cake_mq qdisc
for using cake on mq devices
Willem de Bruijn <willemdebruijn.kernel@...il.com> writes:
> Toke Høiland-Jørgensen wrote:
>> Add a cake_mq qdisc which installs cake instances on each hardware
>> queue on a multi-queue device.
>>
>> This is just a copy of sch_mq that installs cake instead of the default
>> qdisc on each queue. Subsequent commits will add sharing of the config
>> between cake instances, as well as a multi-queue aware shaper algorithm.
>>
>> Reviewed-by: Jamal Hadi Salim <jhs@...atatu.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>> ---
>> net/sched/sch_cake.c | 214 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 213 insertions(+), 1 deletion(-)
>
> Is this code duplication unavoidable?
>
> Could the same be achieved by either
>
> extending the original sch_mq to have a variant that calls the
> custom cake_mq_change.
>
> Or avoid hanging the shared state off of parent mq entirely. Have the
> cake instances share it directly. E.g., where all but the instance on
> netdev_get_tx_queue(dev, 0) are opened in a special "shared" mode (a
> bit like SO_REUSEPORT sockets) and lookup the state from that
> instance.
We actually started out with something like that, but ended up with the
current variant for primarily UAPI reasons: Having the mq variant be a
separate named qdisc is simple and easy to understand ('cake' gets you
single-queue, 'cake_mq' gets you multi-queue).
I think having that variant live with the cake code makes sense. I
suppose we could reuse a couple of the mq callbacks by exporting them
and calling them from the cake code and avoid some duplication that way.
I can follow up with a patch to consolidate those if you think it is
worth it to do so?
-Toke
Powered by blists - more mailing lists