>
> The real question is why NAPI causes so much more work for the client.
>
[Just a summary from my results from last year. All testing with a
simple NIC without hw interrupt mitigation, on a Cyrix P150]
My assumption was that NAPI increases the cost of receiving a single
packet: instead of one hw interrupt with one device access (ack
interrupt) and the softirq processing, the hw interrupt must ack &
disable the interrupt, then the processing occurs in softirq context,
and the interrupts are reenabled at softirq context.
The second point was that interrupt mitigation must remain enabled, even
with NAPI: the automatic mitigation doesn't work with process space
limited loads (e.g. TCP: backlog queue is drained quickly, but the
system is busy processing the prequeue or receive queue)
jamal, it is possible that a driver uses both napi and the normal
interface, or would that break fairness?
Use netif_rx, until it returns dropping. If that happens, disable the
interrupt, and call netif_rx_schedule().
Is it possible to determine the average number of packets that are
processed for each netif_rx_schedule()?
-- Manfred- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:30 EST