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: <1178827253.4062.78.camel@localhost>
Date:	Thu, 10 May 2007 16:00:53 -0400
From:	jamal <hadi@...erus.ca>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	"Zhu, Yi" <yi.zhu@...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 Thu, 2007-10-05 at 11:22 -0700, Waskiewicz Jr, Peter P wrote:
> > Wireless offers a strict priority scheduler with statistical 
> > transmit (as opposed to deterministic offered by the linux 
> > strict prio qdisc); so wireless is not in the same boat as DCE.
> 
> Again, you're comparing these patches with DCE, which is not the intent.
> It's something I presented that can use these patches, not as a
> justification for them.

I was making the claim that wireless _does not_ need you sawing off then
on the core code. It will work just fine with a prio qdisc. And the more
i think about it, the less i think DCE needs it ...

> I ran some tests on a 1gig network (isolated) using 2 hardware queues,
> streaming video on one and having everything else on the other queue.
> After the buffered video is sent and the request for more video is made,
> I see a slowdown with a single queue.  

What does this mean?

> I see a difference using these patches to mitigate the impact to the different flows; 

Thats is an extremely strong statement to be making. We need your
patches to get effective qos?

> Linux may be good
> at scheduling, but that doesn't help when hardware is being pushed to
> its limit - this was running full line-rate constantly (uncompressed mpg
> for video and standard iperf settings for LAN traffic).

What qdisc did you use on the single hardware queue? What was the
classifier you used to separate the video from the rest?
Why do i get the feeling that you did not configure Linux to give you
the separation needed?  If you want to do it proper i can help. 
I will chop off the rest of the text below because imo you need to
compare apples to apples and we are not getting anywhere.

Ok, how do we make progress forward? It seems to me we are back to
square one where i dont see a meeting in the middle.

I wanted to help, but you are so persistent on selling your patches that
we are loosing track of the discussion.
I strongly disagree with your approach and you strongly agree with your
patches. Maybe i should drop off this conversation and you can go
convince Dave? 

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