Date: Tue, 20 Nov 2012 19:08:33 -0600 From: khatfield@socllc.net To: Alfred Perlstein <bright@mu.org> Cc: Barney Cordoba <barney_cordoba@yahoo.com>, Jim Thompson <jim@netgate.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: FreeBSD boxes as a 'router'... Message-ID: <832757660.33924.1353460119408@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> In-Reply-To: <50AC08EC.8070107@mu.org> References: <1353448328.76219.YahooMailClassic@web121602.mail.ne1.yahoo.com> <E1F4816E-676C-4630-9FA1-817F737D007D@netgate.com> <50AC08EC.8070107@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Barney - I would certainly love to see some real evidence to backup such a = ridiculous claim. I agree here as well with Jim. I have a ton of experience with and without.= I haven't done enough testing with FreeBSD 9 to state 100% but I can state= that extensive testing and filtering traffic (specifically high PPS DDoS t= raffic) and polling is a requirement in certain situations.=20 It should not be required for normal traffic, certainly under 200Mbps but i= n no way should polling be discounted completely. Tuning Intel NICs works t= o an extent but offloading everything to the NIC without polling is a sure = fire way to live-lock a system in high PPS situations. So anyway, I stick to my original assessment that it can be iffy depending = on volume and scenario but I will also state that throwing polling out comp= letely discounts one of the strengths easily available on FreeBSD. That wou= ld be short-sighted, in my opinion. My recommendation is to use polling if you begin seeing lag or live-lock. I= n general use it isn't required but I assure you it can be extremely helpfu= l or detrimental. It all depends on the application of the system and the t= ype of workload it has. -Kevin On Nov 20, 2012, at 4:49 PM, "Alfred Perlstein" <bright@mu.org> wrote: > On 11/20/12 2:42 PM, Jim Thompson wrote: >> On Nov 20, 2012, at 3:52 PM, Barney Cordoba <barney_cordoba@yahoo.com> w= rote: >>=20 >>> Anyone who even mentions polling should be discounted altogether. Polli= ng >>> had value when you couldn't control the interrupt delays; but interrupt >>> moderation allows you to pace the interrupts any way you like without >>> the inefficiencies of polling. >> You're entitled to your opinion, but experimental results have tended to= show yours incorrect. >>=20 >> Jim > Agree with Jim. If you want pure packet performance you burn a core to r= un a polling loop. >=20 > -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?832757660.33924.1353460119408>