# leandromoreira/linux-network-performance-parameters: a map of Linux network sysctls, not a tuning preset

> This repository is a documentation project that places sysctl and ethtool parameters into the Linux ingress and egress packet flow. It is for engineers who need to know which knob acts at which stage, not for anyone looking for copy-paste values.

**leandromoreira/linux-network-performance-parameters** — Learn where some of the network sysctl variables fit into the Linux/Kernel network flow. Translations: 🇷🇺

- Repository: https://github.com/leandromoreira/linux-network-performance-parameters
- Website: https://github.com/leandromoreira/linux-network-performance-parameters
- Stars: 5,824 · Forks: 529
- Language: Unknown
- License: BSD-3-Clause
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/leandromoreira-linux-network-performance-parameters

## The problem: knowing which parameter acts at which stage of the packet path

Tuning advice for Linux networking usually arrives as a list of values. The list rarely says where in the stack each value takes effect, so a reader cannot tell whether raising a number removes a drop at the NIC or merely delays it inside the kernel. This repository takes the opposite approach. It walks the ingress path from the moment packets arrive at the NIC, through DMA into the receive ring buffer, the hard IRQ, NAPI polling, the ingress qdisc and the TCP receive buffer, and the egress path from the application's sendmsg call down to the transmit ring buffer. Each parameter is placed at the step where it applies.

The audience is narrow. It is for engineers debugging packet loss, latency or throughput on a Linux host who already know what a sysctl is and want to reason about cause and effect. The introduction is explicit that the project is a brief tutorial, not a tuning guide, and it warns that you might hurt performance if you mess with the defaults, linking to a discussion of the bandwidth-delay problem. Anyone who wants a set of values to paste into sysctl.conf will not find it here, and the README does not pretend otherwise.

## How the repository organizes the flow: numbered ingress and egress steps

The core of the README is two numbered lists. Ingress has 24 steps, from the NIC verifying MAC and FCS through DMA into the rx ring buffer, the hard IRQ, soft IRQ and NAPI polling, sk_buff allocation, the tc ingress qdisc sized by netdev_max_backlog, netfilter PREROUTING and LOCAL_IN, the L4 protocol handler, socket lookup, the TCP finite state machine, and finally the receive buffer sized by tcp_rmem with optional autotuning through tcp_moderate_rcvbuf. Egress has 20 steps, from sendmsg through sk_buff allocation, the socket write buffer sized by tcp_wmem, TCP and IP header construction, netfilter LOCAL_OUT and POST_ROUTING, fragmentation, the output qdisc of txqueuelen length, the tx ring buffer, soft IRQ NET_TX_SOFTIRQ, DMA mapping, and the completion IRQ that frees the memory.

That structure is the whole value of the project. A parameter such as netdev_budget_usecs appears at step 9 of ingress, next to the polling loop it bounds, rather than in an alphabetical list. The second half of the README repeats each parameter in a What, Why and How format. Ring Buffer, for example, is described as a driver receive or send queue with a fixed size, usually a FIFO in RAM; the Why column says you may need to increase it when you see drops or overrun, and notes that the side effect might be increased latency. The How column gives the check, change and monitoring commands. The same pattern covers Interrupt Coalescence, ingress qdisc, egress qdisc, and the TCP read and write buffers.

## Installing it and reading the first parameter: ring buffer size

There is nothing to install. The repository contains README.md, README_RU.md, readme_zh-cn.md, an img/ directory and a LICENSE file. The homepage field points at the GitHub repository itself, and there is no package, no binary and no build step. You read it in a browser or clone it.

The first practical use is checking the ring buffer, which the README lists as the driver receive and send queue. The check command is ethtool with the -g flag against an interface, which prints the current and maximum ring sizes. If the current value sits below the maximum and the monitoring command shows drops, the README's stated remedy is to raise it, with the caveat that latency may rise as a result.

```bash
ethtool -g ethX
```

After reading the current values, the change command takes explicit rx and tx values. The README gives the form below, and the monitoring command filters the interface statistics for error, drop, overrun, miss, timeout, reset, restart and collision counters, hiding any that are still zero.

```bash
ethtool -G ethX rx value tx value
ethtool -S ethX | grep -e "err" -e "drop" -e "over" -e "miss" -e "timeout" -e "reset" -e "restar" -e "collis" -e "over" | grep -v "\: 0"
```

For interrupt coalescence the pattern repeats with different flags: ethtool -c reads the current rx-usecs, tx-usecs, rx-frames and tx-frames settings, and ethtool -C changes them. The README describes the trade-off directly: waiting longer before raising the hard IRQ reduces CPU usage and can raise throughput, at the cost of latency. To observe the flow itself rather than a single counter, the README shows a perf trace inside a container, tracing the net subsystem while pinging.

```bash
perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null
```

## Where this repository stops being useful

The README does not give recommended values. Every How block follows the same shape: a check command, a change command with a placeholder such as value, and a monitoring command. A reader who wants to know what to set rx-usecs to on a 10 GbE NIC will not find an answer. The introduction says as much, calling the search for cargo cult values unrealistic and noting that newer kernels are tuned well by default. That is a deliberate editorial choice, but it means the repository cannot be used as a configuration source without a separate measurement process.

There is also no rollback guidance. The README does not document how to revert a ring buffer or coalescence change, and it does not state whether ethtool -G and ethtool -C settings survive a reboot or a driver reload. Since these are not sysctl values written to a file, the persistence question matters, and the repository is silent on it. The same applies to the sysctl parameters: the README explains what tcp_rmem and tcp_wmem govern and where they sit in the flow, but it does not cover where to write them, how to apply them to a running system, or how to verify that a change took effect beyond re-reading the value. For a production change window, that gap has to be filled from another source.

The material also assumes a conventional single-host setup. There is no discussion of container network namespaces, virtual interfaces, offload interactions, or multi-queue RSS configuration beyond the mention that ring buffers may be single or multiple queues. If your bottleneck is inside a veth pair or an overlay network, the ingress and egress lists still describe the general path, but the parameters they name may not be the ones that matter.

## Alternatives: kernel documentation and the illustrated stack guides

The most direct alternative is the kernel's own networking sysctl documentation, which the README links as its reference for sysctl. That document is authoritative and complete: it defines every parameter, its type, its default and its interaction with other settings. What it does not do is place those parameters in execution order. Reading ip-sysctl.txt tells you what tcp_moderate_rcvbuf does; it does not tell you that it acts at step 22 of the ingress path, after the socket lookup and inside the receive buffer sizing. The repository's contribution is that ordering, and it is the reason to read both rather than one.

A second alternative is the illustrated guide to the Linux networking stack from packagecloud, which the README cites as a heavy inspiration, along with posts by Marek Majkowski. Those sources go deeper into individual mechanisms, particularly the receive path and low-latency tuning, with more code-level detail than a README can carry. The trade-off is scope: they are longer and less scannable when you want to answer a narrow question such as which stage drops packets when an interface reports overruns. This repository is the index; those are the chapters. If you need to understand the NAPI polling loop in detail, go to the sources it cites. If you need to remember where netdev_budget sits relative to netdev_max_backlog, the numbered list is faster.

## Maintenance, licence and the cost of keeping it accurate

The repository is not archived, and the last push was on 2026-06-03. The README carries a request for corrections and suggestions, and the presence of Russian and Simplified Chinese translations (README_RU.md and readme_zh-cn.md) indicates the document is maintained as a shared reference rather than a one-off post. There are no releases, so there is no version to pin and no changelog to read. Updates arrive as commits to the README files.

That raises a real cost for anyone relying on it. Kernel networking internals change: function names, the order of certain steps and the defaults of some parameters are not frozen. A reader following the ingress list is reading a description of a particular kernel generation, and the README does not state which version the flow was written against. When a step does not match what you observe with perf trace, the discrepancy is as likely to be a kernel version difference as an error in the document.

The licence is BSD-3-Clause, which permits reuse and modification with the standard conditions: retention of the copyright notice, the list of conditions, and the disclaimer, and no use of the author's name to endorse derived work. Translations exist in the repository, so anyone forking to add another language should keep the same notice. This is a description of the licence text, not legal advice.

## Conclusion

Adopt this as a reading reference when you need to know whether a drop happens in the ring buffer, the ingress qdisc or the TCP receive buffer, and as a source of the exact ethtool and sysctl commands for each stage. Do not adopt it expecting a tuning preset: the introduction states that the search for cargo cult values that work everywhere is not realistic, and that newer kernels are well tuned by default. Before acting on any parameter, verify the current value on your own interface with ethtool -g, ethtool -c and sysctl, and confirm the kernel version in use, because the repository documents the flow rather than a supported configuration.

## FAQ

### How do I increase the TCP buffer size in Linux with leandromoreira/linux-network-performance-parameters?

The repository places the TCP receive buffer at step 22 of the ingress path, sized by tcp_rmem, and the write buffer at step 3 of the egress path, sized by tcp_wmem. It explains what each governs and notes that tcp_moderate_rcvbuf enables kernel autotuning, but it does not give recommended values or the file to write them to.

### How do I measure network throughput in Linux according to this repository?

The README has a network tools section for testing and monitoring, and it shows a perf trace example that traces the net subsystem while pinging. For interface-level counters it gives ethtool -S with a grep filter for error, drop, overrun, miss, timeout, reset, restart and collision fields.

### How can I test my LAN speed on Linux using the tools this repository mentions?

The repository does not cover LAN speed testing as such. Its monitoring examples are ethtool -S for interface statistics and a perf trace of the net subsystem during a ping, which show where packets are handled rather than how fast the link is.

### How do I measure network performance with the parameters this repository documents?

The README pairs each parameter with a monitoring command rather than a benchmark. For ring buffers and coalescence that means ethtool -S filtered for drop, overrun and timeout counters, and for the full path it shows perf trace with the net event class.

## Sources

- [Issues](https://github.com/leandromoreira/linux-network-performance-parameters/issues)
- [leandromoreira/linux-network-performance-parameters on GitHub](https://github.com/leandromoreira/linux-network-performance-parameters)
- [License: BSD-3-Clause](https://github.com/leandromoreira/linux-network-performance-parameters/blob/master/LICENSE)
- [Project website](https://github.com/leandromoreira/linux-network-performance-parameters)
- [README](https://github.com/leandromoreira/linux-network-performance-parameters/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leandromoreira-linux-network-performance-parameters