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:	Sat, 23 Aug 2008 09:31:06 -0700
From:	"Alexander Duyck" <alexander.duyck@...il.com>
To:	"Jarek Poplawski" <jarkao2@...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 Sat, Aug 23, 2008 at 1:47 AM, Jarek Poplawski <jarkao2@...il.com> wrote:
> On Fri, Aug 22, 2008 at 05:33:48PM -0700, David Miller wrote:
> ...
>> If we want queue selection in the packet scheduler, let's implement
>> it, but let's do so properly using classifiers and TC actions or a
>> ematch modules that can select the queue.
>>
>> Then people can implement whatever policy they want, in completely
>> generic ways, and the kernel simply doesn't care.
>>
>> The way this code worked was completely special purpose and ignored
>> the host of facilities and infrastructure we have for doing things
>> like this.
>
> Alas I can't get your point here. prio is sched + classifier 2 in 1,
> and if a small change in this is enough for somebody who really uses
> this, and there seem to be noone interested in doing this better or
> harmed with this, why bother with actions or other classifiers? Maybe
> this prio method is less generic, but it's quite simple and there is
> some infrastructure around this.
>
> Jarek P.

Actually in this new multiple tx queue kernel this qdisc could serve a
very specific but needed purpose which just became apparent to me.
This qdisc resolves one very specific issue, head-of-line blocking if
one of the hardware queues is full.  What if I reversed things a bit
in prio_classify so that skb->queue_mapping determined the band
instead of the other way around in the case of the multiqueue option
being enabled?  I would think that in this configuration the qdisc
would prove to be pretty useful for purposes other than QOS since it
would allow a classful qdisc per transmit queue instead of per device.

I could then create a select_queue for the device that returns 0 when
in DCB/EEDC mode for our drivers, implement the tc action to set the
queue mapping, and have essentially the same result as I had before.

Thanks,

Alex
--
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