interrupt threads
John Baldwin
jhb at freebsd.org
Tue May 28 20:14:11 UTC 2013
On Tuesday, May 28, 2013 2:41:12 pm Ian Lepore wrote:
> 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).
Eh, it only works if you build a kernel with the INTR_FILTER option (not on by
default) IIRC. I started on cleaning that up and ended up rototilling much of
the ithread code in a p4 branch. I hope to merge that into HEAD at which point
filters + handlers will always work (along with several other changes aimed at
removing the need for taskqueue_fast for most cases).
--
John Baldwin
More information about the freebsd-arch
mailing list