Date: Tue, 28 May 2013 22:40:46 +0200 From: Andre Oppermann <andre@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Orit Moskovich <oritm@mellanox.com>, Ian Lepore <ian@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: interrupt threads Message-ID: <51A5164E.5030508@freebsd.org> In-Reply-To: <201305281500.56679.jhb@freebsd.org> References: <981733489AB3BD4DB24B48340F53E0A55B0D53AD@MTLDAG01.mtl.com> <201305280841.17685.jhb@freebsd.org> <1369766472.1258.11.camel@revolution.hippie.lan> <201305281500.56679.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51A5164E.5030508>