> On Nov 16, 2017, at 5:31 PM, Dave Taht wrote: > > Pete Heist > writes: > >>>> On Nov 15, 2017, at 9:04 PM, Dave Taht wrote: >>>> >>>> >>>> Dave Taht 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.