Re: [Cake] tossing acks into the background queue

[Sebastian Moeller <moeller0@gmx.de>]

Hi Toke,


> On Nov 23, 2021, at 11:39, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> 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.

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

Regards
	Sebastian

> 
> -Toke