From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 22:24:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD1AC16A417 for ; Thu, 19 Oct 2006 22:24:37 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9F243D58 for ; Thu, 19 Oct 2006 22:24:34 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id k9JMOXQO018217; Thu, 19 Oct 2006 15:24:34 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4536EF19.2060201@samsco.org> Date: Thu, 19 Oct 2006 15:24:33 -0700 (PDT) From: John Polstra To: Scott Long Cc: freebsd-net Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 22:24:37 -0000 On 19-Oct-2006 Scott Long wrote: > The performance measurements that Andre and I did early this year showed > that the INTR_FAST handler provided a very large benefit. I'm trying to understand why that's the case. Is it because an INTR_FAST interrupt doesn't have to be masked and unmasked in the APIC? I can't see any other reason for much of a performance difference in that driver. With or without INTR_FAST, you've got the bulk of the work being done in a background thread -- either the ithread or the taskqueue thread. It's not clear to me that it's any cheaper to run a task than it is to run an ithread. A difference might show up if you had two or more em devices sharing the same IRQ. Then they'd share one ithread, but would each get their own taskqueue thread. But sharing an IRQ among multiple gigabit NICs would be avoided by anyone who cared about performance, so it's not a very interesting case. Besides, when you first committed this stuff, INTR_FAST interrupts were not sharable. Another change you made in the same commit (if_em.c revision 1.98) greatly reduced the number of PCI writes made to the RX ring consumer pointer register. That would yield a significant performance improvement. Did you see gains from INTR_FAST even without this independent change? John