[Cake] tossing acks into the background queue

Sebastian Moeller moeller0 at gmx.de
Tue Nov 23 06:31:56 EST 2021

Hi Toke,

> On Nov 23, 2021, at 11:39, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Sebastian Moeller <moeller0 at gmx.de> writes:
>> Hi Dave,
>> On 23 November 2021 08:32:06 CET, Dave Taht <dave.taht at 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.

Fair point. My other reason for wanting to expose this is to allow easier experimentation, but I can be expected to build from modified sources so that is rather weak.

> 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.

	I had sort of ignored that ISPs generally do not offer, fair sharing of a link's capacity between all connected users ;)

>> 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.

	Yes, all the way through the stack.

> This does not *have* to impact latency, as the faster link should keep
> the granularity constant in the time domain.

	Nit-pick: any batching impacts latency compared to perfect just in time processing, just some impact can easily be accepted/tolerated ;)

> So experimenting with doing
> this dynamically in CAKE might be worthwhile, but probably not trivial.

	We tried to do the same for HTB/fq_codel and testing was a bit inconclusive (then again, affected users where not to dedicated in testing)

> 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 :(

	That is sad, and pretty much rules out that I could make some progress in that direction. The next level is shaping at ~1Gbps, even though faster access links become available, like 8.5/10 Gbps (XGS-PON is nominally 10G, but after FEC only ~8.5 Gbps actually are usable) or for a lucky few even 25 Gbps ...


> -Toke

More information about the Cake mailing list