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@gmail.com>]

Toke Høiland-Jørgensen wrote:
> Willem de Bruijn <willemdebruijn.kernel@gmail.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@mojatatu.com>
> >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.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?

Since most functions are identical, I do think reusing them is
preferable over duplicating them.

I'm not fully convinced that mq_cake + cake is preferable over
mq + cake (my second suggestion). We also do not have a separate
mq_fq, say. But mine is just one opinion from the peanut gallery.