From owner-freebsd-arch@FreeBSD.ORG Tue May 28 17:58:29 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 5FA0733B for ; Tue, 28 May 2013 17:58:29 +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 3DBCBB58 for ; Tue, 28 May 2013 17:58:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 30ED2B95D; Tue, 28 May 2013 13:58:26 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: interrupt threads Date: Tue, 28 May 2013 08:41:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <981733489AB3BD4DB24B48340F53E0A55B0D53AD@MTLDAG01.mtl.com> In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D53AD@MTLDAG01.mtl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305280841.17685.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 May 2013 13:58:26 -0400 (EDT) Cc: Orit Moskovich 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 17:58:29 -0000 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. However, in most cases you can simply use a normal ithread handler and not bother with a filter. -- John Baldwin