Network card interrupt handling

[Adrian Chadd]

On 30 August 2015 at 17:00, John-Mark Gurney <jmg at funkthat.com> wrote:
> Adrian Chadd wrote this message on Fri, Aug 28, 2015 at 12:41 -0700:
>> [snip]
>>
>> Well, the other big reason for doing it deferred like this is to avoid
>> network based deadlocks because you're being fed packets faster than
>> you can handle them. If you never yield, you stop other NIC
>> processing.
>
> You snipped the part of me asking isn't the interrupt thread just the
> same interruptable context as the task queue?  Maybe the priority is
> different, but that can be adjusted to be the same and still save the
> context switch...
>
> There is no break/moderation in the taskqueue, as it'll just enqueue
> itself, and when the task queue breaks out, it'll just immediately run
> itself, since it has a dedicated thread to itself... So, looks like
> you get the same spinning behavior...
>
>> People used to do run-to-completion and then complained when this
>> happened, so polling was a thing.
>
> Maybe when using PCI shared interrupts, but we are talking about PCIe
> MSI-X unshared interrupts.

Well, try it and see what happens. You can still get network livelock
and starvation of other interfaces with ridiculously high pps if you
never yield. :P



-adrian