What is the most reliable way to programmatically determine the IRQs associated with a network interface, given the name of the interface (e.g. eth0)?
I'm okay with a best-effort approach, but I'd like it to work across a wide variety of drivers/configurations (i.e. without special handling for each driver), and I'd like to avoid false positives. I'd also like to avoid violating the rules for interacting with sysfs outlined here, but I'm okay with breaking them if necessary. I'll break them in the examples below.
/proc/interrupts is not ideal because the the names associated with the IRQs are driver-specific, and not reliable because there's nothing preventing two devices from having IRQs with the same name.
It would be nice if I could just do something like the following:
$ ls /sys/class/net/eth2/device/msi_irqs | cat /sys/class/net/eth2/device/irq 61 62 63
I've verified that these are the IRQs I'm looking for in this case using
But this doesn't work for all drivers. The IRQ files of interest are at different places, or nowhere to be found.
$ readlink -e /sys/class/net/eth2 /sys/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/eth2 $ ls $(readlink -e /sys/class/net/eth2)/../../msi_irqs 61 62 63
The msi_irqs of interest are two directories up from the /sys/class/net/eth2 symlink. The msi_irqs three directories up are not relevant to me.
$ readlink -e /sys/class/net/eth1 /sys/devices/pci0000:00/0000:00:03.0/virtio0/net/eth1 ls $(readlink -e /sys/class/net/eth1)/../../../msi_irqs 26 27 28
The msi_irqs of interest are three directories up from the /sys/class/net/eth1 symlink. There are no other msi_irqs files in this hierarchy.
$ readlink -e /sys/class/net/eth0 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBus:00/vmbus_0_11/net/eth0
The IRQ info doesn't seem to be in sysfs. I have to resort to grepping /proc/interrupts for the one and only "hyperv" IRQ.
The method I've resorted to using is searching from the directory at
$(readlink -e /sys/class/net/eth0) up to but not including
/sys/devices/pci<domain>:<bus>/ for the
irq file . My concern is that I could get the wrong IRQs by doing this. Maybe there is some reason the IRQs associated with the interface won't be published to
irq, but an ancestor device's IRQs will be published. I'll end up with the ancestor device's IRQs, which may not be what I want.
Is there a better way to reliably determine the IRQs associated with a network interface? If not, can the method described above return IRQs not associated with the interface?