Reference

Linux UDP receive sysctl reference

Tune every Linux network sysctl on the normal high-rate IPv4 UDP receive path with defaults, receiver values, and parameter-specific failure modes.

Baseline assumptions

The recommended column targets a dedicated receiver and provides a starting configuration for testing. Validate it against packet rate, burst behavior, latency, and drops measured on the deployed kernel, NIC, driver, namespace, and workload.

Linux defaults below are upstream defaults where one fixed value exists. A distribution, kernel configuration, boot-time memory calculation, container runtime, or loaded module can change the active value. Read every deployed value before applying a change.

Socket memory

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.core.rmem_default	Current upstream: 256 times SKB_TRUESIZE(256), so the byte value is architecture dependent; older common builds report 212,992 bytes	Keep the active default; have the application request 4,194,304 bytes with SO_RCVBUF	Default receive limit for sockets that make no request	Leaving both default and application request small causes UdpRcvbufErrors during pauses; raising the global default needlessly enlarges unrelated sockets
net.core.rmem_max	Current upstream: 4,194,304 bytes; older common kernels report 212,992 bytes	134,217,728 bytes	Ceiling for an ordinary SO_RCVBUF request	Too low silently caps the requested socket buffer; far above a host memory budget permits many sockets to consume excessive kernel memory under load
net.core.optmem_max	131,072 bytes	131,072 bytes	Maximum ancillary and option memory per socket	Too low can truncate timestamp or control data under complex ancillary use; raising it does not increase UDP payload queue capacity
net.ipv4.udp_mem	Computed at boot from available memory, in pages	Keep the boot-computed triplet unless host-wide UDP pressure is measured and budgeted	Low, pressure, and high thresholds for all UDP socket memory	A low high-threshold drives global UDP memory pressure and drops across sockets; a copied oversized triplet can expose the host to uncontrolled kernel-memory use
net.ipv4.udp_rmem_min	4,096 bytes	4,096 bytes	Minimum receive allocation retained per UDP socket under protocol memory pressure	Lower values make active sockets more fragile during global pressure; raising it across many sockets reserves more pressure-time memory without fixing a slow receiver

Raise the host receive-memory ceiling before socket creation. The process then requests SO_RCVBUF and reads back the effective amount. Linux commonly exposes twice the requested value because of socket accounting, so 4,194,304 requested bytes can appear as 8,388,608.

Input backlog and NAPI budgets

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.core.netdev_max_backlog	1,000 packets	8,192 packets on a dedicated host after a burst test	Maximum per-CPU input backlog when packets arrive faster than the stack processes them	Too low increments the softnet drop field during bursts; too high hides CPU starvation as older queued packets and raises cache and memory pressure
net.core.netdev_budget	300 packets	600 packets on a dedicated receiver, provided ingest scheduling remains inside budget	Maximum packet work in one networking poll cycle	Too low raises softnet time-squeeze events and backlog; too high lets networking occupy the CPU long enough to delay the application that must drain the socket
net.core.netdev_budget_usecs	2,000 microseconds	2,000 microseconds	Time limit for one networking poll cycle on kernels that expose it	Too low defers pending packets and grows the backlog; too high creates scheduler latency spikes for a colocated receive thread
net.core.dev_weight	64 packets	64 packets	Base per-NAPI poll weight used in budget accounting	Too low increases repeated poll scheduling under bursts; too high lets one poller dominate a CPU and delay user space
net.core.dev_weight_rx_bias	1	1	Biases global budget toward receive softirq work relative to the base weight	Too low can starve receive backlog work; too high can starve the socket consumer on the same CPU
net.core.dev_weight_tx_bias	1	1	Biases global budget toward transmit softirq work	Raising it on a receive-focused host can spend the cycle on unrelated transmit work while the feed backlog grows
net.core.gro_normal_batch	8 packets	8 packets	Batch size for normal GRO processing	Too large can increase batching delay and burst delivery into the UDP socket; too small increases per-packet stack work and can raise CPU pressure

For every softnet_stat row under /proc/net, read fields two and three as deltas. A backlog setting cannot repair NIC-ring drops, and a socket-buffer setting cannot repair an earlier softnet drop.

Busy polling

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.core.busy_read	0 microseconds	0 globally; test SO_BUSY_POLL of 50 microseconds on the receiver socket	Default busy-poll duration for blocking reads	Zero can leave scheduler wakeup tails; a large global value burns CPU on unrelated sockets and can starve decode workers
net.core.busy_poll	0 microseconds	0 globally; test 50 microseconds only on a dedicated host if per-socket control is unavailable	Default busy-poll duration for poll and select paths	Too low gives no wakeup benefit; too high can saturate a core during quiet periods without improving packet age

Busy polling requires support across the kernel, driver, NAPI association, privileges, and socket configuration. SO_BUSY_POLL_BUDGET and epoll's busy_poll_budget field are not sysctls, so they remain outside the table. A value without a compatible NAPI path changes nothing. Measure p50, p99.9, CPU, softnet counters, socket drops, and decode age together.

Steering and timestamp placement

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.core.rps_sock_flow_entries	0	0 for one dedicated hardware-steered feed; size only when RFS is intentionally configured	Global Receive Flow Steering table size	Enabling it without per-queue flow counts adds no useful RFS placement; oversized tables consume memory, while poor steering adds cross-CPU cache movement
net.core.netdev_tstamp_prequeue	1	1 for ordinary operation; 0 for a controlled benchmark that requires post-queue timestamp placement	Allows receive timestamps before receive-packet steering and queueing	A value inconsistent across compared feeds moves timestamp boundaries and invalidates a race; disabling prequeue can add queue delay to the recorded timestamp

RPS and RFS also require per-queue sysfs masks and flow counts, outside sysctl. Given sufficient NIC hardware queues, one critical UDP tuple normally benefits more from stable flow affinity than software movement between CPUs.

IPv4 demultiplexing and fragments

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.ipv4.ip_early_demux	1	1	Performs early socket lookup for supported local traffic	Disabling adds later lookup work and can raise CPU cost; enabling is inappropriate only when a documented routing workload requires otherwise
net.ipv4.udp_early_demux	1	1	Enables early demultiplexing for connected UDP sockets	Disabling can add receive-path lookup cost; relying on it for an unconnected listener gives no guarantee of the same fast path
net.ipv4.ipfrag_high_thresh	4,194,304 bytes	4,194,304 bytes	Maximum memory held for IPv4 fragment reassembly before pruning	Too low drops legitimate fragmented traffic; too high lets fragment floods retain more memory and CPU, while this feed should fit inside a normal 1,500-byte MTU
net.ipv4.ipfrag_low_thresh	3,145,728 bytes on older kernels that expose it; absent on newer kernels	Keep the active default if present	Older-kernel target below which fragment memory was pruned	Raising it delays memory reclamation; lowering it increases reassembly failure, and tuning it cannot fix a path that fragments 1,228-byte UDP payloads unexpectedly
net.ipv4.ipfrag_time	30 seconds	30 seconds	Maximum retention time for an incomplete IPv4 fragment queue	Too long retains attack or loss debris and memory; too short drops fragments on slow paths, though normal feed datagrams should not fragment
net.ipv4.ipfrag_max_dist	64	64	Maximum disorder distance used to detect likely unrelated fragments from one source	Too low discards reordered legitimate fragments; too high permits more stale fragment state, while a clean shred path should avoid fragmentation

Do not raise fragment thresholds to conceal an MTU failure. An ordinary 1,500 bytes of path MTU carries the documented UDP maximum without fragmentation under usual IPv4 and UDP headers.

Reverse-path filtering

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.ipv4.conf.all.rp_filter	0 upstream; some distributions set 1	1 on a single-homed symmetric receiver; 2 on an intentionally asymmetric multihomed receiver	Global reverse-path source validation mode	Strict mode drops valid packets silently when the reverse route selects another interface; mode 0 accepts spoof-prone paths that policy may expect to filter
net.ipv4.conf.default.rp_filter	0 upstream; distribution value can differ	Match the intended policy for future interfaces	Template applied when new interfaces appear	A wrong template makes behavior change after interface recreation or reboot even when the current interface looked correct
net.ipv4.conf.INTERFACE.rp_filter	Inherits the default when the interface is created	1 for symmetric routing or 2 for approved asymmetry	Interface-specific reverse-path mode	A conflicting interface value can drop 203.23.178.228 on one path while captures elsewhere appear healthy

Mode 0 disables reverse-path checks, mode 1 is strict, and mode 2 is loose. Before selecting one, test both the receiving interface and its actual route back toward 203.23.178.228.

Conntrack, when loaded

Sysctl	Linux default	Recommended receiver value	Meaning	Concrete failure when wrong
net.netfilter.nf_conntrack_max	Set from the conntrack hash size at module initialization	Keep the host capacity plan with sustained count below 70 percent; use notrack for this tuple on a non-NAT dedicated receiver	Maximum tracked connections	Too low drops new flows with table-full events; too high consumes kernel memory and permits long hash chains under hostile traffic
net.netfilter.nf_conntrack_buckets	Computed from memory when the module loads, bounded by kernel minimum and maximum	Keep the computed value unless bucket-chain measurements support a change	Conntrack hash-table bucket count	Too few buckets raise lookup CPU and latency at a given flow count; too many waste kernel memory
net.netfilter.nf_conntrack_udp_timeout	30 seconds	30 seconds when tracking is required	Timeout for ordinary unassured UDP entries	Too short churns state during feed pauses or breaks NAT mappings; too long retains spoofed one-way flows and table occupancy
net.netfilter.nf_conntrack_udp_timeout_stream	120 seconds	120 seconds when tracking is required	Timeout for UDP flows that have seen traffic in both directions	Too short expires bidirectional state unexpectedly; too long retains inactive assured entries
net.netfilter.nf_conntrack_checksum	1	1	Verifies incoming transport checksums before admitting packets to conntrack	Disabling allows corrupt packets into state tracking; enabling adds checksum work but protects state integrity
net.netfilter.nf_conntrack_acct	0	0 unless per-flow byte and packet counters are required for diagnosis	Adds accounting counters to conntrack entries	Enabling adds per-packet accounting work and memory; disabling removes per-flow counters but not protocol or firewall counters

Conntrack sysctls exist only when that subsystem is present inside the namespace. A stable feed tuple uses about one entry, while packet rate determines lookup work. On a non-NAT receiver with a narrow stateless firewall, an early notrack rule can remove feed traffic from conntrack instead of tuning a global table around one flow.

Apply changes as experiments

Stage	Counter or observation	Sysctls that can affect it
NIC	Driver missed, no-buffer, discard, and queue counters	None in this scope; use driver and ethtool controls
NAPI and softnet	Backlog drops and time-squeeze deltas	netdev_max_backlog, netdev_budget, netdev_budget_usecs, dev_weight fields
UDP socket	UdpRcvbufErrors, per-socket drops, receive allocation	rmem_max, application SO_RCVBUF, udp_mem
Application	Queue rejects and receive-to-decode age	No sysctl substitutes for application capacity
Clock instrument	Timestamp boundary and uncertainty	netdev_tstamp_prequeue plus socket timestamp options
Stateful firewall	Conntrack count, insert_failed, drop, early_drop	nf_conntrack fields

Change a single receive-path layer per experiment. Reboot or recreate the namespace when testing persistence. Record kernel release, active values, NIC and driver, queue mapping, receiver build, packet distribution, loss counters, CPU, and latency before and after.

Questions

Which receive-buffer values should a shred receiver start with?: For a dedicated Linux host, keep its active default receive memory, set the ordinary request ceiling to 134,217,728 bytes, and request 4,194,304 bytes through SO_RCVBUF. Record the returned effective amount, then validate it with controlled pauses, UdpRcvbufErrors, per-socket drops, queue residence, and catch-up time.
Should busy polling be enabled globally?: Leave both global busy-poll sysctls at zero initially. On a dedicated receiver, test SO_BUSY_POLL of 50 microseconds at the target socket. A useful result lowers tail latency without socket loss or a saturated ingest core. Global settings affect unrelated sockets and can waste CPU continuously.
Can sysctl tuning eliminate UDP loss?: No. Sysctls can move or resize specific kernel queues, but they cannot repair NIC loss, an undersized driver ring, bad affinity, sustained application under-capacity, a restrictive firewall, or upstream absence. Locate the first rising drop counter, change the control for that stage, and verify packet age as well as loss.