Network card interrupt handling

[John-Mark Gurney]

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.

> So - I'm all for doing it with a fast interrupt handler and a fast
> taskqueue. As long as we don't run things to completion and
> re-schedule the taskqueue (so other things on that core get network
> processing) then I'm okay.
> 
> (I kinda want us to have NAPI at some point...)

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."