[Bloat] Other CAKE territory (was: CAKE in openwrt high CPU)

Toke Høiland-Jørgensen toke at toke.dk
Fri Sep 4 07:11:57 EDT 2020


David Collier-Brown <davecb.42 at gmail.com> writes:

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

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


More information about the Bloat mailing list