From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmail.com; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmail.com policy.dmarc=quarantine Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by mail.toke.dk (Postfix) with ESMTPS id 20B1E9E17C4 for ; Sat, 29 Nov 2025 17:56:18 +0100 (CET) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-786a822e73aso27170157b3.3 for ; Sat, 29 Nov 2025 08:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764435377; x=1765040177; darn=lists.bufferbloat.net; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yyK1frpIkqMT8VKh9JIYl1DpSkJ3TM9bY2MXFN6WCgQ=; b=c1Py2d7UIH9adlmzPRdlc1zUdpnHc7Rf1xmEUlHZKSCoQvDXclYKRiaecHBWxtjecy o2nZcA8rFMu6S1ubZSqvWOUHkk0Dp1YRRbbH2uzIdFkb5irlxQci1bP3MTZDh5PDNR9D bFkUXXIPHNJDTCuxcEkW1Dz+6SU2A7cYDrN9U1a5pOyGvdazsICsB5DOtdJG+G7R0gEw GWJHPxXDXsH8vkLuoxpNOf06bWZzHCpI89UNVqwhwZEcjtAt7Cf3MOGyLDlIJsfgGpVO wT5yulg3HEm/hlzvQ/0W6rTs6vCCwX2xW+LYup0KgJ6J4tvTrT7T9E2RK9eQBYjmomw3 nmWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764435377; x=1765040177; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yyK1frpIkqMT8VKh9JIYl1DpSkJ3TM9bY2MXFN6WCgQ=; b=DwDl8M3RuQqdRhAggbfAZvQCHfAHd4A3ErN29XAG/bZnxjTArwlqi3J9pOu+C22asw GMkSWEjfiBGJHvI8iXMiFssfvNyJk03S1E5SmHfkrkw6FUBj+pP1Sx4cBITVufmdl/W1 miOUMVDF45RG/fVcpeoi6Q7gNoKbNHUSvYc82irrDeAcLKfdYfT9mflUtyBBvJ2Qo/xa p8EBpLW0yXaF41irCnXvGT4zfCB/0iCtwvU56zgSVYoSJ1Yh0KY0NNd/SbFNgzD9KgAr 1PkxpciGcZVzp3GZdvnpWPpZGIal/v/ChDpbR+c0TWzCmIeGAGfcSB7Np20Lt6NYqJr2 vHFg== X-Forwarded-Encrypted: i=1; AJvYcCXMtqMhb94CRTvAAfX3V2cJmCw4go9py4YDSsHzIZ5CjHeMbqdzSaB9tY3syv4i6bJzfN4d@lists.bufferbloat.net X-Gm-Message-State: AOJu0YzyFpcIgrYR6l8DykLPtjJM9IiYNWzJYRkVkfGLA0FPEJR7dEcx ugKk4Ed5uGFdj8p2a3OB5RNEQnQZ3DvjAtYGO8DkjabadKaCytrvTUPz X-Gm-Gg: ASbGncv6EehfB8HYMzC3BuL7MSKWYOvRdPo3/ZCHMNqbyIT50y6xBIwxa6R1z6SZqvk FVM7FjfdMtICDyK/oIkMCww8BK12pBppPLAERJ9kLjUyz38G8tfcmwAHp3mfHvLFcBKeJUqRJKa 5BKIaJTOFOsFPydG41E535aNV7Rh3ozndaxHVtNLfZWVTPrtXqnzoeaCK/H4PszI5JYyYzE8ZGZ WqmmjRpY6vrFXrMd7bsR59TI0QITv91gzQUMAQWKzzf26RgaEitdvH6I9GT4Dn/CiACGB2gHlTJ /QCmIs5XTbIVC9TkvRJeFHtF9O8oKASJcILMczKrt24M9/tTzfqQxxp4npUHthV86S0mGnUrPLZ bBw0T+luitQht6YVHe+atODF0UPVWVeg6XiZlJ5Ie8RkpBtUKLKczafmuuhWldN3xouMq9SzoTW QEs6JtRAZyOooxL69TbEY/AljBywlsEZFAjE1nfRnzBUR1o2meJn8d6nsHsrgBkPBex7c= X-Google-Smtp-Source: AGHT+IEcrQRp4ITJhrH7YWzMD2/YwlxTQu831k+ljd/SPFUJAFFJTOlxkBAmUUm8nJcxZVwXYw0omQ== X-Received: by 2002:a05:690c:f8f:b0:786:5712:46c4 with SMTP id 00721157ae682-78a8b495420mr279788797b3.27.1764435377025; Sat, 29 Nov 2025 08:56:17 -0800 (PST) Received: from gmail.com (116.235.236.35.bc.googleusercontent.com. [35.236.235.116]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-78ad0d5fefbsm27621837b3.20.2025.11.29.08.56.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Nov 2025 08:56:16 -0800 (PST) Date: Sat, 29 Nov 2025 11:56:15 -0500 From: Willem de Bruijn To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Willem de Bruijn , Jamal Hadi Salim , Cong Wang , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: =?UTF-8?B?Sm9uYXMgS8O2cHBlbGVy?= , cake@lists.bufferbloat.net, netdev@vger.kernel.org Message-ID: In-Reply-To: <87a505b3dt.fsf@toke.dk> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MailFrom: willemdebruijn.kernel@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation Message-ID-Hash: TJJLHTORGOGZVXBC3WHKIR5TQAHVX6ZY X-Message-ID-Hash: TJJLHTORGOGZVXBC3WHKIR5TQAHVX6ZY X-Mailman-Approved-At: Sat, 29 Nov 2025 18:45:46 +0100 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: Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Willem de Bruijn writes: > = > > 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. > >> = > >> This is just a copy of sch_mq that installs cake instead of the defa= ult > >> qdisc on each queue. Subsequent commits will add sharing of the conf= ig > >> between cake instances, as well as a multi-queue aware shaper algori= thm. > >> = > >> 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. > = > 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.