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]

Message-Id: <1178630917.4078.46.camel@localhost>
Date:	Tue, 08 May 2007 09:28:37 -0400
From:	jamal <hadi@...erus.ca>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Zhu Yi <yi.zhu@...el.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	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 Tue, 2007-08-05 at 11:45 +0200, Johannes Berg wrote:
..

Sorry, I missed a lot of the discussions; I am busyed out and will try
to catchup later tonight. I have quickly scanned the emails and
I will respond backwards (typically the most effective
way to catchup with a thread).

As a summary, I am not against the concept of addressing per-ring flow
control. 
Having said that, i fully understand where DaveM and Stephen are coming
from. Making such huge changes to a critical region to support uncommon
hardware doesnt abide to the "optimize for the common" paradigm. That is
also the basis of my arguement all along. I also agree it is quiet
fscked an approach to have the virtual flow control. I think it is
driven by some marketing people and i dont really think there is a
science behind it. Switched (External) PCI-E which is supposed to be
really cheap and hit the market RSN has per-virtual queue flow control,
so that maybe where that came from. In any case, that is a digression. 
Peter, can we meet the goals you strive for and stick to the "optimize
for the common"? How willing are you to change directions to achieve
those goals?

> On Tue, 2007-05-08 at 17:33 +0800, Zhu Yi wrote:
> 
> > 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.
> 

I dont believe wireless needs anything other than the simple approach i
described. The fact that there an occasional low prio packet may endup
going out first before a high prio due to the contention is
non-affecting to the overall results.

> Actually, we still need multiple devices for virtual devices? Or which
> multiple devices are you talking about here?
> 

Those virtual devices you have right now. They are a hack that needs to
go at some point.

cheers,
jamal

-
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