[Bloat] stochastic hashing in hardware with a limited number of queues

[Dave Taht <dave.taht@gmail.com>]

The thread on netdev starting here:

http://comments.gmane.org/gmane.linux.network/307532

was pretty interesting, where a research group at suny looked hard
at the behavior of a 64 hw queue system running giant flows:

http://www.fsl.cs.sunysb.edu/~mchen/fast14poster-hashcast-portrait.pdf

They ran smack into the birthday problem inherent in a small number
of queues. And also a bug (now fixed).

The conclusion of the thread was amusing, in that with the new
sch_fq scheduler with a single hardware queue (and a string
of fixes over the past year for tcp small queues and tso offloads),
performed as well as the multi queue implementation... with utter
fairness.

"On Sun, Mar 9, 2014 at 9:44 AM, Eric Dumazet <eric.dumazet <at>
gmail.com> wrote:
>
> Multiqueue is not a requirement in your case. You can easily reach line
> rate with a single queue on a 10Gbe NIC.
>

I repeated the experiment for 10 times using one tx queue with FQ, and
all clients get fair share of the bandwidth. The overall throughout
showed no difference between the single queue case and the mq case,
and the throughput in both cases are close to the line rate.
"

Sometimes merely because a feature is available on the hardware
does not mean it should be used. Certainly multiple hw queues is
a good idea for some traffic mixes, but not for the circumstances of
this particular test series.


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html