On 09/08/16 03:03, Darren Tucker wrote:
On Fri, Aug 05, 2016 at 11:56:15AM +1000, Darren Tucker wrote:
On Thu, Aug 04, 2016 at 02:46:44PM +0200, Momtchil Momtchev wrote:
[...]
What is the problem with software interrupt moderation? That it has a
fixed timer while the hardware one scales with the RX rate?
The hardware moderation can do per-N-packets in addition to a timer.
I just went through the two Linux drivers. There is the GPLd r8169
that is built into the official kernel written by someone at Realtek.
This one uses hardware interrupt moderation with the 0x5151 magic. Then
there is the r8168 driver distributed by Realtek on their site. It is
also GPLd. That one is considered to be of better quality in the Linux
world and it is repackaged by some Linux distros (Debian and Ubuntu for
example) as a replacement for the built-in driver. This second driver
uses a strategy similar to the current OpenBSD driver - schedule an
interrupt, then whenever the queue is not empty, reschedule the next
interrupt using a hardware timer (register 0x58) on the chip (ie.
"simulated" interrupt moderation) and still has exceptional performance.
The Realtek timer value in Linux is fixed 0x2600. The OpenBSD driver
deduces it from the bus speed. Anyway I think that at least on the PC
Engines APU the bottleneck is not CPU- or IRQ-related.
