Linux – NIC interface names in /proc/interrupts

ethernetinterruptslinuxnetworking

When I look at /proc/interrupts:

$ cat /proc/interrupts
           CPU0       CPU1
(...)
 12:          4          0    IO-APIC-edge  i8042
 14:        145   65310875    IO-APIC-edge  ide0
 50:          0          0   IO-APIC-level  uhci_hcd:usb5, Intel ICH7
 58:       5388    7983508   IO-APIC-level  libata
169:  812427252 1236572641   IO-APIC-level  skge, eth1
217:          6          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
225:          0          0   IO-APIC-level  uhci_hcd:usb3
233:         60 3108720778   IO-APIC-level  uhci_hcd:usb4, skge

I can see two skge and one eth1 entries. All of them are the network cards. Because of the general name "skge" (which is the name of the network driver of the card) I can't easily reocognize, which NIC occupies which interrupt.

How to make linux use more descriptive names in the entries?

Or: Is there any alternative way to obtain INT information instead of /proc/interrupt?

My final goal is to manipulate smp_affinities of the NICs.

Best Answer

On RH based systems you can name each nic by means of ifcfg-* scripts.

Simply specify the MAC address of the nic in orther to associate it to the right HW device, then give it a device name of your choice.

This way you should have "yournicname" listed instead of "eth1", so you can simply achieve your goal.

Here is a nice article with a number of ways you can follow to do this adjustment on various scenarios; depending on you distribution it may be more or less complicated.

Related Solutions

Linux – Alternative to /proc/interrupts

There are two common interfaces to kernel information ( other than syscalls ) and they are implemented as filesystems. Those two filesystems are /proc and /sys. sys is a little more organized than proc and newer, but not as user friendly. So it is a little bit better for programmers and to avoid parsing.

If you want the information from the sys filesystem (which lspci parses (see somefile that is outputted by strace -o somefile lspci)):

$ lspci | grep -i network
00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02)
$ cat /sys/devices/pci0000:00/0000:00:19.0/irq
2299

Notice the 00:19 relationship between the two commands. The number returned by the irq file will be the same as first column of /proc/interrupts for the relevant device.

If you want more information on the sys filesystem look at the documentation included with the kernel source, for example the text files in /usr/src/linux-source-2.6.27/Documentation/filesystems

Update:

Is there a way to connect the output with interface name?

Sure, if you play around with sys, you will find there are lots of symbolic links that point to other locations in sys. For example, in /sys/class/net:

[kbrandt@kb: /sys/class/net] ls -l
lrwxrwxrwx 1 root root 0 2009-11-02 11:01 eth0 -> ../../devices/pci0000:00/0000:00:19.0/net/eth0
lrwxrwxrwx 1 root root 0 2009-11-02 11:01 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 2009-11-02 11:01 pan0 -> ../../devices/virtual/net/pan0
lrwxrwxrwx 1 root root 0 2009-11-02 11:01 vmnet1 -> ../../devices/virtual/net/vmnet1
lrwxrwxrwx 1 root root 0 2009-11-02 11:01 vmnet8 -> ../../devices/virtual/net/vmnet8

So to get the irq for eth0, you can just:

cat /sys/class/net/eth0/../../irq

Ubuntu – Causes of High LOC Interrupts

It's the process for managing multi-CPU threading. See SMP Affinity and Proper Interrupt Handling in Linux for the answers you seek on how to lower it down, but basically its the way the system handles masking the interrupts the are being caused by the CPU's needing to be fed more thread streams or memory and only CPU0 being able to take on the interrupts.

The higher the value, the better the threading of the system is happening, and this is a good thing.

Best Answer

Related Solutions

Linux – Alternative to /proc/interrupts

Ubuntu – Causes of High LOC Interrupts

Related Topic