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 D24B13B2A4 for ; Fri, 4 Sep 2020 07:12:02 -0400 (EDT) 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=1599217918; bh=6uuJDMkqdUHxWNukHNbmOwq7sEvCZoroTapeNFXsE/U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bj2cR5WpUBfhP/ZbhejuDrBp82Km6uaKNcZ8/LNS7oCWvc+DphbI3NtVCJigr9iQR UkqjIvGbvn9dNk1R+ZTM4Z1Jcq/pE9nmDLLKCePuPpBtujh7WEU7qvp3abyonZbo7+ 11XRXgOhJ9lcmhhexSUz9wcaTo+t/CsYeyavjm/+exPYkBu9vOiL+zip9czuYznTRC KeIKKcbDinhw83BeivwGAKWoywRZAHwwDU6dj+p6kq7hKbW6jol7YJ1kC4CLkCKnes 5R4VxjLghq10EShVOodrezJi1JzPAzwMSf3NVfuFNvfgGnkceJi0X+tQBk30dm8wC3 dMUP+YYUfXu0A== To: davecb@spamcop.net Cc: bloat@lists.bufferbloat.net In-Reply-To: <8c4212c4-3acb-6616-d9a2-6bef7e65bbad@rogers.com> References: <87mu2bjbf8.fsf@toke.dk> <5DBFB383-13E8-4587-BE49-1767471D7D59@jonathanfoulkes.com> <87r1rliiiw.fsf@toke.dk> <07CD4278-D448-49D2-AC73-9C230EC041DE@jonathanfoulkes.com> <87imcxi4mq.fsf@toke.dk> <877dtbgcc6.fsf@toke.dk> <8c4212c4-3acb-6616-d9a2-6bef7e65bbad@rogers.com> Date: Fri, 04 Sep 2020 13:11:57 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zh65g5j6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] Other CAKE territory (was: CAKE in openwrt high CPU) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 11:12:03 -0000 David Collier-Brown writes: > On 2020-09-03 10:32 a.m., Toke H=C3=B8iland-J=C3=B8rgensen via Bloat wrote > >> Yeah, offloading of some sort is another option, but I consider that >> outside of the "CAKE stays relevant" territory, since that will most >> likely involve an entirely programmable packet scheduler. There was some >> discussion of adding such a qdisc to Linux at LPC[0]. The Eiffel[1] >> algorithm seems promising. >> >> -Toke > > I'm wondering if edge servers with 1Gb NICs are inside the "CAKE stays=20 > relevant" territory? > > My main customer/employer has a gazillion of those, currently reporting > > ** > > *qdisc mq 0: root* > > * > > qdisc pfifo_fast 0: parent :8 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1=20 > 1 1 1 > > ... > > * > > because their OS is just a tiny bit elderly (;-)). We we're planning to=20 > roll forward this quarter to centos 8.2, where CAKE is an option. > > It strikes me that the self-tuning capacity of CAKE might be valuable=20 > for a whole /class/ of small rack-mounted machines, but you just=20 > mentioned the desire for better multi-processor support. > > Am I reaching for the moon, or is this something within reach? As Jonathan says, servers mostly have enough CPU that running at 1gbps is not an issue. And especially if you're not shaping, running CAKE in unlimited mode should not be an issue. However, do consider what you're trying to achieve here. Most of the specific features of CAKE are targeting gateway routers. For instance, for a server you may be better off with sch_fq to also get efficient pacing support. Depends on what the server is doing... But please, get rid of pfifo_fast! Anything is better than that! ;) -Toke