Interrupts + Polling mode (similar to Linux's NAPI)

Fabien Thomas fabien.thomas at netasq.com
Tue Apr 28 15:51:11 UTC 2009


>>>>
>>>> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>



More information about the freebsd-net mailing list