From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=tu-berlin.de header.i=@tu-berlin.de header.a=rsa-sha256 header.s=dkim-tub26 header.b=TasZRy7c; arc=none (Message is not ARC signed); dmarc=none Received: from mailrelay.tu-berlin.de (mailrelay.tu-berlin.de [130.149.7.70]) by mail.toke.dk (Postfix) with ESMTPS id B677D19127DB for ; Mon, 26 Oct 2026 09:35:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=tu-berlin.de; s=dkim-tub26; t=1793003740; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=t5aVGQFnIo2fbR/ym25z3W3C+Yluhz2Oy30vSlBhxGY=; b=TasZRy7c0+XKSMXnKkKw02pthwb9cknUda+Vi5JgnuOHHP/zHr05bXAg nBzoJ9YF5D4Ipux5R0YkMWQyjPEwrAAze5MQcSgeWRKRrTqKieMyDDmZ1 oBaKkti7ZBzJJRGGF/hf29E01Mfk8k9pINDNF9WzQkMGeRUsSpebW3URi oCUpQSt1AMqyQR01U7kCfkoy7/wz9UqwOUMiFINXsDdXYObEP6I8EW3Iu QZPngDnC5kT4ob/kKDbMhMaeQH5VrOi+BRgdI4vTyM/yhueWHsaUYb5Mo FLzUWDuXkzTb0GwM6xCGPfqA35IYbcSA/Nt3pMwSQAqHzAysoeuC9BHU9 g==; X-CSE-ConnectionGUID: zBdUs2ZiRfO1z7KXzqHd4w== X-CSE-MsgGUID: jEwqq7qaS4yR3m1RQByAfA== X-IronPort-AV: E=Sophos;i="6.27,179,1787004000"; d="scan'208";a="53777538" Received: from bulkmail.tu-berlin.de (HELO mail.tu-berlin.de) ([141.23.12.143]) by mailrelay.tu-berlin.de with ESMTP; 26 Oct 2026 09:35:39 +0100 Message-ID: <3625cee3-3643-4ef8-808d-2fe8267593fd@tu-berlin.de> Date: Mon, 26 Oct 2026 09:35:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "Shubhang Kaushik (Ampere)" , =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Jamal Hadi Salim , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shubhang Kaushik , "Christoph Lameter (Ampere)" CC: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , , , References: <20261025-net_sched_sch_cake-v1-1-5165c924a590@gentwo.org> Content-Language: en-US From: =?UTF-8?Q?Jonas_K=C3=B6ppeler?= In-Reply-To: <20261025-net_sched_sch_cake-v1-1-5165c924a590@gentwo.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: FTZPIOESNSDJVR5GQIN6SQTX2HXEGNNA X-Message-ID-Hash: FTZPIOESNSDJVR5GQIN6SQTX2HXEGNNA X-MailFrom: j.koeppeler@tu-berlin.de 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/sched: sch_cake: skip redundant cake_mq rate updates List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 10/25/26 9:38 PM, Shubhang Kaushik (Ampere) wrote: > cake_mq periodically counts active child qdiscs in cake_dequeue() and > derives an effective per-child shaper rate. cake_dequeue() currently > reconfigures every tin after each scan, even when that effective rate > is unchanged. > > The dequeue-time call chain is: > > cake_dequeue() > -> cake_configure_rates(..., true) > -> cake_config_*() > -> cake_set_rate() > > With rate_adjust=true, cake_set_rate() only refreshes rate-derived > state. Tin 0 records the unscaled rate argument in every supported > CAKE tin mode, so its installed rate identifies whether this call chain > would change any state. > > Skip the reconfiguration when the effective rate is already installed, > while continuing to update the activity-sampling timestamp and > active-queue statistic. > > Fixes: 1bddd758bac2 ("net/sched: sch_cake: share shaper state across sub-instances of cake_mq") > Signed-off-by: Shubhang Kaushik (Ampere) > --- > Tested on an 80-core SMP, non-SMT Ampere Altra system (aarch64) > The test used a 32-TX-queue veth pair, with cake_mq > bandwidth 2gbit on the transmit side and the peer in a network > namespace. The workload was: > > iperf3 -c 198.18.0.2 -P 32 -t 30 > > Validation against mainline commit a32e63a613aa80, the patched kernel > reduced cake_configure_rates() calls by 99.99% (2,477,627 to 206) and > aggregate helper time by 99.986% (3.477 s to 0.498 ms), while retaining > approximately 1.91 Gbit/s aggregate throughput (baseline: > 1.91-1.92 Gbit/s). A separate per-child trace observed no > same-effective-rate calls on the patched kernel (@unchanged: 0). > Changing cake_mq bandwidth from 2Gbit to 1Gbit and back invoked > cake_configure_rates() 64 times, matching all 32 child CAKE qdiscs > updated for each of the two control-plane changes. > --- > net/sched/sch_cake.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c > index aa4043d662c1cc18858d3f9c80f9d9b281f26f72..dd2539cb472087af9a96b74f2ac571eb8b0a8a27 100644 > --- a/net/sched/sch_cake.c > +++ b/net/sched/sch_cake.c > @@ -2052,7 +2052,8 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch) > if (num_active_qs > 1) > new_rate = div64_u64(new_rate, num_active_qs); > > - cake_configure_rates(sch, new_rate, true); > + if (new_rate != READ_ONCE(q->tins[0].tin_rate_bps)) > + cake_configure_rates(sch, new_rate, true); Thanks! Yes, I think the idea is right. I think we could even omit the READ_ONCE. Best Jonas> q->last_checked_active = now; > WRITE_ONCE(q->active_queues, num_active_qs); > } > > --- > base-commit: a32e63a613aa80dfdb9acc0a09efab940e96054f > change-id: 20261025-net_sched_sch_cake-e6653fd393d6 > > Best regards,