interrupt threads

[John Baldwin]

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.

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

-- 
John Baldwin