On Sat, 2008-23-08 at 09:31 -0700, Alexander Duyck wrote:

Actually in this new multiple tx queue kernel this qdisc could serve a
very specific but needed purpose which just became apparent to me.
This qdisc resolves one very specific issue, head-of-line blocking if
one of the hardware queues is full.  What if I reversed things a bit
in prio_classify so that skb->queue_mapping determined the band
instead of the other way around in the case of the multiqueue option
being enabled?  I would think that in this configuration the qdisc
would prove to be pretty useful for purposes other than QOS since it
would allow a classful qdisc per transmit queue instead of per device.

i think thats whats Dave is saying not in so many words.

prio_classify calls classifiers.
dont modify the qdisc; rather do a classification which when matched
sets skb->queue_mapping to a value your policy likes it to be.  
you dont need a new classifier, u32 would do for example. or ematch if
you want to do some funky things. you will need a new action which sets
the skb->queue_mapping.

I could then create a select_queue for the device that returns 0 when
in DCB/EEDC mode for our drivers, implement the tc action to set the
queue mapping, and have essentially the same result as I had before.

put overflow queues in your driver. With the new multiq approach the
controls are per-queue not per driver.

cheers,
jamal