RE: NAPI vs. interrupts

NAPI driver _always_ does
	ack some irqs
	mask irqs
	ack some more irqs
	process events
	unmask irqs

e1000+NAPI is this path.

The purpose of this email is to solicit suggestions to 
develop a strategy to fix what I believe is a problem with NAPI.

Here are some comments of mine:

1) Can this problem be alleviated entirely without driver 
changes?  For example, would it be reasonable to do 
pkts-per-second sampling in the net core, and enable software 
mitigation based on that?

2) Implement hardware mitigation in addition to NAPI.  Either 
the driver does adaptive sampling, or simply hard-locks 
mitigation settings at something that averages out to N pkts 
per second.

I've tried something similar to this while playing around with e1000
recently.  Using ITR (InterruptThrottleRate), dial in a max intr/sec
rate of say 4000 intr/sec, and then just call netif_rx_schedule() for
each interrupt.  Don't mask/unmask interrupts.  If already polling,
netif_rx_schedule does nothing.  The code differences between the NAPI
path and non-NAPI path was minimal, so I liked that, and your worst case
is gone.  If you look at the average size of the Rx packets, you could
fine tune ITR to get a pkt/intr rate to balance your quota to try to
maximize the amount of time spent polling, but this is too fancy for my
taste.  Anyway, worst case, 2*4000 PIO writes/sec was the savings, but I
can't say I could measure a difference.
 
-scott