From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=toke.dk; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=toke.dk policy.dmarc=reject From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1764444794; bh=f/KyVCRWNS1Y8RXUJQH+pdcC5xBr+/2oT62pE2DNR8c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mcA9/JOKO+mcqnOtpkyJwZEecAs8jeYMaYl+y7QscbRinl/fYtSkCtTKqlFAa2n8n BrOEI8rmqvFKMBP/+HoNMj/43Gw+jSFrjJ+FZUnHb2KR8uKQNJmHXo0uXpn74Wq8hh hsibo6UOldCgwgVoqcFOHFb5JgSf/oNwU4N7Zj/t2T7uwoHRZgb7MdZkqx4aSWZIsG aMNSM+w9Jkv37OgttawTEfJaU63VjL1CI3SyXzbWx+8xHzxu4gZPQQI03TqtUdGI7V MUtWc2G/+ykayfCfNFQBV6sl2H4irbIz8fobETaAxy4eq+inQldMi0m0eUyD2KDuyr LLonTXz/VwLGQ== To: Willem de Bruijn , Willem de Bruijn , Jamal Hadi Salim , Cong Wang , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Jonas =?utf-8?Q?K=C3=B6ppeler?= , cake@lists.bufferbloat.net, netdev@vger.kernel.org In-Reply-To: References: <20251127-mq-cake-sub-qdisc-v2-0-24d9ead047b9@redhat.com> <20251127-mq-cake-sub-qdisc-v2-2-24d9ead047b9@redhat.com> <87a505b3dt.fsf@toke.dk> Date: Sat, 29 Nov 2025 20:33:14 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zf84ab2d.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: DKR25KMWWXSP7BKRYXBAYFI4CQX7U2PZ X-Message-ID-Hash: DKR25KMWWXSP7BKRYXBAYFI4CQX7U2PZ X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Cake] Re: [PATCH net-next v2 2/4] net/sched: sch_cake: Add cake_mq qdisc for using cake on mq devices List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Willem de Bruijn writes: > Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Willem de Bruijn writes: >>=20 >> > Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Add a cake_mq qdisc which installs cake instances on each hardware >> >> queue on a multi-queue device. >> >>=20 >> >> This is just a copy of sch_mq that installs cake instead of the defau= lt >> >> qdisc on each queue. Subsequent commits will add sharing of the config >> >> between cake instances, as well as a multi-queue aware shaper algorit= hm. >> >>=20 >> >> Reviewed-by: Jamal Hadi Salim >> >> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen >> >> --- >> >> 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. >>=20 >> 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). >>=20 >> 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. Sure, that's fair. Seems relatively straight forward too: https://git.kernel.org/pub/scm/linux/kernel/git/toke/linux.git/commit/?h=3D= mq-cake-sub-qdisc&id=3Dfdb6891cc584a22d4823d771a602f9f1ee56eeae > 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. Right, I do see what you mean; as I said we did consider this initially, but went with this implementation from a configuration simplicity consideration. If we were to implement this as an option when running under the existing mq, we'd have to add an option to cake itself to opt in to this behaviour, and then deal with the various combinations of sub-qdiscs being added and removed (including mixing cake and non-cake sub-qdiscs of the same mq). And userspace would have to setup the mq, then manually add the cake instances with the shared flag underneath it. Whereas with this cake_mq qdisc the user interface is as simple as possible: just substitute 'cake_mq' for 'cake' if you want the multi-queue behaviour on a device; everything else stays the same. Since configuration simplicity is an explicit goal of cake, I think this is appropriate; although it may not be for other qdiscs. Hope that makes sense? -Toke