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. Indeed. > rstone_at_ 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. -- AndreReceived on Tue Nov 06 2012 - 10:41:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC