Date: Tue, 28 Apr 2009 17:07:39 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Barney Cordoba <barney_cordoba@yahoo.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, fabient@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) Message-ID: <20090428150739.GC8430@onelab2.iet.unipi.it> In-Reply-To: <50451.74235.qm@web63901.mail.re1.yahoo.com> References: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com> <50451.74235.qm@web63901.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Of course it would be possible to modify polling to implement generic interrupt mitigation even without hardware support, so you get the best of the two worlds. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090428150739.GC8430>