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

["Alexander Duyck" <alexander.duyck@xxxxxxxxx>]

On Sun, Aug 24, 2008 at 5:50 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Jarek Poplawski <jarkao2@xxxxxxxxx>
> Date: Sun, 24 Aug 2008 21:27:34 +0200
>
>> On Sun, Aug 24, 2008 at 09:19:05PM +0200, Jarek Poplawski wrote:
>> ...
>> > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html