netdev - RE: [PATCH] NET: Multiqueue network device support.

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:	Sun, 10 Jun 2007 11:27:09 -0400
From:	"Leonid Grossman" <Leonid.Grossman@...erion.com>
To:	<hadi@...erus.ca>
Cc:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	"Patrick McHardy" <kaber@...sh.net>, <davem@...emloft.net>,
	<netdev@...r.kernel.org>, <jeff@...zik.org>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Ramkrishna Vepa" <Ramkrishna.Vepa@...erion.com>,
	"Alex Aizman" <aaizman@...erion.com>
Subject: RE: [PATCH] NET: Multiqueue network device support.

> -----Original Message-----
> From: J Hadi Salim [mailto:j.hadi123@...il.com] On Behalf Of jamal
> Sent: Saturday, June 09, 2007 8:03 PM
> To: Leonid Grossman
> Cc: Waskiewicz Jr, Peter P; Patrick McHardy; davem@...emloft.net;
> netdev@...r.kernel.org; jeff@...zik.org; Kok, Auke-jan H; Ramkrishna
> Vepa; Alex Aizman
> Subject: RE: [PATCH] NET: Multiqueue network device support.
> 
> our definition of "channel" on linux so far is a netdev
> (not a DMA ring). A netdev is the entity that can be bound to a CPU.
> Link layer flow control terminates (and emanates) from the netdev.

I think we are saying the same thing. Link layer flow control frames are
generated (and terminated) by the hardware; the hardware gets configured
by netdev.
And if a hw channel has enough resources, it could be configured as a
separate netdev and handle it's flow control the same way single-channel
NICs do now. 
I'm not advocating flow control on per DMA ring basis. 

> > This is not what I'm saying :-). The IEEE link you sent shows that
> > per-link flow control is a separate effort, and it will likely to
> take
> > time to become a standard.
> 
> Ok, my impression was it was happening already or it will happen
> tommorow morning ;->

the proposal you mentioned is dated 2005, but something like that will
probably happen sooner or later in IEEE. Some non-standard options,
including ours, are already here - but as we just discussed, in any case
flow control is arguably a netdev property not a queue property. 
The multi-queue patch itself though (and possibly some additional
per-queue properties) is a good thing :-)

-
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