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 ...

[Andrew Gallatin]

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