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=1760355108; bh=uk4LKFdpJMLTA/xiRvdkdBXYjWK9L0XEP4+c/M0T/fk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=B82ARk1c4axhPbU2bRBFeaEr9DHHTMrHNed3QO6WxnZcMtnDSow14VWSWARUAxMwl hGm7Cr3Zr2aGcKsfqQBYLJ/MqviNKLLPWEgBB3DDhiC1yr2gsuGknSJWihI8vDMuwx GdBrUeNYTtcSyOkTb8YOo9Iur4/RiOCad14Ktz4UL9SLwkF3YQp3VTpsdAhvPQJU4N Z7MbHJ0TwXxegEbvckhlKVYQSgXUu8EsVtKl3h8XfqDgQx/WjmPgmAEVEL5HU6Wom5 xDtus4FcZGJKnuqp8rmppxry88h/jf00/9vQzVLJatX3FICPzxelgKNw9wQopyVZb2 YUF5wfDaBLIRg== To: Jamal Hadi Salim Cc: Cong Wang , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonas =?utf-8?Q?K?= =?utf-8?Q?=C3=B6ppeler?= , cake@lists.bufferbloat.net, netdev@vger.kernel.org In-Reply-To: References: <20250924-mq-cake-sub-qdisc-v1-0-43a060d1112a@redhat.com> Date: Mon, 13 Oct 2025 13:31:48 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87v7kj597f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WMMFPKKAGZIAGA2DE5HHZBZU4P5POWEQ X-Message-ID-Hash: WMMFPKKAGZIAGA2DE5HHZBZU4P5POWEQ 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 RFC net-next 0/4] Multi-queue aware sch_cake List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Jamal Hadi Salim writes: > On Wed, Sep 24, 2025 at 8:16=E2=80=AFAM Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >> >> This series adds a multi-queue aware variant of the sch_cake scheduler, >> called 'cake_mq'. Using this makes it possible to scale the rate shaper >> of sch_cake across multiple CPUs, while still enforcing a single global >> rate on the interface. >> >> The approach taken in this patch series is to implement a separate qdisc >> called 'cake_mq', which is based on the existing 'mq' qdisc, but differs >> in a couple of aspects: >> >> - It will always install a cake instance on each hardware queue (instead >> of using the default qdisc for each queue like 'mq' does). >> >> - The cake instances on the queues will share their configuration, which >> can only be modified through the parent cake_mq instance. >> >> Doing things this way does incur a bit of code duplication (reusing the >> 'mq' qdisc code), but it simplifies user configuration by centralising >> all configuration through the cake_mq qdisc (which also serves as an >> obvious way of opting into the multi-queue aware behaviour). >> >> The cake_mq qdisc takes all the same configuration parameters as the >> cake qdisc, plus on additional parameter to control the sync time >> between the individual cake instances. >> >> We are posting this series to solicit feedback on the API, as well as >> wider testing of the multi-core shaper. >> >> An earlier version of this work was presented at this year's Netdevconf: >> https://netdevconf.info/0x19/sessions/talk/mq-cake-scaling-software-rate= -limiting-across-cpu-cores.html >> >> The patch series is structured as follows: >> >> - Patch 1 factors out the sch_cake configuration variables into a >> separate struct that can be shared between instances. >> >> - Patch 2 adds the basic cake_mq qdisc, based on the mq code >> >> - Patch 3 adds configuration sharing across the cake instances installed >> under cake_mq >> >> - Patch 4 adds the shared shaper state that enables the multi-core rate >> shaping >> >> A patch to iproute2 to make it aware of the cake_mq qdisc is included as >> a separate patch as part of this series. >> > > For this version of the patchset > Reviewed-by: Jamal Hadi Salim Thanks! > Q: Does Eric's riddance of busylock help? Good question! Probably not for cake_mq usage itself, but maybe it'll change the baseline? We'll test this before sending a non-RFC :) -Toke