[Cake] Cake upstream Planning

[Dave Taht]

Pete Heist <peteheist at gmail.com> writes:

>     On Nov 16, 2017, at 5:31 PM, Dave Taht <dave at taht.net> wrote:
>
>     
>     Pete Heist <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.

At a rather large cpu cost.

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

I put in a pull request with all the outstanding patches to the
maintainer. Should have done that 2+ years ago.