polling's future [was: Re: Dynamic Ticks/HZ]

Andre Oppermann andre at freebsd.org
Tue Nov 6 11:41:25 UTC 2012

On 06.11.2012 12:02, Fabien Thomas wrote:
>> Hi Luigi,
>> do you agree on polling having outlived its usefulness in the light
>> of interrupt moderating NIC's and SMP complications/disadvantages?
> If you have only one interface yes polling is not really necessary.
> If you have 10 interfaces the interrupt moderation threshold is hard to find
> to not saturate the system.
> Doing polling at 8000hz in that case is a lot better regarding global interrupt level.

OK.  Is the problem the interrupt load itself, or the taskqueues?

> The problem is that in the current state polling does not work well and people remember
> the good old time where polling was better.


> rstone@ and myself have made some improvement to polling.
> You can find a diff here for 8.3 with updated intel driver :
> http://people.freebsd.org/~fabient/polling/patch-pollif_8.3_11052012
> - support multiqueue for ixgbe, igb, em.
> - compat API for old driver
> - keep interrupt for link / status
> - user core mapping / auto mapping
> - deadline to keep cpu available
> - integrated to netisr
> - deferred packet injection with optional prefetching

This is a number of interesting but sometimes only tangentially
related features.  Lets focus on the network cpu monopolization
issue first.

> Performance are on par with interrupt but you can keep a system alive more easily
> by accounting all network processing for the deadline (with direct dispatch).

Would you be willing to work a solution with me with a load aware
taskqueue as I proposed in a recent email to Luigi?  That way we
don't need special cases or features or even a normal server under
DDoS wouldn't go down.


More information about the freebsd-current mailing list