interrupt threads

[Ian Lepore]

On Tue, 2013-05-28 at 08:41 -0400, John Baldwin wrote:
> On Sunday, May 26, 2013 2:16:39 am Orit Moskovich wrote:
> > Hi,
> > 
> > I'm trying to understand the difference between using taskqueues defined by 
> ithreads (taskqueue_swi, taskqueue_swi_giant, taskqueue_fast) to defer an 
> interrupt's work, and defining an interrupt handler to give as ithread 
> parameter to bus_setup_intr.
> > Is there a difference in the priority? Which of the methods is preferable 
> when writing a network device and performance is important?
> 
> There are two types of interrupt handlers somewhat similar to the setup in OS 
> X's IOKit: a filter which runs in the borrowed thread context when an 
> interrupt happens, and a threaded handler.  Currently you can only use one or 
> the other.  However, filters are more restricted in what they can do (can only 
> use spin locks, can call wakeup(), but generally not use many other APIs).  
> Most drivers just use a threaded handler that runs in an ithread.  However, a 
> few drivers use a filter (e.g. the Intel gigabit driver uses a filter to 
> workaround an Intel chipset bug where if you mask the interrupt in the I/O 
> APIC while the ithread runs, the chipset decides you aren't using the APIC at 
> all and routes the NIC's interrupt to an alternate pin triggering a duplicate 
> interrupt on a pin shared with a USB controller).  When using a filter a 
> driver needs to manually schedule a thread context to perform the actions it 
> cannot perform in the filter (e.g. passing received packets up the network 
> stack).  The taskqueue_fast is used to manage those threads.  Typically the 
> threads backing such a taskqueue will have the same priority as ithreads as 
> they basically function as ithreads.
> 
> Eventually we will support having both a filter and a threaded handler for an 
> interrupt where the filter's return value decides whether or not the threaded 
> handler is scheduled to run.
> 

By "eventually" you must mean "since 2007."  At least, that's when the
code defining the filter handler return values was added.  I know it
works as documented at least since 8.2 because I use the feature in a
PPS driver (the pps capture is done in the filter handler and the rest
of the pps event processing is done in the threaded handler).

-- Ian


> However, in most cases you can simply use a normal ithread handler and not 
> bother with a filter.
>