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:	Fri, 4 May 2007 13:43:43 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Stephen Hemminger" <shemminger@...ux-foundation.org>
Cc:	<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

> Just because they want to standardize, and put it in hardware 
> doesn't mean it is a good idea and Linux needs to support it!

I gave this as the motivation for the original idea.  But these patches
have been under scrutiny in the community for months now, and nobody
seemed to think they were totally wrong in design, just a few
implementation issues.  I did not design this specifically for this
technology either; this was the original idea, but the idea of allowing
the kernel to manage multiple queues on the NIC is the main focus here,
which many people seemed to like.  What happened that shifted that
perception?

> Why is it better for hardware to make the "next packet to 
> send" decision?
> For wired ethernet, I can't see how adding the complexity of 
> fixed number of small queues is a gain. Better to just do the 
> priority decision in software and then queue it to the 
> hardware. This seems like the old Token Ring and MAP/TOP 
> style crap crammed on top of Ethernet.

Are you saying it'd be better for the flow control requests per priority
to come up into the stack?  If you look closely at what I proposed in my
patches, it's just an API exposing the queues in the NIC to the kernel.
That's all.  How the hardware handles it is completely independent to
these patches.  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.  That is all these
patches are providing.  Jamal and I talked about the original
motivation, and so I shared that with the community.  I don't want the
focus to shift to a proposed standard that could take advantage of these
patches; rather, I'd like the focus to remain on the patches themselves,
and what they're providing.  And if someone can explain to me why 2
months of review and scrutiny of these patches has shifted in another
direction, I'd really like to understand that.

Thanks,

-PJ Waskiewicz
-
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