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
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
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 majord
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
> 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
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 tc
