From owner-cvs-all@FreeBSD.ORG Thu Jan 12 22:06:49 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 201FA16A41F; Thu, 12 Jan 2006 22:06:49 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C7E43D8B; Thu, 12 Jan 2006 22:06:38 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k0CM6bdw012406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2006 17:06:37 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k0CM6WeP007020; Thu, 12 Jan 2006 17:06:32 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17350.53992.494972.787933@grasshopper.cs.duke.edu> Date: Thu, 12 Jan 2006 17:06:32 -0500 (EST) To: Scott Long In-Reply-To: <43C6C4EA.20303@samsco.org> References: <200601110030.k0B0UPOx009098@repoman.freebsd.org> <20060112152119.A6776@grasshopper.cs.duke.edu> <43C6C4EA.20303@samsco.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Scott Long , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/em if_em.c if_em.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 22:06:49 -0000 Scott Long writes: > > Touching the APIC is tricky. First, you have to pay the cost of a > spinlock. Then you have to may the cost of at least one read and write > across the FSB. Even though the APIC registers are memory mapped, they > are still uncached. It's not terribly expensive, but it does add up. > Bypassing this and using a fast interrupt means that you pay the cost of > 1 PCI read, which you would have to do anyways with either method, and 1 > PCI write, which will be posted at the host-pci bridge and thus only as > expensive as an FSB write. Overall, I don't think that the cost > difference is a whole lot, but when you are talking about thousands of > interrupts per second, especially if multiple interfaces are running > under load, it might be important. And the 750x and 752x chipsets are > so common that it is worthwhile to deal with them (and there are reports > that the aliasing problem is happening on more chipsets than just these > now). I think you've sold me. I'm in the process of trying to justify time to write a FreeBSD driver for our PCIe 10GbE cards, and I find what you're doing fascinating. I'd like to use some of your techniques for the driver I'm writing. > As for latency, the taskqueue runs at the same PI_NET priority as an the > ithread would. I thought that there was an optimization on some > platforms to encourage quick preemption for ithreads when they are > scheduled, but I can't find it now. So, the taskqueue shouldn't be all > that different from an ithread, and it even means that there won't be > any sharing between instances even if the interrupt vector is shared. OK that (a taskqueue not getting the same fast preemption an ithread would) was just what I was afraid of. I'm glad that it is not a problem. <...> > However, taskqueues are really just a proof of concept for what I really > want, which is to allow drivers to register both a fast handler and an > ithread handler. For drivers doing this, the ithread would be private Ah, the darwin / MacOSX model. That would be very cool. Anyway, keep up the good work. It is inspiring! Drew