[Cake] cake verses hardware multiqueue

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

Nearly all the latest hardare has hardware multiqueue, which is
usually useful in gaining some benefit from natively fq-ing flows, but
also (due to the limited number of queues), tends to show severe
birthday problems.

Hardware multiqueue is also of benefit when

A) there is a mapping from the hardware queues to the cpus IRQ
handler(s) so they can be serviced in parallel.

B) when the queues can prioritize

It is generally unclear if hardware multiqueue on ethernet is
implemented as a priority queue of any sort. (it is on wifi, and
sorting out which better qdisc to select for each device type is a
longstanding issue)

It has been shown (old eric dumazet post) that we can often get better
results to have a single qdisc, rather than one per hardware queue, to
keep control of the BQL queues in the implementation, so long as the
single interrupt can be adaquately handled by one cpu.

C) Cake - at line rate - could spread it's diffserv markings across
the existing hardware queues also to get priority (if the hardware
queues supported that, rather than fairness.)  This would mitigate a
bit against excessive BQL.

D) mvneta and the ethernet device in the rangeleys are both hardware
multiqueue. I believe the mvneta has 16 queues, and perhaps it would
be better to have one cake instance per cpu to drive those
multiqueues, instead. We would save on dcache, in particular.

E) Drivers could also specify a different qdisc at instantation time,
rather than the default from the sysctl, or mq + the default
sysctl. "cakemq"


-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67