On Sat, Aug 23, 2008 at 1:47 AM, Jarek Poplawski [off-list ref] wrote:

On Fri, Aug 22, 2008 at 05:33:48PM -0700, David Miller wrote:
...

quoted

If we want queue selection in the packet scheduler, let's implement
it, but let's do so properly using classifiers and TC actions or a
ematch modules that can select the queue.

Then people can implement whatever policy they want, in completely
generic ways, and the kernel simply doesn't care.

The way this code worked was completely special purpose and ignored
the host of facilities and infrastructure we have for doing things
like this.

Alas I can't get your point here. prio is sched + classifier 2 in 1,
and if a small change in this is enough for somebody who really uses
this, and there seem to be noone interested in doing this better or
harmed with this, why bother with actions or other classifiers? Maybe
this prio method is less generic, but it's quite simple and there is
some infrastructure around this.

Jarek P.

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 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.

Thanks,

Alex