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  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, 23 Feb 2007 08:49:59 -0800
From:	Roland Dreier <rdreier@...co.com>
To:	Jan-Bernd Themann <ossthema@...ibm.com>
Cc:	netdev <netdev@...r.kernel.org>,
	Christoph Raisch <raisch@...ibm.com>,
	"Jan-Bernd Themann" <themann@...ibm.com>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"linux-ppc" <linuxppc-dev@...abs.org>,
	Marcus Eder <meder@...ibm.com>,
	Thomas Klein <tklein@...ibm.com>,
	Stefan Roscher <stefan.roscher@...ibm.com>
Subject: Re: [PATCH] ehea: Optional TX/RX path optimized for SMP

 > This patch introduces an optional alternative receive processing
 > functionality (enabled via module load parameter). The ehea adapter
 > can sort TCP traffic to multiple receive queues to be processed by
 > the driver in parallel on multiple CPUs. The hardware always puts
 > packets for an individual tcp stream on the same queue. As the
 > current NAPI interface does not allow to handle parallel receive
 > threads for a single adapter (processing on multiple CPUs in parallel)
 > this patch uses tasklets with a simple fairness algorithm instead. 
 > On the send side we also take advantage of ehea's multiple send queue
 > capabilites. A simple hash function in combination with the LL_TX
 > attribute allows to process tx-packets on multiple CPUs on different
 > queues. The hash function is needed to guarantee proper TCP packet
 > ordering. This alternative packet processing functionality leads to 
 > significant performance improvements with ehea. 

Why make this a module option that the user has to set?  Are there any
circumstances when someone wouldn't want "significant performance
improvements?"  If this approach is just better, then it should just
replace the old code.

Also, as far as the approach of using tasklets, I think it would be
better to use the "fake netdev" approach to continue to use NAPI.
Basically you create a pseudo-netdev for each receive queue and have
NAPI handle the polling for you -- you could look for
drivers/net/cxgb3 for an example of this.

 - R.
-
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

Powered by blists - more mailing lists