Why Does Your Linux NIC Drop Packets? Understanding RX Errors, Overruns, and Tuning

Linux NIC packet reception flow

NIC receives a packet.

DMA moves the packet from the NIC hardware cache to server memory without CPU involvement.

A hard interrupt notifies the CPU.

The CPU triggers a soft interrupt for the kernel.

The TCP/IP stack processes the packet.

The application reads the data via read() from the socket buffer.

Diagnosing packet loss

Example ifconfig eth0 output shows RX/TX packet counts and error statistics.

# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.5.224.27  netmask 255.255.255.0  broadcast 10.5.224.255
        inet6 fe80::5054:ff:fea4:44ae  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:a4:44:ae  txqueuelen 1000  (Ethernet)
        RX packets 9525661556  bytes 10963926751740 (9.9 TiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8801210220  bytes 12331600148587 (11.2 TiB)
        TX errors 0  dropped 0  overruns 0  carrier 0  collisions 0

Use watch to monitor the interface periodically:

# watch -n 1 "ifconfig eth0"
# watch -n 1 ip -s link show eth0

Normal statistics

Abnormal statistics

Understanding RX error counters

RX errors : total receive errors, including too‑long frames, ring‑buffer overflow, CRC errors, frame sync errors, FIFO overruns, missed packets, etc.

RX dropped : packets entered the ring buffer but were discarded during copy to memory due to insufficient system resources.

RX overruns : FIFO overrun; the kernel cannot process incoming IO fast enough, causing the NIC FIFO to fill before packets reach the ring buffer.

RX frame : misaligned frames.

Difference between dropped and overruns

Dropped : packet reached the NIC’s receive FIFO and started being copied to system memory, but was discarded because of system constraints (e.g., low memory).

Overruns : packet never entered the FIFO; the FIFO was already full because the kernel could not service the NIC interrupt quickly enough, indicating CPU load or interrupt‑handling issues.

Ring buffer overflow

When the NIC’s ring buffer is too small, incoming packets fill it faster than the kernel can consume them, leading to drops. Statistics can be viewed with ethtool -S or /proc/net/dev.

# ethtool -S ens2 | grep fifo
     rx_fifo_errors: 0
     tx_fifo_errors: 0
# cat /proc/net/dev | grep ens2
  ens2:  659229    8107    0    0    0     0          0         0   249827    2833    0    0    0     0       0          0

Adjusting ring buffer size

# ethtool -G eth0 rx 4096 tx 4096
Pre‑set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096

Interrupt handling

An interrupt is a signal that temporarily halts the CPU’s current work. Hard interrupts are generated by hardware (e.g., NIC, disk, keyboard). Soft interrupts are generated by the kernel in response to hard interrupts.

When the NIC receives a packet, it raises a hard interrupt, the CPU stops its current task, and the kernel is notified. The kernel then schedules a softirq to copy the packet from the NIC cache to memory; if this copy is delayed, the packet may be dropped.

Multiqueue NIC and RSS

Modern NICs support multiple receive queues (multiqueue) to distribute packets across CPUs. Receive Side Scaling (RSS) hashes packet headers to select a queue, and IRQ affinity can bind each queue’s interrupt to a specific CPU, improving parallel processing.

RPS (Receive Packet Steering)

When the NIC lacks RSS, RPS implements a similar mechanism in software. After the NIC places packets in a single ring buffer, a single CPU processes the buffer, computes a hash for each packet, and forwards the packet to a per‑CPU backlog via an inter‑processor interrupt (IPI). Enabling RPS can increase CPU load.

IRQ affinity configuration

View per‑CPU interrupt statistics in /proc/interrupts. Set affinity by writing a CPU bitmask to /proc/irq/IRQ_NUMBER/smp_affinity. Example (bind IRQ 41 to CPUs 0 and 1):

echo 6 > /proc/irq/41/smp_affinity

Softirq statistics

cat /proc/softirqs
                    CPU0       CPU1
          HI:          1          0
       TIMER: 1650579324 3521734270
      NET_TX:   10282064   10655064
      NET_RX: 3618725935       2446
       BLOCK:          0          0
BLOCK_IOPOLL:          0          0
     TASKLET:      47013      41496
       SCHED: 1706483540 1003457088
     HRTIMER:    1698047   11604871
         RCU: 4218377992 3049934909

NET_RX shows the number of packets that triggered a softirq on each CPU; uneven distribution may indicate a lack of multiqueue support, which can be mitigated by enabling RPS.

netdev_max_backlog tuning

The kernel’s netdev_max_backlog queue holds packets after the NIC receives them but before the protocol stack processes them. Its default is 1000. Increase it with sysctl:

sysctl -w net.core.netdev_max_backlog=2000