From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30CF534BA2D for ; Mon, 13 Oct 2025 11:40:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.145.95.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760355658; cv=none; b=SQFGJ4mDvcdOLcHNeNAHWtU66O6jFelzoY5CmLOp/te+ZRPxQXjY4wfNYGjwkBfV3dF4sXrX1I0NJ6HSI1NGz9TPAOGWmDlvuTsMMTu76+6/VTSni3p1ITdRKPHIt+soqtF8U84pHTjJk+CIxuhkjDnmevDS25vpWIse2UY7zFw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760355658; c=relaxed/simple; bh=uk4LKFdpJMLTA/xiRvdkdBXYjWK9L0XEP4+c/M0T/fk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=T/ub0yuVI9xhTzZTB9o96CkPL636h9od5IRXM/Dk33+cu0Ebh3KyNnAilzMZjCPaFoHzsJHWtx3sEpMRsHNkVhRsMttITPNZMwybCgGQT09H6+qky6asnMVOesv/UQrBatAnF5O4axgSvvCZEUjVkBY5jw/e/n/4QKxVBoAhCtM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=toke.dk; spf=pass smtp.mailfrom=toke.dk; dkim=pass (2048-bit key) header.d=toke.dk header.i=@toke.dk header.b=B82ARk1c; arc=none smtp.client-ip=45.145.95.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=toke.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=toke.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=toke.dk header.i=@toke.dk header.b="B82ARk1c" 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 Subject: Re: [PATCH RFC net-next 0/4] Multi-queue aware sch_cake 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> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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