From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com
[IPv6:2607:f8b0:4864:20::f32])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by lists.bufferbloat.net (Postfix) with ESMTPS id 8B98B3B29E
for ; Thu, 3 Sep 2020 18:14:52 -0400 (EDT)
Received: by mail-qv1-xf32.google.com with SMTP id f11so2119484qvw.3
for ; Thu, 03 Sep 2020 15:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:reply-to:subject:to:references:cc:message-id:date:user-agent
:mime-version:in-reply-to:content-language;
bh=yUJNVmrm9/FNXNeZ/X0/PcdA0bd1s3L/tr1vVK7NxZ4=;
b=kcZ0byV07IvoP+zzLEOJsnJVXzQq5Wqym2bP7D4PII8THG8UyTITUfz1IfIXkFjCY4
7yFhimGAelIJdFZO5dAbJdVcgA0H0JBVt6nZbJpC0W3O7fDlCzqBpuqFsViQNUMERVyD
W/iQT/oohsLZgUrl2wzMolnaHBc4khXYEn0J3FrDtCFsAj6pnXUW8nhxcHJS5siWcJEO
eeGfsVZF+t4WpZsGTv6YtF3D22xyBGJkaidPKMsK8Iy2448TSTy6yhez8UROhKV3+lIx
P7QNhbFS3XRgNUvcogyNrs1LYIUtMXYQzKx3UddB8scEG1Ux3MKMu5d50+AxaH9cmlW9
qV2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:reply-to:subject:to:references:cc
:message-id:date:user-agent:mime-version:in-reply-to
:content-language;
bh=yUJNVmrm9/FNXNeZ/X0/PcdA0bd1s3L/tr1vVK7NxZ4=;
b=H5AqGJo+dOg2j7fcrEVvg1zqFBGp4VNBX6jT4i9jhJPUYZFUwu++Uz4keSyg2MFOqN
1ndzpOTeoWJejxr7Ui+ozcGwH7hnFIQNRtkdeI0Q0/MplVnVFGfN5r19o9gqugCCeKe7
Lj5+G/pKzNTwg0ywQ4mi2p9BYe+S1/rhbbbgOHIGZtrwUu7dc5cRnrIJQfam+s59+sE/
fq0Od+kd+NiUqffXV0LzErIghzNhVDdMmaG0+5zPQD49RprmtmMYYFAuRhzj+lKgepZx
ZamPPjqB+aq5uUG+gO80qDwoMkH5bsUgbpoyyWbqM8ow5IAt0uAc5mqasuYqK/BGG8AW
EpTQ==
X-Gm-Message-State: AOAM530fA2Ue5Fcdv4uS9mbIwcS3K9SdCPGfZRKlDde0nPrHRcieUBKa
ipXH4W75XZGq1ZKLG7cZwVDqVOL2yvg=
X-Google-Smtp-Source: ABdhPJwy/6EID0k2iw71a5IFjrkQFQzmhMUxtjY3GJX7AC+W5B8KUnafWn5PN3R5jyUQn/JrBQE4kw==
X-Received: by 2002:a05:6214:292:: with SMTP id
l18mr3993307qvv.3.1599171291944;
Thu, 03 Sep 2020 15:14:51 -0700 (PDT)
Received: from ?IPv6:2607:fea8:561f:e34d::966b? ([2607:fea8:561f:e34d::966b])
by smtp.gmail.com with ESMTPSA id
k63sm3068332qkf.33.2020.09.03.15.14.50
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 03 Sep 2020 15:14:51 -0700 (PDT)
From: David Collier-Brown
X-Google-Original-From: David Collier-Brown
Reply-To: davecb@spamcop.net
To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?=
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>
Cc: bloat@lists.bufferbloat.net
Message-ID: <8c4212c4-3acb-6616-d9a2-6bef7e65bbad@rogers.com>
Date: Thu, 3 Sep 2020 18:14:49 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <877dtbgcc6.fsf@toke.dk>
Content-Type: multipart/alternative;
boundary="------------E6C57DC974DCF4B7D7799673"
Content-Language: en-US
Subject: [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: Thu, 03 Sep 2020 22:14:52 -0000
This is a multi-part message in MIME format.
--------------E6C57DC974DCF4B7D7799673
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 2020-09-03 10:32 a.m., Toke Høiland-Jørgensen 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
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
1 1 1
...
*
because their OS is just a tiny bit elderly (;-)). We we're planning to
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
for a whole /class/ of small rack-mounted machines, but you just
mentioned the desire for better multi-processor support.
Am I reaching for the moon, or is this something within reach?
--dave
--
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain
--------------E6C57DC974DCF4B7D7799673
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
On 2020-09-03 10:32 a.m., Toke Høiland-Jørgensen 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 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 1 1 1
...
because their OS is just a tiny bit elderly (;-)). We we're
planning to 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 for a whole class of small rack-mounted machines,
but you just mentioned the desire for better multi-processor
support.
Am I reaching for the moon, or is this something within reach?
--dave
--
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain
--------------E6C57DC974DCF4B7D7799673--