Date: Tue, 28 Apr 2009 17:51:07 +0200 From: Fabien Thomas <fabien.thomas@netasq.com> To: 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: <3B579474-23FD-4A9F-970B-98AA17B31EC7@netasq.com> In-Reply-To: <50451.74235.qm@web63901.mail.re1.yahoo.com> References: <50451.74235.qm@web63901.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-6-633662438 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >>>> >>>> I have done at work modification to the polling >> code to do SMP polling (previously posted to this ml). >>>> >>>> SMP polling (dynamic group of interface binded to >> CPU) does not significantly improve the throughput (lock >> contention seems to be the cause here). >>>> The main advantage of polling with modern >> interface is not the PPS (which is nearly the same) but the >> global efficiency of the system when using multiple >> interfaces (which is the case for Firewall). >>>> The best configuration we have found with FreeBSD >> 6.3 is to do polling on one CPU and keep the other CPU free >> for other processing. In this configuration the whole system >>>> is more efficient than with interrupt where all >> the CPU are busy processing interrupt thread. >>> out of curiosity: did you try polling on 4.x? i know >> it doesn't "support" SMP over there, but last >> time i tried polling on 7.x (or was it 6.x? i don't >> remember...) >>> i found it didn't gave any benefit, while >> switching the system to 4.x showed a huge improvement. >>> >> >> yes rewriting the core polling code started at half because >> the polling code on 6.x and up perform badly (in our env) >> regarding performance. >> today 4.x is unbeatable regarding network perf (6.2 -> >> 7.0 at least, i need to do more test on 7_stable and 8). >> >> the other half of the work was to explore the SMP scaling >> of the polling code to gain what we loose with fine grained >> SMP kernel. > > 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. I agree with you with one interface. When you use ten interface it is not the case. > > > 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. > > > Barney > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --Apple-Mail-6-633662438--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B579474-23FD-4A9F-970B-98AA17B31EC7>