From owner-freebsd-arch@FreeBSD.ORG Tue May 28 20:14:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51585FAD; Tue, 28 May 2013 20:14:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6CC2F0; Tue, 28 May 2013 20:14:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7589DB988; Tue, 28 May 2013 16:14:10 -0400 (EDT) From: John Baldwin To: Ian Lepore Subject: Re: interrupt threads Date: Tue, 28 May 2013 15:00:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <981733489AB3BD4DB24B48340F53E0A55B0D53AD@MTLDAG01.mtl.com> <201305280841.17685.jhb@freebsd.org> <1369766472.1258.11.camel@revolution.hippie.lan> In-Reply-To: <1369766472.1258.11.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305281500.56679.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 May 2013 16:14:10 -0400 (EDT) Cc: Orit Moskovich , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:14:11 -0000 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