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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
