When network traffic is heavy, it is most efficient, and delivers the best performance, to disable interrupts and run in polling mode. But when network traffic is light, interrupt-driven processing works best, he noted.
“An implementation using only polling would waste a lot of resources/energy during times of light traffic. An implementation using only interrupts becomes inefficient during times of heavy traffic. … So the biggest energy savings arise when comparing to a high-performance always-polling implementation during times of light traffic,” Karsten said. “Our mechanism automatically detects [the amount of network traffic] and switches between polling and interrupt-driven to get the best of both worlds.”
In the patch cover letter, Damato described the implementation of the new parameter in more detail, noting: “this delivery mode is efficient, because it avoids softIRQ execution interfering with application processing during busy periods. It can be used with blocking epoll_wait to conserve CPU cycles during idle periods. The effect of alternating between busy and idle periods is that performance (throughput and latency) is very close to full busy polling, while CPU utilization is lower and very close to interrupt mitigation.”
Added Karsten: “At the nuts and bolts level, enabling the feature requires a small tweak to applications and the setting of a system configuration variable.”
And although he can’t yet quantify the energy benefits of the technique (the 30% saving cited is best case), he said, “the biggest energy savings arise when comparing to a high-performance always-polling implementation during times of light traffic.”