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

2007-03-03 Thread Andi Kleen
On Sat, Mar 03, 2007 at 09:28:28AM +0100, Benjamin Herrenschmidt wrote: > On Sat, 2007-03-03 at 04:06 +0100, Andi Kleen wrote: > > Jan-Bernd Themann <[EMAIL PROTECTED]> writes: > > > > > > Are there any concerns about this approach? > > > > Yes. You should fix the NAPI code instead of trying to w

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

2007-03-03 Thread Benjamin Herrenschmidt
On Sat, 2007-03-03 at 04:06 +0100, Andi Kleen wrote: > Jan-Bernd Themann <[EMAIL PROTECTED]> writes: > > > > Are there any concerns about this approach? > > Yes. You should fix the NAPI code instead of trying to work > around it. NAPI is being fixed but the fix will take time to get in. In the m

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

2007-03-02 Thread Andi Kleen
Jan-Bernd Themann <[EMAIL PROTECTED]> writes: > > Are there any concerns about this approach? Yes. You should fix the NAPI code instead of trying to work around it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More

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

2007-02-26 Thread Jan-Bernd Themann
Hi > 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 exa

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

2007-02-23 Thread Roland Dreier
> 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 ind