From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Sebastian Moeller <moeller0@gmx.de>, Dave Taht <dave.taht@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] tossing acks into the background queue
Date: Tue, 23 Nov 2021 11:39:44 +0100 [thread overview]
Message-ID: <87czmrcg0f.fsf@toke.dk> (raw)
In-Reply-To: <BFE5D61E-ED29-4AA3-816C-A8F0947EFDD7@gmx.de>
Sebastian Moeller <moeller0@gmx.de> writes:
> Hi Dave,
>
> On 23 November 2021 08:32:06 CET, Dave Taht <dave.taht@gmail.com> 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
next prev parent reply other threads:[~2021-11-23 10:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 5:03 Dave Taht
2021-11-23 7:07 ` Sebastian Moeller
2021-11-23 7:17 ` Dave Taht
2021-11-23 7:32 ` Dave Taht
2021-11-23 7:33 ` Dave Taht
2021-11-23 8:06 ` Sebastian Moeller
2021-11-23 8:27 ` Dave Taht
2021-11-23 9:03 ` Sebastian Moeller
2021-11-23 10:39 ` Toke Høiland-Jørgensen [this message]
2021-11-23 11:31 ` Sebastian Moeller
2021-11-23 12:12 ` Toke Høiland-Jørgensen
2021-11-23 15:12 ` Dave Taht
2021-11-23 15:49 ` Toke Høiland-Jørgensen
2021-11-23 7:35 ` Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czmrcg0f.fsf@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox