Message-ID: <3D78F55C.4020207@colorfullife.com>
Date: Fri, 06 Sep 2002 20:35:08 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
MIME-Version: 1.0
To: Dave Hansen <haveblue@us.ibm.com>, jamal <hadi@cyberus.ca>,
       netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1393
Lines: 33

 >
> 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/