From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E0763CB35 for ; Tue, 23 Nov 2021 05:39:47 -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=1637663984; bh=eX40U8tHjSiAng1aPWoQ81HFchV/Wh7szqpf+T7vzqM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=shM+K1OuHqX2sB3wPikYQu9EVkZ3dI3a/hYwmyFfYejT68GcfHZelfzUf211RunSq NRYvN3PsxLt//OIIII0LhL7TjCPIc/I8qAkeyVPF1nOVUjdtM3b6ayEVSsg0AfngKX aFaXakSpPkBoOu1L8DEV2bW4EokuGB5WvUYZZEQmwKgzWpziPtwMRJWhhUoy8RiON0 DcOPhE9iu2qhPUQn/xGRis8PHcndHWergOj8KsSM5b7nc0jJd0SBxLfAzCCiexnuBK Km3oxX1vD0nrrykLcoum/jFWTDYLIrGJDZxCaA4M8qzsGBGP/bUKS3ul4V29a1Bz/b wlcgg4a0PjMAw== To: Sebastian Moeller , Dave Taht Cc: Cake List In-Reply-To: References: <67BC6CC2-F088-4C0D-8433-A09F4AC452FE@gmx.de> Date: Tue, 23 Nov 2021 11:39:44 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87czmrcg0f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 10:39:47 -0000 Sebastian Moeller writes: > Hi Dave, > > On 23 November 2021 08:32:06 CET, Dave Taht wrote: >>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. > IMHO cake works pretty well, with the biggest issue being its CPU > demands. As far as I understand however, that is caused by the shaper > component and there low latency and throughput are in direct > competition, if we want to lower the CPU latency demands we need to > allow for bigger buffers that keep the link busy even if cake itself > is not scheduled as precisely as we would desire or as e.g. BQL > requires. Yes, as link speed increases, batching needs to increase to keep up. This does not *have* to impact latency, as the faster link should keep the granularity constant in the time domain. So experimenting with doing this dynamically in CAKE might be worthwhile, but probably not trivial. And either way, CAKE is still going to be limited by being single core only, and fixing that requires some serious surgery that I seem to recall looking into and giving up at some point :( -Toke