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:	Wed, 13 Jun 2007 15:12:37 +0200
From:	Robert Olsson <Robert.Olsson@...a.slu.se>
To:	hadi@...erus.ca
Cc:	Zhu Yi <yi.zhu@...el.com>, Patrick McHardy <kaber@...sh.net>,
	David Miller <davem@...emloft.net>,
	peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
	jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: [PATCH] NET: Multiqueue network device support.

jamal writes:

 > The key arguement i make (from day one actually) is to leave the
 > majority of the work to the driver.
 > My view of wireless WMM etc is it is a different media behavior
 > (compared to wired ethernet) which means a different view of strategy
 > for when it opens the valve to allow in more packets. 802.11 media has
 > embedded signalling which is usable. Guy Cohen gave a good use case
 > which i responded to. Do you wanna look at that and respond?

 Hello,

 Haven't got all details. IMO we need to support some "bonding-like" 
 scenario too. Where one CPU is feeding just one TX-ring. (and TX-buffers
 cleared by same CPU). We probably don't want to stall all queuing when
 when one ring is full. 

 The scenario I see is to support parallelism in forwarding/firewalling etc.
 For example when RX load via HW gets split into different CPU's and for 
 cache reasons we want to process in same CPU even with TX.

 If RX HW split keeps packets from the same flow on same CPU we shouldn't
 get reordering within flows.

 Cheers
						--ro

-
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