Linux har sedan väldigt långt tillbaka (NAPI från 2002) växlat mellan att driva nätverkskort med en kombination av IRQ och busy-polling.
Att till 100 % låta applikationer styra polling är bra så långe som applikationer uppför sig, men blir katastrofalt om den inte gör det. Så går inte att köra en sådan modell med mindre än att då helt räkna applikationen som en del av OS-kärnan.
Nyheten här är egentligen otroligt simpel: en till timer.
Processen i NAPI är att NIC ger ett RX IRQ när ett paket kommer in. "Top-half" av IRQ-rutinen maskar då den IRQ-kanalen och schemalägger ett "soft-IRQ" som hanterar paketet. I detta läge kommer alltså inga fler IRQs.
ALLA paket (eller normalt alla paket, finns en övre "budget" när man låter andra saker komma emellan men normalfallet är alla) processas sedan i soft-IRQ. När man är klar slås IRQ på igen.
Här är nyheten. Vid hög last kommer ett nytt IRQ nästan direkt triggas igen, det kommer i praktiken hända innan applikationer haft en chans att beta av allt som redan kommit in -> detta leder till lägre IPC då cacha:ar trashas av frekventa kontext-switchar.
Istället för att direkt slå på IRQ när man processat alla paket startar man nu en timer. Om applikationen är "well-behaved" kan man nu helt driva all nätverkstrafik mot den RX-ringen med IRQ permanent avslaget så länge det kommer paket "tillräckligt snabbt".
Om applikationen får för sig att sluta poll:a av någon anledning triggar timer som slår på IRQ så inte andra applikationer blir lidande. "Worst case tail-latency" begränsas då av denna timer.
Så länge applikationen uppför sig så kommer paket drivas av att den rätt snabbt går in för att kolla efter paket.
Besparingen kommer av att det är mer effektivt att driva trafik med IRQ avslaget vid hög last. Alt. om man kör out-of-kernel polling (t.ex. via DPDK) så är vinsten att detta ger nästan samma prestanda, fast utan extremt hög effekt när det kommer få paket.
