Generate Linux UDP receiver tuning

1 profile produces a reviewable runbook

The kernel tuning generator takes packet rate, mean and maximum packet size, stall tolerance, burst multiplier, interface name, receive-thread count, and host role. It returns commands with the arithmetic beside them.

The initial profile represents one busy receiver, not a measurement. Enter locally observed packet frequency and average size. The product wire contract fixes the maximum packet at 1,228 bytes; traffic observations supply the mean.

The generator does not promise that one sysctl block fits every kernel. It produces a starting configuration, capability checks, and acceptance counters.

Method

Receive-buffer sizing follows the same model as the buffer calculator:

base_packets = ceil(pps * stall_seconds)packets_in_stall = base_packets * burst_multipliercharged_bytes = mean_packet_bytes + accounting_allowanceraw_rmem = packets_in_stall * charged_bytessocket_request = round_up(raw_rmem)

The generator proposes net.core.rmem_max at or above the socket request, with extra ceiling headroom selected by the user. The application still calls SO_RCVBUF. Raising a global ceiling does not resize an existing socket.

Backlog planning uses packet count:

backlog_packets = ceil(pps * scheduler_stall_seconds * burst_multiplier)

The netdev input-backlog sysctl limits a per-CPU queue when the network stack cannot process arrivals immediately. It is separate from socket memory and should never be derived from bytes.

NIC receive-ring recommendations are bounded by values reported through ethtool. Queue count is bounded by the NIC, driver, and CPU topology. The tool never emits an unsupported ring or queue setting as a mandatory command.

Generate settings for a 200 millisecond stall

Model 5,300 packets each second, a 1,184-byte average payload, 200 milliseconds, burst multiplier 4, and 512 accounting bytes.

base_packets = ceil(5,300 * 0.200) = 1,060packets_in_stall = 1,060 * 4 = 4,240charged_bytes = 1,184 + 512 = 1,696raw_rmem = 4,240 * 1,696 = 7,191,040 bytessocket_request = 8,388,608 bytes after rounding to 8 MiB

With a two-times ceiling policy, the generated starting point is:

net.core.rmem_max = 16777216application SO_RCVBUF request = 8388608

For a separate 80 millisecond scheduler-stall assumption:

backlog_packets = ceil(5,300 * 0.080 * 4) = 1,696

The generator can round that operating target upward, but it shows 1,696 as the derived count. An administrator should compare this value with the existing backlog setting and observed softnet drops before changing anything.

Generated sections

The sysctl section covers receive-memory ceiling, default receive memory when requested, and input backlog. It prints a temporary command and a persistent configuration fragment. The socket section states that the receiver must set SO_RCVBUF and verify the effective readback.

The NIC section begins with read-only commands for driver, ring bounds, channels, offloads, coalescing, and counters. Any proposed ethtool write is labeled optional and appears only after the user enters a supported value. Large rings can absorb bursts while adding queue residence time.

The CPU section maps receive queues and worker count to a proposed affinity layout. It avoids CPUs the user reserves for the operating system. It treats IRQ names and queue numbers as discovered values because interface naming differs by driver.

Busy polling and receive-flow steering remain opt-in. Some workloads see shorter scheduler wakeups, at the cost of CPU or cross-core movement. The generator explains which before-and-after counters to compare.

Apply one change at a time

Capture a baseline for interface traffic and drops, NIC counters, softnet processing, UDP errors, socket memory, application queue age, decode throughput, and CPU utilization. Apply one category, then repeat the same traffic or replay test.

This order matters because several changes can move a drop from one boundary to another. Increasing the socket buffer can remove kernel overflow while allowing a stale application backlog. Adding queues can spread interrupts while increasing cache movement. Lower interrupt moderation can improve median arrival while raising CPU cost.

The output includes rollback commands based on values the user pastes from the host. It does not invent previous values. Persist settings only after the temporary configuration survives a representative load and restart test.

Acceptance criteria

Run mean traffic plus short bursts and controlled receive-thread stalls. Observe no unexplained increase in NIC misses, softnet drops, UDP receive errors, or application gaps within the declared test. Confirm the oldest-packet age stays below the strategy deadline.

Inspect effective SO_RCVBUF through getsockopt or socket tooling. Linux often reports an internally doubled application request. Record both requested and returned amounts instead of assuming the convention.

Record the receive-to-decode median, p95, p99, and worst observation. Tuning that eliminates loss by holding packets for hundreds of milliseconds may fail a low-latency acceptance condition.

Limitations

Kernel names and behavior vary across versions, distributions, containers, virtual machines, drivers, and cloud platforms. Some sysctls are namespaced and others are host-wide. Managed hosts may deny changes.

The method starts from mean packet rate plus an assumed burst multiplier. Replace that multiplier with short-window measurements. The tool does not know unrelated traffic on the interface, hypervisor packet limits, NUMA layout, or provider policing.

No kernel setting repairs upstream loss or makes an application faster than sustained input. XDP, AF_XDP, DPDK, io_uring, and custom busy-poll designs require separate benchmarks and operational skills.

The generated commands are a change proposal. Read them, capture current values, and use the host's configuration management. A web tool cannot verify that the kernel accepted them or that the receiver improved.