polling's future [was: Re: Dynamic Ticks/HZ]
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 :
> - 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
> 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