Date: Mon, 17 Mar 2008 10:33:38 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@freebsd.org> 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 ... Message-ID: <18398.33113.488394.494142@grasshopper.cs.duke.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <irq> <cpu>'.
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18398.33113.488394.494142>