[lkml]   [2002]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Early SPECWeb99 results on 2.5.33 with TSO on e1000
> 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()?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.067 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site