Tuning net.core.netdev_budget for Network Performance

High-traffic servers processing thousands of packets per second can experience packet drops and increased latency when the kernel's network subsystem runs out of processing budget during interrupt handling. The net.core.netdev_budget parameter controls how many packets the kernel processes in a single NAPI polling cycle, directly impacting the balance between network throughput and CPU fairness. Understanding when and how to tune this parameter prevents packet loss during traffic bursts while avoiding excessive CPU monopolization.

What is net.core.netdev_budget?

net.core.netdev_budget is a Linux kernel parameter that defines the maximum number of packets the kernel processes from all network interfaces during one NAPI (New API) polling cycle. The default value is 300 packets. When network traffic arrives, the kernel raises a soft interrupt (SoftIRQ) to poll network cards using NAPI routines. The budget limits how long this polling can continue before yielding the CPU to other processes, preventing network processing from starving other system tasks.

How NAPI Polling Works

The Linux kernel uses NAPI to efficiently handle high packet rates by batching interrupt processing. When packets arrive, the network card triggers a hard interrupt. The kernel disables further interrupts from that interface, schedules a SoftIRQ, and begins polling the network card for additional packets. The polling continues until either net.core.netdev_budget packets are processed or net.core.netdev_budget_usecs microseconds elapse—whichever limit is reached first. This batching reduces per-packet interrupt overhead while maintaining low latency.

Monitoring NAPI Budget Exhaustion

Check /proc/net/softnet_stat to identify budget exhaustion. The third column shows "squeezed" events—occurrences where the polling cycle ended with packets still queued because the budget or time limit was exceeded:

cat /proc/net/softnet_stat

Example output:

00000001 00000000 00000005 00000000 00000000 00000000 00000000 00000000 00000000 00000000

The third column (00000005 in this example) indicates five squeezed events. If this counter increases continuously under load, the current budget is insufficient for your traffic patterns.

Tuning the Budget

Increase net.core.netdev_budget when monitoring shows persistent squeezed events during peak traffic. Raise the value incrementally and retest:

# Check current value
sysctl net.core.netdev_budget

# Temporarily increase budget
sudo sysctl -w net.core.netdev_budget=600

# Make permanent
echo "net.core.netdev_budget = 600" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Pair budget adjustments with net.core.netdev_budget_usecs (default 2000 microseconds) to control time spent polling:

sudo sysctl -w net.core.netdev_budget_usecs=4000

Monitor squeezed counters after tuning. If they stop increasing, the new budget matches your workload. If they continue rising, further increases may be necessary.

When to Tune

Only adjust net.core.netdev_budget when observing specific symptoms:

• Packet Drops: Interface RX-DRP counters increase under moderate load (ip -s link show).
• Squeezed Events: /proc/net/softnet_stat third column increments rapidly during traffic spikes.
• High Latency: Latency-sensitive applications experience jitter coinciding with network bursts.

Modern kernels (4.x and newer) are well-tuned by default. Avoid changing this parameter on low-traffic systems or without baseline measurements—incorrect values can degrade performance by allowing network processing to monopolize CPU time.

Operational Tips

• Correlate with RPS/RFS: When tuning budget, also verify Receive Packet Steering (net.core.rps_sock_flow_entries) is configured to distribute interrupt load across CPUs.
• Test Under Load: Apply changes during maintenance windows and verify behavior with realistic traffic patterns using tools like iperf3 or production replay.
• Document Baselines: Record default values and squeezed counter rates before tuning to enable rollback if performance degrades.
• Use with IRQ Affinity: Combine budget tuning with interrupt affinity adjustments (/proc/irq/*/smp_affinity) to isolate network processing on dedicated cores.

Conclusion

net.core.netdev_budget provides fine-grained control over kernel network polling behavior, enabling operators to optimize throughput on high-traffic servers. By monitoring squeezed events and incrementally adjusting the budget, SREs can eliminate packet drops without sacrificing CPU fairness or system responsiveness.

For efficient incident management and to prevent on-call burnout, consider using Akmatori. Akmatori automates incident response, reduces downtime, and simplifies troubleshooting.

Additionally, for reliable virtual machines and bare metal servers worldwide, check out Gcore.