Re: Why not remove polling(4) from 7.0?

On Jun 7, 2007, at 2:36 AM, Abdullah Ibn Hamad Al-Marri wrote:
>> > So why not remove it or switch to adaptive polling as em(4)  
>> instead of
>> > resorting to polling?
>>
>> Are you just talking about em(4) or removing polling for all  
>> drivers? It
>> is helpful in some cases, for example I run FreeBSD on a Nortel
>> contivity 1010 box where interrupts do not work on the fxp  
>> interface and
>> yet its quite usable with polling mode.
>>
>> Its not enabled by default so its up to the user if they want to make
>> use of it.
>
> I mean can't we use better handeling for nics which is better than
> current polling(4)?

If a particular NIC supports something like interrupt mitigation,  
generally it will be enabled by default.  Of course, using interrupt  
mitigation adds latency also, just as using polling does, but the  
tradeoffs are probably worth it for many cases.

However, under other circumstances-- such as continuous or nearly  
continuous high traffic loads on something like a router or firewall  
application-- polling tends to handle such load better and avoid  
livelock and/or excessive context switches to the interrupt handler  
resulting in lower throughput.  The key point to notice is that  
polling is not the default behavior, it's an option which can be  
selectively enabled when the admin of a particular machine decides  
that it might prove to be the better choice.

And, as Andrew mentioned, in a few cases you'll find a machine where  
the NIC doesn't fire interrupts off correctly at all, generally due  
to some major flaw in the hardware or BIOS config, but polling will  
still work OK.

-- 
-Chuck