On Sat, Aug 23, 2008 at 9:49 AM, jamal [off-list ref] wrote:

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

quoted

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.

We have to modify the existing prio qdisc or create a new qdisc in
order to resolve the head-of-line blocking once any of the queues have
stopped.  The new one wouldn't make any changes to the priority of the
packet but instead would only switch it to a separate qdisc based on
the queue_mapping of the skb.

I get the fact that all we would need is a new action to handle the
queue mapping, but in order for that to be an acceptable solution I
still need the qdisc changes.

quoted

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.

I think you missed the email from Dave earlier, either that or I am
not understanding something and if I am feel free to explain.  My
understanding is that when we assign a new qdisc via tc the
qdisc/transmit queues end up with a configuration kind of like what
Dave has on slide 7 at
(http://vger.kernel.org/~davem/davem_seattle08.pdf).  Adding more
queues doesn't resolve anything since I am still going through the
same qdisc regardless of how many queues I have.  The changes to the
dequeue portion of this qdisc are the most important part for this
change since I need them to keep the qdisc from jamming up in a
dequeue/requeue loop if the packet at the head of the qdisc needs to
go to a stopped hardware transmit queue.

cheers,
jamal

Thanks,

Alex