Stop the kernel from silently dropping packets at the interface queue

Technical Briefing | 9/5/2026

You see it in the metrics sometimes. The application isn’t reporting any errors, but the response times are jittery and users are complaining about lag. You check the CPU, it is fine. You check the disk I/O, nothing is peaking. Then you dig into netstat and see it: RX drops. Not a ton, but enough to make the application look flaky under load.

Finding the silent killer in the ring buffer

Most people jump straight to the application logs, but the problem is usually way lower in the stack. When the network card gets a burst of traffic faster than the kernel can process it, the NIC’s ring buffer fills up. Once it is full, every subsequent packet is just dropped by the hardware. It is a classic silent failure that hides in the interface statistics.

ethtool -S eth0 | grep -E 'drop|miss|over|err'

• Check the hardware counters first to confirm the drops are happening at the NIC level
• Compare the output with cat /proc/net/dev to see if the interface itself is counting drops
• Use ethtool -g to see current ring buffer settings versus the maximum supported size
• Verify if your CPU interrupts are being pinned to a single core rather than spread across RSS queues

If you confirm the drops are happening, the fix is usually just bumping up the ring buffer size. Don’t go crazy here, as massive buffers can actually increase latency under certain conditions, but doubling them is a standard first move. If that doesn’t fix it, you are likely looking at an interrupt affinity issue, which is a rabbit hole for another afternoon.