On Sat, Aug 23, 2008 at 9:49 AM, jamal <hadi@cyberus.ca> wrote:
quoted text
> 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.

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

quoted text
> cheers,
> jamal
>

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html