netdev - Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

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:	Thu, 26 Apr 2007 18:44:25 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
CC:	hadi@...erus.ca,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org, jgarzik@...ox.com,
	cramerj <cramerj@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Leech, Christopher" <christopher.leech@...el.com>,
	davem@...emloft.net
Subject: Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

Waskiewicz Jr, Peter P wrote:
>>I wouldn't object to putting this into a completely new scheduler
>>(sch_multiqueue) though since the scheduling policy might be 
>>something completely different than strict priority.
> 
> 
> We have plans to write a new qdisc that has no priority given to any
> skb's being sent to the driver.


I'm not sure I understand correctly, "no priority" == single band
qdisc?

> The reasoning for providing a
> multiqueue mode for PRIO is it's a well-known qdisc, so the hope was
> people could quickly associate with what's going on.  The other
> reasoning is we wanted to provide a way to prioritize various network
> flows (ala PRIO), and since hardware doesn't currently exist that
> provides flow prioritization, we decided to allow it to continue
> happening in software.


Any qdisc serving multiple queues needs some scheduling policy to
decide which one to dequeue in case multiple queues are active, so
a new qdisc might as well also use strict priority. Two reasons
why it might make sense to add a new qdisc are a) the hardware
scheduling policy could be something different than prio, like WRR,
so a neutral name like sch_multiqueue seems more fitting and b)
you don't have to figure out how to pass the new parameter to prio
without breaking compatibility.

>>The wireless multiqueue scheduler is pratically identical to 
>>this one, modulo the wireless classifier that should be a 
>>seperate module anyway.
> 
> 
> Yi Zhu from the wireless world has been active with me in this
> development effort.  He and I are copresenting a paper at OLS on this
> specific topic, so I have been getting a perspective from the wireless
> world.
> 
> I'd like to know if anyone has looked at the actual kernel patches,
> instead of the tiny patch to tc here, since that might answer many
> questions or concerns being presented here.  :-)


I did and I'm fine with the current patches if you get rid of the prio
ABI breakage. Using a new scheduler is just a suggestion, but I think
it would be cleaner to do so.

-
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