On Sun, Aug 24, 2008 at 5:50 PM, David Miller [off-list ref] wrote:

From: Jarek Poplawski <redacted>
Date: Sun, 24 Aug 2008 21:27:34 +0200

quoted

On Sun, Aug 24, 2008 at 09:19:05PM +0200, Jarek Poplawski wrote:
...

quoted

Jamal, maybe I miss something, but this could be like this only with
default pfifo_fast qdiscs, which really are per dev hwqueue. Other
qdiscs, including prio, are per device, so with prio, if a band with
the highest priority is blocked it would be requeued blocking other
bands (hwqueues in Alexander's case).

And, actually, because of this, Alexander is right the prio_dequeue()
can't work like this without any changes.

Yes it can, see my other response.  Only the higher priority
queues filling up can block lower priority traffic, and that
is fine.

Let's get away from the priority discussion because it doesn't have
anything to do with what I am talking about.  One of the main reasons
why I am thinking it might be wise to move this out of the prio qdisc
and spin it off as a qdisc of its own is because what I am trying to
accomplish doesn't care about the priority of the packet.  All I am
concerned with is that this qdisc doesn't block the transmit of any
other hardware queues if one of the hardware queues are blocked and
that all queues have an equal chance to dequeue packets.

What I am planning to implement at this point is a simple multi-band
qdisc that assigns the band number based on queue mapping.  This
combined with something like the rr_dequeue from the original qdisc
will resolve the head-of-line issues.  Essentially it will try to
mimic the way the pfifo_fast qdiscs work with hardware multiqueue, but
it will have the ability to classify traffic and be stuck with one
spin lock for all queues.

I will try to get patches submitted for this new approach to the qdisc
and the new action in the next day or two.  In the meantime we can
probably drop this issue for now since I am in agreement that this
isn't the best approach to resolving this issue.

Thanks,

Alex