Eric Dumazet and the small queues that support the Linux server economy

Summary

• Eric Dumazet currently appears as a Linux maintainer for core networking, TCP and sockets, and sits on the technical committee of the Netdev Foundation. These roles are shared with other maintainers and reviewers: they carry major integration responsibility, not individual control over the network stack.
• His clearest named contribution is TCP Small Queues, introduced in 2012 to stop a single TCP flow from depositing an excessive amount of data in queues below the transport layer. By linking the socket's local credit to packet completions, TSQ reduced latency and memory pressure at the sender without removing all queues along the path.
• His later work onsch_fqand internal pacing turned send timing into an explicit control. Fair queueing separates flows and pacing distributes packets over time. These pieces support several congestion algorithms, including environments running BBR, but BBR has its own authorship and history.
• His most recent work connects structure layout, cache-line traffic and per-socket state with the efficiency of large fleets. The conclusion is that Linux networking is also accounting for CPU, memory, queue depth and time. The economic effect can be material, although public evidence does not allow assigning a monetary figure or promising the same result on every system.

A fast server can still lose time behind its own packets

The story starts inside a transmit queue. The application has written data, TCP believes it can send more, and the kernel has handed it to lower layers. From above they appear sent, but they may still be waiting on the same machine.

The link stays busy and the problem is hidden. An interactive request waits behind a bulk transfer, buffers hold memory, and the notion of “data in flight” stops matching what is simply accumulated locally. TCP Small Queues changed that relationship by limiting how much a socket could place below TCP and by returning send permission when the hardware completed real work.

The public record explains the engineering and avoids inventing a biography

The best evidence comes from the kernel itself:MAINTAINERS, patch discussions, documentation, conferences and public review. Those records support his continuing work on networking, TCP and sockets, his seat on the Netdev Foundation and a visible affiliation with Google through his maintainer email.

They do not provide a complete biography, a verified current corporate title, a total patch count or the exact allocation of his time. Filling those gaps with plausible details would be less than rigorous. The profile therefore focuses on observable mechanisms and decisions. Dumazet appears as an engineer with technical responsibility whose work only becomes infrastructure after others review, modify, test and deploy it.

Being a maintainer places him close to decisions, not above the community

As of 4 August 2026, the Linux records listed him under core networking, TCP and sockets. A maintainer can request an interface redesign, reject an unjustified maintenance burden, apply accepted changes and represent the subsystem to mainline.

The same source shows shared authority. David S. Miller, Jakub Kicinski and Paolo Abeni appear under core networking; Neal Cardwell shares TCP, and other reviewers step in depending on the topic. Patches also pass through architecture, drivers, security, testing, stable branches and the kernel's final process. Dumazet's influence is notable because it works within that network of checks.

Linux became economic infrastructure as connections grew

On a small machine, a few extra bytes per socket or a cache miss are barely noticeable. On a server with hundreds of thousands of connections, the cost multiplies until it competes with the application, memory and energy.

“Server economics” does not mean there is a public savings figure. It describes fleet consequences: how many connections fit, how much CPU remains for the service, how much memory networking consumes and how often a local queue breaks a latency target. Distributions and operators choose versions, qdisc, congestion control and NICs. Dumazet does not control those decisions; he changes the common starting point.

TCP's familiar work conceals a highly complex accounting system

TCP provides a reliable stream, but it must decide how many bytes may remain outstanding, when to retransmit, how to charge memory, how to order packets and how to share CPU and queues among thousands of sockets.

An implementation can be correct and still perform poorly: too much local backlog, bursts, shared locks or structures that waste cache. The common thread in Dumazet's work is accounting. Bytes are charged to the socket, completions return credit, send times are calculated and hot fields are separated from cold ones. The goal is to use the resources necessary without building a second hidden network inside the host.

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

Before TSQ, TCP could hand a great deal of traffic to the qdisc and the driver. The congestion window might be reasonable, and yet a long local queue could hold packets below the transport layer. The application could no longer pull them back when an urgent flow appeared.

That accumulation weakened feedback: TCP saw acknowledgements from the path, but part of the data had not even left the host. It also consumed memory, especially when many flows repeated the pattern. What was needed was to maintain throughput without allowing each socket to use the lower layers as unlimited storage.

The 2012 TSQ series gave the socket back a local queue budget

The 2012 patches limited, per socket, the amount of data queued below TCP. When the local credit ran out, the socket stopped; when packets completed, it regained the ability to send.

The idea was simple: count local bytes and treat completion as proof of progress. Control returned to the transport that understood the flow. It was no longer necessary to deposit a large batch in advance to keep the link busy. The importance of TSQ lies precisely in the fact that applications unaware of the mechanism received more disciplined behaviour without modifying their code.

Packet completion became a useful signal inside the host

Completion might look like simple cleanup. TSQ turned it into information: part of the lower path made progress, and the socket may emit more.

This local feedback complements remote acknowledgements. One describes progress across the network; the other, progress below TCP. Statistics from the qdisc, the driver and the NIC track other parts. No single signal is enough by itself. TSQ used one of them to control local excess without replacing end-to-end congestion control.

TSQ reduced one source of bufferbloat, not all queues along the path

TSQ did not eliminate bufferbloat. It acts on the sender's backlog below TCP. Queues still exist in the qdisc, the driver, the NIC, the access link, routers, switches and the receiver.

The useful claim is more precise: TSQ reduces a socket's ability to create an excessively large hidden queue. It can lower latency and memory usage and bring TCP state closer to device progress. It does not replace active queue management, sensible configuration or end-to-end congestion control.

Thresholds, offloads and workloads determine how much TSQ helps

The outcome depends on the limit, packet size, qdisc, hardware queues, TSO and flow mix. An interactive service and bulk replication do not respond equally.

The implementation also changed after 2012. Other developers adjusted limits and fixed interactions. The authorship of the concept can be attributed to Dumazet without presenting the current mechanism as a frozen piece belonging exclusively to him.

sch_fqseparated flows and brought time into the scheduler

In 2013, Dumazet published thesch_fqscheduler. It maintains per-flow state and a time-ordered structure to release packets according to their target time. New flows can receive service soon, while paced flows wait their turn.

It solves two problems: it stops a large transfer from monopolising the local queue and provides a place where the kernel can respect send times. It does not guarantee equality between applications; it offers a more disciplined policy and practical support for pacing.

Fair queueing is a policy, not a promise of equal outcomes

“Fair” can sound more absolute than it is. Separating flows in a queue does not equalise application performance. Packet size, route, receiver, congestion control, offloads and the number of connections still matter.

Even the identity of a flow is a decision: one application can open many connections and another one.sch_fqlimits local domination, but it does not resolve fairness between users or companies. For the operator it is an arbitration tool, not a universal guarantee.

Pacing turns a rate estimate into a sequence of send instants

An algorithm can decide on the correct rate and still release it in a burst. The average is preserved, but the queue suffers a spike.

Pacing distributes packets over time. It can stabilise queues, improve coexistence and better express the congestion model. The implementation requires coherent timestamps, timers, qdisc, segmentation and NIC behaviour. The software rate only matters if it becomes real times on the wire.

Pacing and congestion control solve different parts

Congestion control decides how much of the path to use; pacing decides when the permitted data leaves. A good model can be ruined by bursts, and perfect pacing can execute the wrong rate.

Dumazet's infrastructure allows several algorithms to express a rate over time. The authorship of each model belongs to its designers, even if it depends on that infrastructure.

BBR uses pacing, but it has its own authorship and evolution

BBR is often associated with Dumazet because of its dependence on pacing and the Google environment. That does not make him its sole inventor. BBR has its own authors, model and versions.

Dumazet's contribution is foundational: queues, pacing, instrumentation and sockets make later algorithms deployable. That description recognises his importance and preserves the credit of Neal Cardwell and other congestion authors.

TSO saves CPU and can rebuild the burst that pacing tried to avoid

TCP Segmentation Offload allows handing a large segment to the NIC to be split later. It greatly reduces the per-packet cost, but it places the hardware between the timing decision and the emission.

If the segment leaves as a unit, the NIC can produce a burst. TSQ, qdisc, TSO, driver and hardware must be treated as one system. A CPU saving can worsen latency if it is not coordinated with the traffic shape.

Quantum, timestamps and NIC behaviour must describe the same reality

The kernel works with quanta, timer resolution, timestamps, offload units and physical queues. A large quantum creates bursts; a small one costs CPU; a NIC that interprets a different granularity alters the output.

That is why qdisc is part of capacity planning. Developers must measure the complete path, and benchmarks that only name congestion control or link speed omit most of the system.

TCP's internal pacing reduced dependence on a specific qdisc

In 2017, Dumazet published internal pacing in TCP. The transport gained more ability to hold traffic according to its rate and timers, without depending entirely on a specific discipline.

The qdisc remained relevant for ordering and policy. The logic moved closer to the subsystem that owns the intent, but the final output continued to be split between TCP, scheduler, driver and NIC. It is layered evolution, not a clean replacement.

The queueing discipline remains an operational decision with real consequences

Linux offers qdiscs for different goals.sch_fqfavours pacing; FQ-CoDel combines flow separation with active queue management. They are not the same.

The defaults vary by distribution and environment. Cloud images, appliances and container hosts can choose differently, and the hardware can shift the execution. Upstream offers mechanisms; the operator decides whether they become real service behaviour.

A few bytes per socket become a fleet-wide constraint

Every connection maintains sequences, timers, congestion state, queues and counters. At scale, every byte multiplies and every frequently accessed field occupies cache.

Reducing per-socket memory can increase density; improving layout can reduce misses and inter-CPU coherence traffic. This is the strongest bridge to server economics, but it does not allow calculating a universal saving or a personal valuation of the work.

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

The processor moves whole lines, not individual fields. Hot data next to cold fields circulates useless bytes; two CPUs modifying the same line generate coherence traffic even if they touch different values.

Dumazet's recent work adopts this physical view. Separating hot and cold fields reduces memory traffic that grows with packets and sockets. The benefit depends on processor and workload, so the profile of one fleet cannot simply be turned into a universal law.

The 2024 work on structures shows a mature phase of performance engineering

The 2024 presentation began with profiles: which fields are hot, which lines move and which structures dominate memory. Tools can suggest reorganisations, but they do not replace review of alignment, locking, compatibility and maintainability.

In mature infrastructure, large gains can come from avoiding a miss or moving a field, not from a new algorithm. It is less visible than a congestion brand, but it determines real performance.

Hyperscale profiles are powerful evidence and incomplete public science

Large operators see populations and hardware that are difficult to reproduce. They can discover costs that do not appear in the lab. Dumazet's affiliation with Google places him in that environment.

Some workloads and data remain private. A talk can show method and result without providing all the inputs. The solution is not to discard the evidence, but to limit its scope and turn more real-world cases into public tests and CI.

Locks and receive queues belong to the same resource story

Although the profile's focus is on transmission, Dumazet's track record includes sockets and receive. Incoming packets need polling, memory, classification, queues and delivery across CPUs. At high rates, locks and shared state become a cost.

Linux reduces that cost by moving work, grouping operations and reducing contention. The principle is the same: use the coordination necessary for correctness without allowing the accounting to consume the service.

Batching raises throughput and changes latency and fair sharing

Grouping packets or completions amortises locks, calls and cache. NAPI, drivers and offloads depend on it.

The batch, however, waits and can arrive as a burst. Large batches improve amortisation and increase waiting or domination. TSQ, fair queueing and pacing do not reject batching; they bound it to preserve feedback and latency.

TCP performance emerges from layers that can cancel each other out

The algorithm defines intent; TCP creates packets; TSQ limits backlog; the qdisc orders; TSO groups; the driver maps; the NIC emits; the network adds queues and losses.

Precise pacing can be cancelled out by coarse segmentation; a low-latency qdisc, by excessive enqueue; a compact layout, by a new lock. Dumazet's importance lies in working on those seams and improving the installed path rather than separating from it.

Public review turns a local optimisation into shared infrastructure

An improvement starts as a claim: less latency, memory or CPU. To enter Linux it must survive netdev: methodology, generic interface, unusual architectures, testing and future cost.

A maintainer can split the series, reject a vendor abstraction or defer a change. It is slower than a private patch and more durable. Dumazet's authority includes judging not only whether something works today, but whether Linux will be able to sustain it for years.

netandnet-nextseparate urgent repair from future development

Fixes normally go tonet; features, tonet-next. The separation avoids mixing urgent maintenance with refactors for a future version.

The classification requires judgement. A fix can change behaviour and a feature can reveal an old defect. Maintainers split series so that the risk is explicit and to prevent a commercial date from replacing technical readiness.

Review, rejection and redesign do not appear in the commit counter

Commits measure visible authorship, but not the sentence that forces an interface redesign nor the rejection that avoids a years-long burden. Applying a patch means assuming integration, not inventing its idea.

The profile combines attributed mechanisms with stewardship. TSQ,sch_fq, pacing and layouts are clear, but they do not exhaust decades of review or turn every integrated change into personal works.

Testing reduces risk without representing every machine Linux will encounter

Builds, selftests, KUnit, syzbot, driver labs and downstream deployments find faults, but they do not cover every CPU, NIC, qdisc and workload.

A change useful for hyperscale can harm a rare device. Maintainers still need experience, compatibility and rollback. Tests strengthen governance; they do not remove judgement.

Stable backports require another decision after mainline

A mainline patch does not automatically enter every branch. Stable requires a real, bounded and low-risk fix. Distributions then make another decision.

Performance changes can depend on surrounding code that is absent from an old branch. The impact arrives in stages: upstream, stable, distribution, cloud and configuration. No one controls the entire chain.

Current responsibility for TCP and sockets is deliberately shared

MAINTAINERSdistributes the load among Dumazet, Neal Cardwell and other maintainers and reviewers. This reduces dependence on one person and combines knowledge of congestion, sockets, drivers and testing.

Plurality requires clear ownership. Overlaps can leave gaps if everyone waits for someone else. Healthy succession distributes authority and preserves the reasons behind decisions, not just the names in a file.

The Netdev Foundation can fund without becoming a merge authority

The foundation, under the Linux Foundation, supports CI, tooling, travel and research. Dumazet sits on its TSC. A grant does not guarantee that a patch will be accepted.

The distinction is healthy: maintaining networking costs money and time, but upstream legitimacy still comes from public evidence. Funding should increase the capacity to decide, not buy exceptions.

Google affiliation brings capacity without ownership of Linux TCP

The Google email proves affiliation, not a complete title. A hyperscaler can fund profiling, hardware and review that then benefit all of Linux.

The asymmetry is that its workloads and data are not fully public. Open review compensates: the patch must be generic and acceptable outside Google. The company contributes time and evidence; it does not own the stack.

Downstream operators decide whether the improvement changes their service

Distributions choose kernels; clouds, qdisc and congestion; appliances, versions; NIC vendors, capabilities; applications, traffic. There is no complete census of TSQ orsch_fqusage.

A mechanism can be compiled but not active, or active by default without user visibility. Dumazet's impact is broad but indirect: he changes the common options; each operator turns them into experience.

Userspace stacks compete for specialised workloads, not for all Linux functions

DPDK, VPP and proprietary stacks can avoid parts of the kernel to achieve high rates, at the cost of dedicated cores, huge pages and a different operational model.

Linux integrates sockets, security, namespaces, observability and drivers. Dumazet's work reduces the cost of the general path without claiming it is perfect for everything. Bypass remains for specific uses; Linux remains the base for most.

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

A stack must be fast, compatible, secure, observable and maintainable. An isolated path can deliver more packets per second and create operating and support costs.

A Linux application inherits TSQ, pacing and accounting through ordinary sockets. That invisibility is part of the strength: the benefit continues even when the user does not know the author's name.

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

Improving the local queue does not fix congested access, a slow receiver or routers that drop packets. TSQ and pacing govern the sender, not the whole path.

They can reduce one source of delay and make the flow more regular. They do not guarantee application outcomes. End-to-end performance still depends on application, receiver, path and configuration.

A benchmark does not represent every server, NIC and workload

Packet size, connections, CPU, cache, NIC, offloads, qdisc, timers, kernel and workload change the result. A Google profile can uncover a real cost without predicting the percentage in another fleet.

Good information preserves conditions. Dumazet's talks are attributed operational evidence; public tests and independent measurements are needed to generalise.

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

Strange limits can exist because of an old NIC, an API still in use or a forgotten regression. The code does not always explain why.

Veteran maintainers carry that context. Documentation, tests, archives and new reviewers turn private memory into institutional knowledge. Succession must preserve principles and allow them to be revisited for future hardware.

Hardware pacing and device memory can move the boundary again

Modern NICs schedule packets, manage more queues and expose telemetry or local memory. They reduce CPU and shift behaviour to firmware.

Linux must express intent, observe what happened and recover when hardware and software differ. Driver APIs, timestamps and errors will be as important as the rate. The principles remain: feedback, limits on hidden queues and observability.

Cache economics may offer more gains than new transport formulas

Congestion algorithms will keep appearing, but the next material improvement may be a better layout, lock or batch. It has no attractive brand and benefits multiple algorithms.

The 2024 work shows a mature stack evaluated by physical costs. The question shifts from “which protocol wins” to “how much machine each connection consumes”.

Dumazet's lasting contribution is resource discipline, not a heroic legend

An exaggerated version would make him the inventor of modern TCP and BBR; another would erase the individual within the community. The evidence allows a precise position.

He introduced TSQ, authored foundational work onsch_fq, drove internal pacing and showed the relevance of layout. He also maintains critical areas within a shared system. His contribution is to treat packets and sockets as demands on time, memory, queueing and CPU locality.

The final impact is dispersed across design, review, integration and operation. A commit can be attributed; a denser fleet or an avoided outage cannot. That difficulty does not justify either exaggeration or erasure: it shows that infrastructure value arises from a collective chain with identifiable individual decisions.