[Cake] Cake upstream Planning

Pete Heist peteheist at gmail.com
Thu Nov 16 13:40:24 EST 2017

> On Nov 16, 2017, at 5:31 PM, Dave Taht <dave at taht.net> wrote:
> Pete Heist <peteheist at gmail.com <mailto:peteheist at gmail.com>> writes:
>>>>   On Nov 15, 2017, at 9:04 PM, Dave Taht <dave at taht.net> wrote:
>>>>   Dave Taht <dave at taht.net> writes:
>>> https://github.com/ffainelli/bqlmon was a tool for looking at bql more
>>> directly.
>>> I had forked it for some reason or another:
>>> https://github.com/dtaht/bqlmon
>> Nice, that does work for me. It’s interesting that there are four queues for the
>> igb driver, 00 - 03, and when I try an rrul_be_nflows test, not all four queues
>> are necessarily used. Once I get >= 8 flows in each direction they usually are
>> though. I suppose this is the driver deciding when to start using another queue
>> or not.
> Usually it is selected via a hash. In more than a few cases, however,
> the designer of the hardware intended it as a strict priority queue. In
> other cases, it's based on the CPU.
> In all cases such a limited number of queues tends to cause oddities.
> I think it was the mvneta (?) that had the strict priority queue idea baked
> into it, which we ended up disabling entirely and going with just one
> hardware queue.

I noticed when I went to buy the APU2 that the two lower-end models (apu2c2 and apu2c0) have I211 NICs instead of a I210. The I211 is a “value part” that among other things has 2 tx and rx queues per port instead of 4. I wasn’t sure of the real effect of this when I purchased them, but for an extra few bucks the I210 seemed worth it. Table 1-6 on page 13:


>> Cake does seem to visibly reduce the size of the queues.
> I generally observe that TSO/GRO/etc tends to make BQL's queues 3-5
> times larger than they are without those offloads - no way to fix it,
> short of doing what cake does to peel those apart.

A real nicety of Cake that the world should benefit from.

>> For whatever
>> terminal/ncurses weirdness reason though, the bar graphs may be sometimes
>> blowing off the top of my 45 row screen, but it doesn’t entirely ruin the
>> experience.
> Maybe that was why I forked it?

Looks like you forked it to fix a multi-queue problem. I forked your fork to add a scaling parameter to fix the bar height. -s 4096 works well for me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171116/4e82fb53/attachment.html>

More information about the Cake mailing list