Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Apr 2009 11:49:27 +0200
From:      Fabien Thomas <fabien.thomas@netasq.com>
To:        Paolo Pisati <p.pisati@oltrelinux.com>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: Interrupts + Polling mode (similar to Linux's NAPI)
Message-ID:  <36906055-E1AE-486B-BA77-D260E0609BBB@netasq.com>
In-Reply-To: <49F6C6B4.4080108@oltrelinux.com>
References:  <160513.83122.qm@web63904.mail.re1.yahoo.com> <F14F044E-B39E-476B-A9DE-0EDB4D5265BE@netasq.com> <49F6C6B4.4080108@oltrelinux.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail-154-611962325
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable


Le 28 avr. 09 =E0 11:04, Paolo Pisati a =E9crit :

> Fabien Thomas wrote:
>>
>> To share my results:
>>
>> I have done at work modification to the polling code to do SMP =20
>> polling (previously posted to this ml).
>>
>> SMP polling (dynamic group of interface binded to CPU) does not =20
>> significantly improve the throughput (lock contention seems to be =20
>> the cause here).
>> The main advantage of polling with modern interface is not the PPS =20=

>> (which is nearly the same) but the global efficiency of the system =20=

>> when using multiple interfaces (which is the case for Firewall).
>> The best configuration we have found with FreeBSD 6.3 is to do =20
>> polling on one CPU and keep the other CPU free for other =20
>> processing. In this configuration the whole system
>> is more efficient than with interrupt where all the CPU are busy =20
>> processing interrupt thread.
> out of curiosity: did you try polling on 4.x? i know it doesn't =20
> "support" SMP over there, but last time i tried polling on 7.x (or =20
> was it 6.x? i don't remember...)
> i found it didn't gave any benefit, while switching the system to =20
> 4.x showed a huge improvement.
>

yes rewriting the core polling code started at half because the =20
polling code on 6.x and up perform badly (in our env) regarding =20
performance.
today 4.x is unbeatable regarding network perf  (6.2 -> 7.0 at least, =20=

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 =20
polling code to gain what we loose with fine grained SMP kernel.

> --=20
>
> bye,
> P.
>
>


--Apple-Mail-154-611962325--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36906055-E1AE-486B-BA77-D260E0609BBB>