Date: Tue, 28 Apr 2009 07:26:40 -0700 (PDT) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Paolo Pisati <p.pisati@oltrelinux.com>, fabient@freebsd.org Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) Message-ID: <50451.74235.qm@web63901.mail.re1.yahoo.com> In-Reply-To: <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Tue, 4/28/09, Fabien Thomas <fabien.thomas@netasq.com> wrote: > From: Fabien Thomas <fabien.thomas@netasq.com> > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Paolo Pisati" <p.pisati@oltrelinux.com> > Cc: "FreeBSD Net" <freebsd-net@freebsd.org> > Date: Tuesday, April 28, 2009, 5:49 AM > Le 28 avr. 09 =E0 11:04, Paolo Pisati a =E9crit : >=20 > > Fabien Thomas wrote: > >>=20 > >> To share my results: > >>=20 > >> I have done at work modification to the polling > code to do SMP polling (previously posted to this ml). > >>=20 > >> 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. > >=20 >=20 > 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). >=20 > 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.=20 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=20 either=20 1) The polling code in the driver is better or 2) You tuned polling better than you tuned interrupt moderation. Barney=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50451.74235.qm>