Interrupts + Polling mode (similar to Linux's NAPI)

[Barney Cordoba]

--- On Tue, 4/28/09, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

> From: Luigi Rizzo <rizzo at iet.unipi.it>
> Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI)
> To: "Barney Cordoba" <barney_cordoba at yahoo.com>
> Cc: "Paolo Pisati" <p.pisati at oltrelinux.com>, fabient at freebsd.org, "FreeBSD Net" <freebsd-net at freebsd.org>
> Date: Tuesday, April 28, 2009, 11:07 AM
> On Tue, Apr 28, 2009 at 07:26:40AM -0700, Barney Cordoba
> wrote:
> ...
> > The problem with all of this "analysis" is
> that it assumes that SMP
> > coding scales intuitively; when the opposite is
> actually true. 
> > 
> > What you fail to address is the basic fact that
> moderated interrupts
> > (ie holding off interrupts to a set number of
> ints/second) is exactly
> > the same as polling, as on an active system you'll
> get exactly X
> > interrupts per second at equal intervals. So all of
> this chatter about
> > polling being more efficient is simply bunk.
> > 
> > The truth is that polling requires additional overhead
> to the system while
> > interrupts do not. So if polling did better for you,
> its simply because 
> > either 
> > 
> > 1)  The polling code in the driver is better
> > 
> > or
> > 
> > 2) You tuned polling better than you tuned interrupt
> moderation.
> > 
> 
> If i am not mistaken we don't have generic support for
> interrupt moderation
> in the kernel but that's a specific NIC feature: it
> works if the
> hardware supports it, and it doesn't otherwise.

Well its the silly integrator who uses whatever hardware he has lying 
around. You don't try to squeeze performance out of crap hardware.
You get hardware that has the features you need.

The point of polling was to avoid livelock. So the question is why is it
still around in 7 and 8, along with the propaganda that its any better 
than just using a decent controller.

BC