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

Fabien Thomas fabien.thomas at netasq.com
Tue Nov 6 11:02:21 UTC 2012

> 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.

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

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).


> And also that in its current state it is providing no benefit, if
> not negative, and that fixing it for the current world-order is major
> undertaking that's not really beneficial considering superior
> alternatives?
> That nobody is maintaining it and taking care of and fixing the frequent
> problem, performance and bug reports?
> Additionally it misleads people without deep network knowledge to
> compile it into their kernel under wrong assumptions and see a
> degradation of performance, if not other side effects?
> Under these considerations I propose to remove polling support from
> current and 10.0 in lieu of upcoming superior alternatives (netmap
> enabled features).  It was a great feature in the past but is beyond
> retirement and should live a peaceful live in the attic.
> -- 
> Andre
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

More information about the freebsd-current mailing list