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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Aug 2008 06:16:28 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	David Miller <davem@...emloft.net>, hadi@...erus.ca,
	jeffrey.t.kirsher@...el.com, jeff@...zik.org,
	netdev@...r.kernel.org, alexander.h.duyck@...el.com
Subject: Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

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@...emloft.net> wrote:
> > From: Jarek Poplawski <jarkao2@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html