From owner-cvs-all@FreeBSD.ORG Mon Mar 17 14:34:07 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B379A106566C; Mon, 17 Mar 2008 14:34:07 +0000 (UTC) (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 53E508FC30; Mon, 17 Mar 2008 14:34:07 +0000 (UTC) (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.14.2/8.14.2) with ESMTP id m2HEY6eC000909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 10:34:06 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id m2HEXcrV038629; Mon, 17 Mar 2008 10:33:38 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18398.33113.488394.494142@grasshopper.cs.duke.edu> Date: Mon, 17 Mar 2008 10:33:38 -0400 (EDT) To: John Baldwin In-Reply-To: <200803170952.42262.jhb@freebsd.org> References: <200803141941.m2EJfmL2020579@repoman.freebsd.org> <20080316145259.A37148@grasshopper.cs.duke.edu> <200803170952.42262.jhb@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/arm/arm intr.c src/sys/i386/i386 intr_machdep.c src/sys/i386/include intr_machdep.h src/sys/ia64/ia64 interrupt.c src/sys/kern kern_intr.c ... 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: Mon, 17 Mar 2008 14:34:07 -0000 John Baldwin writes: > > I already have in my tree an amd64/i386-specific sysarch request to bind an > IRQ to a CPU, but it's sort of a pain to use since we don't expose interrupt > info to userland very well so the sysadmin can't tell which CPU an IRQ is > already connected to w/o a verbose dmesg. The first thing I plan to > implement is the aforementioned bus_bind_intr(9) for device drivers to use. More than that, an admin cannot tell what MSI-X vector corresponds to what functionality. For example, on linux, the driver can attach a custom label to the irq information seen from cat /proc/irq. Hence my linux 10GbE driver attaches meaninful labels to each MSI-X vector it uses. Eg, for 2 "slices" (what we call qsets), we have this on Linux: % grep eth0 /proc/interrupts 510: 0 0 PCI-MSI-edge eth0:slice-1 511: 0 5 PCI-MSI-edge eth0:slice-0 But on FreeBSD: % vmstat -i | grep mxge irq256: mxge0 318254 74 irq257: mxge0 311469 73 So I'd like the driver to be able to append a custom string (":slice-%d") to the label used by vmstat -i so the adminstrator can know what he's binding. > I'm not sure what the sysadmin interface will look like. Probably the ideal > is to make the UI do what my existing little tool does 'ibind '. > However, the MI code doesn't actually know anything about IRQ values. > Probably would need some sort of MD helper routine to that takes the > requested 'IRQ' value and maps it to an interrupt event. Also, the code does > not currently differentiate between a userland (administrative) bind request > vs. a driver bind request. My guess is that the administrative requests > should have precedence over the driver request. I also think driver requests > need to fail with EBUSY like they do now if the interrupt is already bound > whereas administrative requests should maybe fail with EBUSY if the driver > has bound it unless the sysadmin uses a force option (ibind -f or some such). This sounds reasonable. Thanks again, Drew