Enhancing Intel i210 Network Card Performance with Static IRQ Affinity on Linux

Understanding Interrupt Request Affinity

In a standard Linux configuration, the kernel dynamically assigns interrupts from hardware devices, such as network interfaces, to available CPU cores. While this automatic balancing works well for general-purpose computing, it introduces variability in performance. When an interrupt handler runs on a core that is already busy or has a cold cache, packet processing can suffer from delays. By manually setting the affinity of these interrupts, you ensure that the network driver’s interrupt handlers run exclusively on specified cores, leading to more predictable and higher performance.

This technique is particularly valuable for servers handling high-throughput network traffic, virtualization hosts, or any application where low latency is critical. The Intel i210 is a popular Gigabit Ethernet controller known for its reliability, but like many NICs, its default interrupt handling may not be optimized for heavy loads. Static affinity allows administrators to pin these interrupts to the first four cores of the system, isolating them from user-space applications and background services.

Identifying the Relevant IRQ Numbers

The first step in optimizing your Intel i210 card is identifying the specific Interrupt Request (IRQ) lines assigned to its network queues. Modern NICs often use multiple receive queues to parallelize packet processing, each associated with its own IRQ. You can view the current IRQ assignments by examining the /proc/interrupts file or using the lspci command to find the device address.

1. Find the PCI address: Run lspci | grep -i ethernet to locate your Intel i210 adapter. Note the bus:device.function identifier, typically starting with numbers like 03:00.0.
2. List IRQs: Execute cat /proc/interrupts and look for entries containing e1000e or i210. Each line represents a queue or feature, showing which CPU cores are currently handling the interrupts.
3. Note the IRQ numbers: Record the numerical IRQ values associated with the network interface. These are the identifiers you will modify in the next steps.

If you have multiple queues, you will see several IRQ lines for the same device. It is important to handle all relevant IRQs to ensure balanced performance across all receive channels. For a comprehensive guide on troubleshooting connectivity issues that might arise during hardware changes, you may refer to our article on Troubleshooting Linux Device Not Reachable During Network Ping.

Setting Static IRQ Affinity via sysfs

Linux exposes the ability to set CPU affinity for interrupts through the /proc/irq//smp_affinity interface. This file accepts a hexadecimal bitmask representing the CPU cores that should handle the interrupt. To bind an IRQ to the first four cores (CPU 0, 1, 2, and 3), you need to calculate the bitmask value.

The bitmask is calculated as 2^0 + 2^1 + 2^2 + 2^3 = 1 + 2 + 4 + 8 = 15. In hexadecimal, this is f. Therefore, to assign an IRQ to the first four cores, you write 0xf to the corresponding smp_affinity file. This operation must be performed with root privileges.

# Replace IRQ_NUM with the actual interrupt number found earlier
echo f > /proc/irq/IRQ_NUM/smp_affinity

You should repeat this command for every IRQ associated with your Intel i210 network queues. If you have four queues, you might distribute the load evenly or pin all to the same four cores depending on your workload. For single-queue setups, pinning to cores 0-3 is a safe default. Remember that changing these settings resets after a reboot, so persistence requires additional configuration.

Making the Configuration Persistent

Since modifying /proc/irq/*/smp_affinity is volatile, you need a mechanism to apply these settings automatically at boot. The most robust method is using a systemd service or a udev rule. A systemd service is often easier to manage and debug.

Create a script, for example /usr/local/bin/set-i210-affinity.sh, that iterates through the detected IRQs and sets their affinity. Then, create a systemd unit file /etc/systemd/system/i210-affinity.service that executes this script during the early boot phase. Ensure the service has After=network-pre.target and Wants=network-pre.target to guarantee the network interfaces are initialized before the affinity is set.

[Unit]
Description=Set IRQ Affinity for Intel i210
After=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/set-i210-affinity.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable the service with systemctl enable i210-affinity.service. This approach ensures that your performance optimizations survive reboots and updates. For users interested in other hardware diagnostics, checking your storage health is also crucial for overall system stability; see our guide on Check Hard Drive Status for Personal Photos in Linux.

Verifying Performance Improvements

After applying the static affinity, verify that the settings are active by checking /proc/irq/IRQ_NUM/smp_affinity again. Use tools like top or htop to monitor CPU usage on the pinned cores during network stress tests. You should observe a reduction in softirq time spikes and more consistent packet processing rates.

Additionally, consider using perf or bpftrace to measure interrupt latency before and after the change. A successful configuration will show lower variance in interrupt handling times. This optimization complements other network tuning parameters, such as increasing ring buffer sizes or adjusting TCP window scaling, to maximize the potential of your Intel i210 hardware.

Frequently Asked Questions

Can I set IRQ affinity for all CPUs instead of just the first four?

Yes, you can set the bitmask to include all available cores by calculating the sum of powers of two for each CPU index. However, spreading interrupts too widely can negate the benefits of cache locality, so limiting it to a subset of cores is often better for performance.

Does this configuration affect the transmit queues as well?

The primary focus of IRQ affinity is usually on receive interrupts, as they dictate how quickly packets enter the system. Transmit queues are often polled or use completion interrupts that are less frequent, but you can adjust their affinity similarly if needed for bidirectional traffic optimization.

What happens if I pin an IRQ to a core that is already overloaded?

Pinning an IRQ to an overloaded core can lead to increased latency and packet drops because the interrupt handler cannot run promptly. It is essential to choose cores that are relatively idle or dedicate specific cores solely for network processing to avoid contention.

Is there a risk of breaking network connectivity with this change?

There is minimal risk if you correctly identify the IRQs and maintain a valid bitmask. However, if you accidentally exclude all CPUs (by setting the mask to 0), the system may fail to process interrupts for that device. Always keep a console session open to revert changes if necessary.

How do I determine the correct bitmask for my specific CPU layout?

The bitmask corresponds directly to the CPU IDs reported by nproc or lscpu. If you want to target CPU 0 and CPU 2, the bitmask is 1 + 4 = 5, which is 0x5 in hexadecimal. You can use online converters or simple arithmetic to derive the hex value for your desired core selection.