interrupt threads

Andre Oppermann andre at freebsd.org
Tue May 28 20:40:51 UTC 2013


On 28.05.2013 21:00, John Baldwin wrote:
> 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).

That would be excellent.

-- 
Andre



More information about the freebsd-arch mailing list