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
meantime,
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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
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 example
Hi!
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
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
