[Cake] Cake upstream Planning

[Pete Heist]

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

https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf

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