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:	Tue, 08 May 2007 17:33:56 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	Johannes Berg <johannes@...solutions.net>, jamal <hadi@...erus.ca>
Cc:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	hadi@...erus.ca, Patrick McHardy <kaber@...sh.net>,
	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

On Fri, 2007-05-04 at 23:22 +0200, Johannes Berg wrote:
> On Fri, 2007-05-04 at 13:43 -0700, Waskiewicz Jr, Peter P wrote:
> > If hardware exists that wants the granularity to
> > start/stop queues independent of each other and continue to have
> > traffic
> > flow, I really think it should be able to do that. 
> 
> Not much of an if there, I'm pretty sure at least some wireless hardware
> can do that. We've been watching this multiqueue stuff for a while now
> with some interest but haven't hashed out yet how we could use it.

Right.

Jamal, as you said, the wireless subsystem uses an interim workaround
(the extra netdev approach) to achieve hardware packets scheduling. But
with Peter's patch, the wireless stack doesn't need the workaround
anymore. This is the actual fix.

On Wed, 02 May 2007 08:43:49 -0400, jamal wrote:

> You feel the need to keep all the rings busy even when one is
> shutdown; I claim by having a synced up qdisc of the same scheduler 
> type you dont need to worry about that. Both approaches are correct;
> what iam proposing is many factors simpler.

Let me explain why this is not true for wireless. The wireless priority
happens in the MAC level. That is, packets priority not only compete
each other in the host, they also compete in the network. For example,
once the wireless medium becomes idle from busy, the higher priority
packet seizes the channel after waiting for a shorter time period (which
makes the channel unavailable again). Both the high and low priority
packets have to be queued in the hardware queues before they are sent
out so that the hardware knows how to kick off its timers when it
detects the medium is idle. If the Qdisc stops feeding all packets just
because the hardware low prio queue is full (as it cannot seize the
channel in the network), it is unfair to the local high prio packets.
The host is too "nice(2)" to NOT let local high prio packets complete
with the ones in the other hosts. BTW, you cannot write a smiliar
scheduler in the Qdisc since it requires hard real time in microsecond
level.

After a second thought, this is not wireless specific. It can be
generalized as hardware level packet scheduling. I think kernel needs
such kind of support. And Peter's patch address this well.

Thanks,
-yi

-
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