From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B7B603B29D for ; Tue, 23 Nov 2021 10:49:36 -0500 (EST) 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=1637682572; bh=vBEHrkF6DWvC06vXFXeq+LzagUhxzJGQkr+wCuuKQY0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BwSaNb3zoO/VmI/yVG6Sfmr7YczqyXfGUqhdYijH+mnIrZb6u+F0CQJO7uWj+3SZg QeajNkQc3I5FQhp5Hit5Oa5BBSNE85k/IPbR/5Lz0ghi/P0J6f6nQCiBgyQiq+fUq1 GZwvm53B1JsoNbXWVwhR+94JPKJQcebCWRmQTufOoPubaoLhvib3svN26909eG4+NZ +AEYEAcoMG9cxwSCht1bAGc7VaxlNxvyJkxKfcZj8jRPXyO7cG1IhhGdckyeiwym2X 6yrZf7Hbd90KdXN8ZoP3qTzyKvcPU20tp4yAxbNX7Ylx+P5+vZbMEGDfncr/i9004A v8Mhp2FZQ+/WQ== To: Dave Taht Cc: Sebastian Moeller , Cake List In-Reply-To: References: <67BC6CC2-F088-4C0D-8433-A09F4AC452FE@gmx.de> <87czmrcg0f.fsf@toke.dk> Date: Tue, 23 Nov 2021 16:49:31 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874k82dg8k.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] tossing acks into the background queue X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 15:49:36 -0000 Dave Taht writes: > On Tue, Nov 23, 2021 at 2:39 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Sebastian Moeller writes: >> >> > Hi Dave, >> > >> > On 23 November 2021 08:32:06 CET, Dave Taht wrot= e: >> >>The context of my question is basically this: >> >> >> >>Is cake baked? Is it done? >> > >> > How about per MAC address fairness (useful for ISPs and to treat >> > IPv4/6 equally)? >> > >> > How about configurable number of queues (again helpful for ISPs)? >> >> FWIW I don't think CAKE is the right thing for ISPs, except in a >> deployment where there's a single CAKE instance per customer. For >> anything else (i.e., a single shaper that handles multiple customers), >> you really need hierarchical policy enforcement like in a traditional >> HTB configuration. And retrofitting this on top of CAKE is going to >> conflict with the existing functionality, so it probably has to be a >> separate qdisc anyway. > > What progress has been made on breaking the HTB locks in the last few > years? None. Don't see that happening any time soon; just the simple pfifo_fast qdisc is uncovering all kinds of bugs when running in lockless mode. Jesper basically solved the contention issue by partitioning the traffic and running multiple instances: https://github.com/xdp-project/xdp-cpumap-tc Doesn't work for bandwidth sharing across instances, though, so it solves the ISP "separate rates per customer" case, but not the CAKE "shape a single link" case. > Given the enormous number of hw tx/rx queues we see today (64+ on > 10gbit), trying to charge off > bandwidth per queue in a cake-derived shaper and protecting the merge > with rcu seemed plausible... Yeah, that was what I was going to try, but it turned out to be decidedly non-trivial to make sch_cake itself mq-aware, so I gave up. My hope is that this will be possible once we get sch_bpf, so we can just have separate instances but they can share a single atomic var for the bandwidth sync... -Toke