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

[Jarek Poplawski <jarkao2@gmail.com>]

On Sun, Aug 24, 2008 at 08:03:11PM -0700, Alexander Duyck wrote:
> On Sun, Aug 24, 2008 at 5:50 PM, David Miller <davem@davemloft.net> wrote:
> > From: Jarek Poplawski <jarkao2@gmail.com>
> > 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.

I agree with you that a separate qdisc, or actually some aliases, like
this older sch_rr, and maybe also independent sch_prio_mq with .enqueue
and .dequeue overridden, look most sensible to me.

Thanks,
Jarek P.