From owner-freebsd-arch@FreeBSD.ORG Tue May 28 18:41:22 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF8A543C; Tue, 28 May 2013 18:41:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id C97A1E35; Tue, 28 May 2013 18:41:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UhOpf-000K51-Su; Tue, 28 May 2013 18:41:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r4SIfCZG006525; Tue, 28 May 2013 12:41:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19oD9mekSbQ7abrVlZW2ozJ Subject: Re: interrupt threads From: Ian Lepore To: John Baldwin In-Reply-To: <201305280841.17685.jhb@freebsd.org> References: <981733489AB3BD4DB24B48340F53E0A55B0D53AD@MTLDAG01.mtl.com> <201305280841.17685.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 May 2013 12:41:12 -0600 Message-ID: <1369766472.1258.11.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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 18:41:23 -0000 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). -- Ian > However, in most cases you can simply use a normal ithread handler and not > bother with a filter. >