netdev - Re: [PATCH] ehea: Optional TX/RX path optimized for SMP

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, 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