Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

[jamal <hadi@cyberus.ca>]

On Sun, 2008-24-08 at 09:53 +0200, Jarek Poplawski wrote:
> On Sat, Aug 23, 2008 at 12:09:42PM -0700, Alexander Duyck wrote:
 
> > 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.
> 
> I guess, Jamal meant additional, backup queues, 

right; in the driver - but even that may be unnecessary.
With current controls being per qdisc instead of per netdevice,
the hol fear is unfounded. 
You send and when hw cant keep up, you block just the one hwqueue.
While hwqueue is blocked, you can accumulate packets in the prio qdisc
(hence my statement it may not be necessary to accumulate packets in
driver).
On tx completion when hwqueue has more space, you check your backup
queues; and send those first before opening up path from above. 

And to your other statement; if you use basic skb->priority to hwqueue
mapping, then you wouldnt need an extra action. 

cheers,
jamal