Eric Dumazet and the small queues shaping Linux server economics

Summary

• Eric Dumazet is currently a Linux maintainer for core networking, TCP and sockets, and sits on the Netdev Foundation Technical Committee. These responsibilities are shared with other maintainers and reviewers: they confer substantial integration responsibility, not sole authority over the networking stack.
• His most readable named contribution is TCP Small Queues, introduced in 2012 to prevent a single TCP flow from placing an excessive amount of data in the queues below the transport. By linking local socket credit to packet completion, TSQ reduced sender-side latency and memory pressure without claiming to remove every queue in the path.
• His work onsch_fqand TCP internal pacing made transmission timing an explicit variable. Fair queueing separates flows; pacing spreads packets over time. These mechanisms support several congestion controls, including environments using BBR, but BBR has a distinct history and distinct authors.
• His more recent work connects structure layout, cache-line traffic and per-socket state to fleet efficiency. The general lesson is that Linux networking accounts for CPU, memory, queues and time. The economic effect can be significant at scale, although no precise amount or universal gain can be publicly established.

A fast server can still lose time behind its own packets

The best starting point is neither a company title nor a conference stage, but a transmit queue inside a Linux host. The application has written data, TCP believes it can send more, and the kernel has handed the data to the lower layers. To the application, the data appears to have left; in reality, it may still be queued inside the same machine.

Throughput remains high and masks the problem. An interactive request waits behind a bulk transfer, buffers hold memory, and TCP’s notion of “in flight” data drifts away from what is merely stacked locally. TCP Small Queues changed this balance by limiting what a socket can place below TCP and tying the resumption of transmission to real hardware progress.

The public archives tell the engineering, not a manufactured biography

The strongest evidence comes from the kernel: theMAINTAINERSfile, patch discussions, documentation, conferences and years of public review. They establish sustained responsibility for core networking, TCP and sockets, a seat on the Netdev Foundation committee, and a visible Google affiliation in the maintainer address.

They do not provide a complete biography, a verified current job title at Google, or an exhaustive count of patches and reviews. Inventing those details would weaken the portrait. The article therefore relies on what can be examined directly: mechanisms, review decisions and technical explanations. Dumazet appears as an engineer of responsibility, whose work becomes infrastructure only after review, modification, testing and deployment by others.

Maintainer status places him close to decisions, not above the community

As of 4 August 2026, the Linux registries listed Dumazet for core networking, TCP and sockets. A maintainer can request a redesign, reject an interface that is too costly to maintain, merge an accepted change and represent the subsystem to the mainline kernel.

The same source shows that this power is shared. David S. Miller, Jakub Kicinski and Paolo Abeni are among the core networking maintainers; Neal Cardwell shares TCP responsibility, with reviewers and specialists acting according to the patch. Decisions also pass through architectures, drivers, automated tests, stable fixes and the mainline process. Dumazet’s influence is strong because it operates within this distributed system, not because it abolishes it.

Linux became economic infrastructure as the number of connections rose

On a small machine, a few extra bytes in a socket structure or a cache miss can go unnoticed. On a server carrying hundreds of thousands of connections, the same cost multiplies until it competes with the application, memory and energy.

This is the context in which Dumazet’s work takes on an economic dimension. It does not allow a publicly calculated amount of money saved. It acts on more concrete variables: connection density, CPU share left to the service, memory held by networking, and latency caused by local queues. The effect remains indirect: distributions and operators choose the kernel, qdisc, congestion control and NIC settings. Dumazet changes the common foundation from which those choices are made.

TCP’s familiar role hides very dense accounting

TCP is often presented as a reliable byte stream. Its implementation must nonetheless decide how much data may remain in flight, when to retransmit, how to charge memory, how to order packets, and how to share CPU and queues among thousands of sockets.

A stack can therefore be correct and still behave badly: a local queue that is too deep, bursts, contention, or structures that needlessly occupy cache. The common thread in Dumazet’s work is accounting. Bytes are charged to the socket, completion returns credit, send times are calculated, flows are separated, and hot fields are distinguished from cold fields. The goal is to keep the link busy without building a second hidden network inside the server.

Before TCP Small Queues, a sender could build a queue it no longer controlled

Before TSQ, TCP could hand a great deal of data to the qdisc and the driver. The congestion window could be reasonable from the path’s perspective, while a long local queue still held packets below the transport. An application could no longer withdraw them when a more urgent flow appeared.

This queue blurred the feedback. TCP reasoned about acknowledgements and data in the network, but a significant share had not yet left the host. It also consumed memory, especially when many flows did the same. The system needed to preserve throughput without letting each socket use the lower layers as an unlimited warehouse.

The 2012 TSQ series gave the socket a local queue budget

The 2012 patch series set a per-socket limit on the amount of data placed below TCP. Once that credit was spent, the socket stopped; when packets were completed, it could send again.

The idea seems modest: count local bytes and use completion as proof that the lower layer is making progress. Its importance comes from moving control to the transport that understands the flow. Throughput no longer requires a socket to deposit a large reserve in advance. The NIC remains busy, but TCP state tracks the real departure of packets more closely. Applications that have never heard of TSQ still benefit from this internal accounting rule.

Packet completion became a useful signal inside the host

The completion path could be nothing more than buffer cleanup. TSQ treats it as information: part of the lower stack has advanced, so the socket can receive a new right to transmit.

This local feedback complements remote acknowledgements. Those describe progress on the path; completion describes progress below TCP; qdisc and driver statistics show other forms of contention. No single signal is sufficient. TSQ made one of them useful for limiting local excess without replacing end-to-end congestion control.

TSQ reduced one source of bufferbloat, not every queue in the network

Presenting TSQ as the end of bufferbloat would be false. It limits the delay created below TCP by a sending socket. Queues remain possible in the qdisc, the driver, the NIC, the access network, routers, switches and the receiver.

The narrower conclusion is more useful: TSQ prevents a flow from too easily building a large hidden queue in the host. It can reduce latency and memory and bring the transport state closer to hardware progress. It replaces neither active queue management, nor good queue sizing, nor congestion control.

Thresholds, offloads and workloads determine TSQ’s real benefit

TSQ’s effect depends on the local limit, packet size, qdisc, device queues, segmentation and the mix of flows. An interactive service with many short transfers does not necessarily get the same result as bulk replication.

The implementation has also evolved since 2012. Other contributors adjusted thresholds, fixed interactions and integrated the mechanism into the rest of the stack. It is legitimate to credit Dumazet with the origin of the idea without presenting the current state as his unchanged and exclusive work.

sch_fqseparated flows and introduced time into scheduling

In 2013, Dumazet published the Linux schedulersch_fq. It maintains per-flow state and a time-ordered structure so that packets are released according to their target time. New flows can be served quickly, while paced flows wait for their deadline.

The mechanism addresses two problems: preventing a large transfer from occupying the entire local queue, and giving TCP a scheduler capable of respecting a pace. It does not guarantee equality between applications; it provides a more disciplined service policy and an execution point for the transmit times calculated by the transport.

Queue fairness is a policy, not universal equality

The word “fair” can be misleading. Separating flows at a local queue does not guarantee the same performance to every application. Packet size, path, receiver, congestion control, offloads and the number of connections still matter.

The identity of a flow is itself a choice: one application can open many connections, another only one.sch_fqreduces the dominance of a single flow without deciding what is fair between users or companies. For the operator, the benefit is concrete: better local arbitration and a basis for pacing, not the resolution of every priority.

Pacing turns an estimated rate into a series of transmit times

A congestion control can determine a rate or an amount of in-flight data, then release that permission as a burst. The average rate looks correct, but the burst briefly creates an intense queue.

Pacing spreads packets over time. It stabilises the queue, makes sharing easier and allows the congestion model to express its intention more clearly. The implementation is complex: timestamps, timers, qdisc, segmentation and NIC behaviour must converge. A software rate is useful only if it becomes a coherent physical sequence on the wire.

Pacing and congestion control address two different parts of the problem

Congestion control decides how aggressive the flow may be; pacing decides when the authorised data leaves. A good algorithm can be betrayed by bursts, and perfect pacing can execute a rate that is too high if the model is wrong.

Dumazet’s work is therefore execution infrastructure. It allows different algorithms to translate a rate into time. The credit for a particular model belongs to its designers, even though it depends deeply on kernel pacing.

BBR uses pacing but has its own authors and its own history

BBR is often associated with Dumazet because it depends on pacing and was developed in a Google environment where he plays an important role on TCP. That proximity does not make him the sole inventor of BBR. The model and its versions have distinct authors.

Dumazet’s contribution is that of a foundation: scheduling, pacing, instrumentation and socket accounting make certain congestion controls deployable. This history gives his work more value than an exaggerated attribution would, while preserving credit for Neal Cardwell and the other engineers in the field.

TSO saves CPU and can recreate the burst that pacing wanted to avoid

TCP Segmentation Offload allows the kernel to hand a large segment to the NIC, which then splits it into packets. It is essential for reducing per-packet cost, but it places hardware between the timing decision and the actual transmission.

If a large segment is released in one piece, the NIC can produce a burst despite the pacing intention. TSQ, qdisc, TSO, driver and hardware must therefore be designed as one system. A CPU gain can degrade latency if it is not coordinated with traffic shape.

Pacing quantum, timestamps and NIC behaviour must describe the same reality

The kernel works with quanta, timer resolution, timestamps, offload units and hardware queues. A quantum that is too large recreates bursts; one that is too small consumes CPU; a driver or NIC that interprets the units differently changes the result on the wire.

Operators therefore cannot treat the qdisc as decoration. It is part of the capacity model. Developers must test the complete path, and a benchmark that names only the congestion control or link throughput omits much of the mechanism.

TCP internal pacing reduced dependence on a particular qdisc

In 2017, Dumazet published work on TCP internal pacing. The transport gained a more direct ability to hold back transmission according to its rate state and timers, even when the qdisc was not exactly the one expected.

The qdisc did not become useless: it still orders packets and remains a place for policy. The change moved part of the logic to the subsystem that carries the intent. As often happens in the kernel, a capability born in one layer is later brought closer to its owner without removing all the earlier layers.

Qdisc choice remains an operator decision with real consequences

Linux offers several disciplines for different purposes.sch_fqis particularly well suited to pacing; FQ-CoDel pursues another combination of per-flow fairness and active queue management. The two are not identical.

Defaults vary across distributions and environments. Cloud images, appliances and container hosts do not necessarily use the same choices, and hardware offload can move execution. The kernel provides the capability; the operator decides whether it actually shapes the service.

A few bytes per socket become a constraint at fleet scale

Every connection carries sequence numbers, timers, congestion state, queues and accounting. At small scale, the size of the structure seems secondary. At hundreds of thousands of sockets, every byte multiplies and every frequently touched field becomes a cache load.

Reducing memory per socket potentially increases density; better field layout reduces cache misses and transfers between processors. This link to server economics remains analytical: the evidence shows that the costs exist, but not a universal financial amount or a personal value attributable to Dumazet.

A cache line becomes infrastructure when it is touched on every packet

The processor moves cache lines, not isolated fields. Hot data placed with cold fields needlessly moves the whole line; two CPUs modifying different values on the same line create coherence traffic as well.

Dumazet’s recent work adopts this physical reading of the code. Separating hot and cold fields aims to reduce the memory bandwidth consumed on each packet or socket operation. The gain varies by processor and workload. An optimisation derived from a production profile must remain correct and acceptable on other machines.

The 2024 structure work marks a mature phase of optimisation

The 2024 presentation on assisted structure reorganisation started from profiles rather than a new algorithm: which fields are hot, which lines move, which structures dominate memory? Tools can suggest a layout, but human review remains necessary for alignment, locking, compatibility and readability.

This is the face of mature infrastructure. After a mechanism is invented, major gains sometimes come from a cache miss avoided or a field moved. Less spectacular than a new protocol name, this work nevertheless determines real efficiency at scale.

Hyperscale profiles are powerful evidence and incomplete public science

Large operators see volumes, NICs and socket populations that are hard to reproduce. Their telemetry can reveal costs invisible in a microbenchmark. Dumazet’s Google affiliation gives access to that kind of reality.

But some workloads, tools and data remain private. A conference can expose the method without delivering every parameter. That does not make the observation false; it imposes qualification. The best outcome is for private findings to motivate public changes, and then for more realistic workloads to be encoded in open tests.

Locks and receive queues belong to the same resource story

The article’s central mechanisms concern transmission, but Dumazet’s work also covers sockets and reception. Incoming packets must be interrogated, allocated, classified, queued and delivered across CPUs. At high rate, locks and shared state become a cost as well.

Linux reduces these costs through work movement, batching and contention limiting. The common thread remains the same: spend enough coordination on correctness, not so much that accounting absorbs the application’s capacity. A complete inventory of contributions would be misleading; representative mechanisms show the coherence better.

Batching increases throughput while changing latency and fairness

Processing several packets or completions together amortises locks, calls and cache movement. Linux uses this principle in NAPI, drivers, offload and queues.

A batch, however, waits to be formed and can arrive at the next layer as a burst. The larger it is, the better the amortisation, but the longer the first element waits and the more one flow can occupy resources. TSQ, fair queueing and pacing do not fight batching; they give it limits so that it improves throughput without destroying feedback.

Linux TCP performance is born of layers that can cancel each other out

Congestion control gives an intention. TCP turns it into packets and timestamps. TSQ limits the local queue. The qdisc orders. TSO groups. The driver maps memory. The NIC transmits and the path adds its own queues.

Progress in one layer can disappear in another: precise pacing undone by large segmentation, a fast qdisc overwhelmed by too much enqueueing, a compact structure replaced by a new lock. Dumazet’s work crosses these joints. It improves the installed stack rather than proposing a brand-new architecture detached from the existing fleet.

Public review turns a local optimisation into shared infrastructure

An improvement begins as a performance claim. To enter Linux, it must survive the netdev list: measurement evidence, a generic interface, rare architectures, maintenance cost and tests.

A maintainer can ask to split a series, reject a proprietary abstraction or defer work that is too fragile. The process is slower than a private patch, but it forces a particular need to become a common capability. Dumazet’s authority lies especially in this capacity to judge not only what works today, but what Linux can sustain tomorrow.

netandnet-nextseparate urgent repair from future development

Fixes normally go tonet; new features go tonet-next. This separation prevents a critical repair from being mixed with a redesign intended for a future release.

The boundary requires judgement. A “fix” can change behaviour, a feature can reveal an old bug, and a series sometimes has to be split. The trees make authority visible and prevent a vendor’s commercial timetable from becoming, by itself, a reason for inclusion.

Review, rejection and redesign disappear from commit statistics

Line and commit counters seem objective, but they ignore the sentence that forces an author to redesign an interface, or the rejection that avoids years of maintenance. Applying a patch means accepting its integration; it does not make the maintainer the author of the idea.

The portrait must therefore combine named contributions and a governance role. TSQ,sch_fq, internal pacing and the cache work are identifiable. They do not summarise decades of TCP and socket review, just as not every merged patch becomes Dumazet’s personal creation.

Tests reduce risk without representing every Linux machine

Builds, selftests, KUnit, syzbot, driver laboratories and downstream deployments detect many regressions. They do not cover every architecture, NIC, protocol combination, qdisc and workload.

Maintainers still have to reason about compatibility, rollback and rare paths. A hyperscale optimisation can harm an embedded device. Tests strengthen public governance; they do not replace the technical memory and judgement that connect different environments.

Stable backports impose a second decision after mainline

A patch accepted in mainline does not automatically belong to every stable branch. Stable maintainers verify that it fixes a real problem, remains limited and does not introduce a new feature or an absent dependency.

Performance patches are delicate: moved without their context, they can create another regression. Impact therefore arrives in stages: upstream design, stable, distribution, cloud, operator tuning. No maintainer controls the whole chain, and no current mechanism is necessarily deployed everywhere in the same form.

Current TCP and socket maintainership is deliberately shared

TheMAINTAINERSfile distributes responsibility among Dumazet, Neal Cardwell and other maintainers and reviewers. This plurality reduces the risk that an absence blocks the work and brings different expertise on congestion, sockets, drivers and tests.

It also requires explicit coordination. Overlapping areas can become ambiguous if each person assumes another will respond. A healthy succession preserves the principles and tests without requiring every future decision to pass through the same person.

The Netdev Foundation can fund work without becoming the merge authority

Under the supervision of the Linux Foundation, the Netdev Foundation funds tests, tools, travel and research. Dumazet sits on its TSC. That role can direct resources, but funding does not guarantee the inclusion of a patch.

The separation is essential. Deep maintenance requires paid time, hardware and CI; denying that economy would be illusory. Upstream legitimacy, however, still comes from public technical evidence. Money should increase the capacity to decide, not buy an exception.

Google affiliation brings resources without giving ownership of Linux TCP

The Google address in the registries establishes an affiliation, not a complete title. Google can fund large-scale profiling, hardware and review time, which then benefits outside users when the changes are merged upstream.

The trade-off is data asymmetry. Hyperscale needs can attract attention, and some evidence remains private. Public review serves as a counterweight: the patch must remain generic, understandable and acceptable to independent maintainers. The employer brings time and observations, not ownership of the stack.

Downstream operators decide whether an upstream improvement actually changes the service

Distributions choose versions and backports; clouds choose qdisc and congestion control; appliance makers sometimes freeze old kernels; NICs impose their capabilities; applications create the load.

There is no complete public census ofsch_fqusage or TSQ settings. A mechanism can be present but inactive, or active by default without the user knowing. Dumazet’s impact is therefore broad and indirect: he changes the common set of options, while each operator turns it into service.

User-space stacks target specialised workloads, not every Linux use

DPDK, VPP and application stacks can bypass part of the kernel path to achieve high throughput and tight control. They often require dedicated cores, huge pages, device binding and separate operations.

Linux TCP offers broader integration: ordinary sockets, security, namespaces, observability, drivers and applications. TSQ, pacing and cache work reduce the cost of this general path without claiming it is optimal for every case. Specialised stacks can bypass it; Linux remains the common base for most applications.

Linux remains the default because integration is worth more than raw throughput

A network stack must be fast, but also compatible with APIs, security updates, routing, namespaces, observability and thousands of drivers. Performance achieved in a separate island can be useful, but has its own operational cost.

Linux’s advantage is that the application uses a standard socket and inherits decades of work on queues, pacing and memory. The developer does not need to know TSQ. This invisibility explains why the infrastructure is durable: the benefit remains even when the author’s name disappears from the user experience.

A faster host does not prove that the network path is better

A shorter local queue repairs neither a congested access link, nor an overloaded remote server, nor a router that loses packets. TSQ and pacing discipline the sender; they do not control the complete path.

A kernel improvement can reduce one source of delay and make the flow more cooperative. It does not guarantee the application result. The strongest formulation is conditional: Linux can become a better sender and a more efficient host, while end-to-end performance still depends on the application, the receiver, the network and operator settings.

One benchmark does not represent all servers, NICs and workloads

Packet size, connection count, CPU architecture, cache, NIC, offloads, qdisc, timers, kernel version and load change the result. A Google profile or a microbenchmark can reveal a real cost without predicting the exact gain elsewhere.

A good technical narrative preserves these conditions. A reduction in cache misses proves that layout matters, not a universal percentage. Dumazet’s talks provide attributed operational evidence; open tests and independent measurements are needed to generalise.

Succession is a technical problem because part of the design lives in human memory

Old limits sometimes exist because of a forgotten NIC, an API still in use, or a regression resolved long ago. The code does not always tell that story.

Long-serving maintainers carry this memory, which creates both value and a dependency risk. Documentation, tests, archives and co-maintainers convert private knowledge into an institution. A good succession does not deny Dumazet’s expertise; it lets others understand the reasons behind TSQ, pacing and socket accounting, and then adapt them to future hardware.

Hardware pacing and device memory can shift the boundary again

NICs are increasingly able to schedule, manage queues, expose telemetry and work with local memory. They can reduce CPU and improve timing while placing more behaviour in firmware.

The next problem will be coordination: Linux must convey intent, learn what the hardware actually did and recover when the models differ. Driver interfaces, timestamps and errors become as important as rate calculation. The principles from Dumazet’s work remain relevant: control close to intent, feedback, limits on hidden queues and observability.

Cache economics can deliver more gains than new transport formulas

New congestion controls will continue to appear, but on large hosts the next gain may come from a split structure, a removed lock, an adjusted batch or a cache line that no longer bounces between CPUs.

These changes carry less branding but benefit many algorithms and applications. The 2024 work shows a mature stack measuring itself by physical costs. The question moves from “which protocol wins?” to “how much machine does each connection consume without anyone noticing?”

Dumazet’s lasting contribution is resource discipline, not a heroic myth

A bad version of this story would make Dumazet the sole inventor of modern TCP and BBR. Another would dissolve every individual contribution into an anonymous community. The evidence supports a more precise position.

Dumazet introduced TSQ, authored foundational work onsch_fq, developed internal pacing and showed the importance of structure layout. He also holds current responsibility within a shared maintenance system. His contribution is to treat packets and sockets as requests on time, memory, queues and CPU locality.

The final impact is dispersed across review, integration, configuration and deployment. A patch is easy to date; a denser fleet or an avoided outage cannot be cleanly attached to an author. That difficulty authorises neither exaggeration nor erasure: it shows that infrastructure value is created in a collective chain in which some initial decisions remain identifiable.