In the data centre, TCP has quietly become one of the most expensive things a Central Processing Unit (CPU) does. Network hardware has continued to scale impressively while keeping power consumption reasonable. A single NVIDIA ConnectX-7 Network Interface Controller (NIC) handles 400Gbps and 300Mpps at roughly 25W.
Software network stacks have not kept pace, and they are now the dominant bottleneck, failing to translate those hardware gains into application performance. Even with the best kernel-bypass stacks, communication-intensive applications burn as much as 74% of their CPU cycles in the transport, rather than in application logic. As link speeds climb to terabits, the ‘CPU tax’ compounds into tens of cores, hundreds of watts of power, stranded bandwidth, and inflated tail latency.
Operators have long lived with an uncomfortable choice. Software Transport Control Protocol (TCP) is flexible, interoperable, and robust, but executes on CPUs. Hardware-implemented transports such as Remote Direct Memory Access (RDMA) and TCP offload engines are fast and efficient, but rigid and notoriously brittle to operate at cloud scale.
RDMA is a case in point. Having been designed for tightly controlled, lossless fabrics at far smaller scale, its retrofit to large-scale data centre networks has proven error-prone and slow, gated by hardware iteration cycles. A transport fixed in silicon denies operators the ability to debug, trace, manage, and adapt the stack quickly to meet emerging application or deployment needs. Hardware transports, therefore, stay confined to specialized silos such as storage and high-performance computing clusters, while software stacks remain the default everywhere else.
Presto breaks this tension. We built Presto on the Reconfigurable Match-action Table (RMT) architecture — the design underlying programmable switches such as Intel Tofino, and a growing number of SmartNICs like AMD’s Pensando. RMT sustains deterministic line-rate packet processing at billions of packets per second, with sub-microsecond latency and Application-Specific Integrated Circuit (ASIC) class power efficiency, while remaining fully software programmable in Programming Protocol-Independent Packet Processors (P4).
However, TCP’s complex state machine is ill-suited to RMT’s strictly unidirectional execution model. This post explains how Presto’s principles tailor a complete TCP stack expressed entirely as match-action operations, unlocking ASIC performance and efficiency, while retaining software flexibility.
Challenges for TCP on RMT
To see this mismatch concretely, recall how the RMT architecture processes a packet. It parses the packet into a header vector, then pushes that vector through a fixed sequence of match-action stages, each performing simple Arithmetic Logic Unit (ALU) operations against stage-local memory, all in lock-step.
Every packet takes the same path, in the same number of cycles, and each stage carries only a fixed, small budget of match-action logic. That rigidity is the source of RMT’s determinism and efficiency, but is also the source of the programming difficulty.
TCP, by contrast, requires complex, interdependent state updates. For example, window boundaries, sequence numbers, and out-of-order bookkeeping may need to be updated many times, in any order. An RMT pipeline permits none of this (Figure 1a): State is stage-local, the packet only ever moves forward, and cannot revisit earlier stages. Direct implementations of TCP on RMT thus fall into one of these three traps:
- If an early stage needs a value that only becomes available later, we encounter a forward read dependency, which the pipeline simply cannot satisfy (Figure 1b).
- Defer the update until that value is known, and the write must flow backward to an earlier stage — a circular write dependency, resolvable only by looping the packet back through the pipeline (Figure 1c). This is doubly costly: The loop-back doubles common-path latency, consumes bandwidth, and can transiently expose stale state, and every stage must now tell original packets from recirculated ones — extra match-action cases the stage budget can rarely afford.
- Serialize the updates to avoid both, and you have pipeline stalls, squandering the parallelism that made the pipeline fast (Figure 1d).
Reconciling TCP state with RMT constraints
Presto addresses each of the RMT constraints with a corresponding design technique.
- Bump-in-the-wire processing is our design philosophy to avoid pipeline stalls. Each segment makes at most one pass through the pipeline, with no recirculation on the common path and no buffering of segments in the pipeline. This preserves both bandwidth and low latency under tight memory constraints.
- Optimistic concurrency with deferred validation addresses forward read dependencies. Presto executes the common case state updates speculatively, updating state in an early stage and validating the assumption several stages downstream. Uncommon cases fall back to corrective actions by a slower control path.
- Pseudo-segment injection resolves circular write dependencies. Some TCP state dependencies are inherently backward: state held in an earlier stage must be revised based on a later value. A forward-only pipeline cannot express this directly. Instead, the later stage emits a small synthetic segment — a pseudo-segment — that is fed back to the head of the pipeline. It carries no application payload, but every stage it passes treats it as an ordinary segment, so the existing match-action logic performs exactly the updates required. Presto can express backward state updates while preserving pipeline invariants without introducing special cases or stalls. Because only this rare synthetic segment loops back, the real segment is never delayed: The common path pays none of the latency or bandwidth cost of recirculation.
The mechanics of these design principles, as applied to TCP state, are detailed in our paper.
A modular data-path, and why that matters
Unlike fixed-function offloads, Presto’s data-path is programmable end-to-end. To make this tractable, the RMT data path executes the core transport logic — window management, reassembly, acknowledgment generation, sequence-to-address translation for Direct Memory Access (DMA), and rate control — not as a monolith, but as a sequence of decoupled, independently programmable functional blocks, each spanning several match-action stages. This modularity allows operators to evolve transport semantics, change congestion-control mechanisms, or integrate application co-designs by editing a few lines of P4 rather than redesigning the pipeline.
Presto redefines the software TCP design space
We built a full prototype on an Intel Tofino 2 switch (a Netberg Aurora 810), and compared it to Linux, the TCP Acceleration Service (TAS) kernel-bypass stack, and RDMA. The trade-off we described at the outset — performance, efficiency, flexibility — is what Presto is meant to dissolve. Taking each attribute in turn:
- Performance: One core is no longer the ceiling. A single TCP connection on a single CPU core can now stream at 25Mpps, enough to exceed 1.6Tbps at 8K Maximum Transmission Unit (MTU).
- Efficiency: The CPU tax goes to zero. The RMT pipeline sustains 1.2Bpps of TCP processing at 2.81W. On the host side, Presto exceeds TAS’s peak throughput with 16 fewer CPU cores and doubles a key-value store’s throughput-per-watt at five times lower tail latency.
- Flexibility: Transport evolution is a software change. Extensions spanning transport logic, congestion control, and application co-design each landed as a localized edit to one or two blocks, costing tens to low hundreds of lines of P4 and a fraction of a watt.
- Robustness: The simplified hardware stack is not brittle. Presto holds full throughput to a 0.1% drop rate and delivers roughly two times TAS’s throughput, while keeping latency-sensitive and bandwidth-intensive flows from interfering with one another.
- Compatibility: Nothing above the socket changes. Popular applications like memcached, nginx, and FlexKVS run unmodified over Presto, and a Storage Performance Development Kit (SPDK) NVMe-over-TCP target reaches RDMA-level performance — more than four times Linux’s throughput — all while interoperating with Linux and TAS TCP endpoints.
- Generalizability: This is not a Tofino trick. Ported to a Field Programmable Gate Array (FPGA) SmartNIC, Presto’s fine-grained pipelining eases the timing pressure that monolithic designs face, sustaining three times the packet rate of prior work while using 2.5% of the FPGA’s logic.
Conclusion
Presto allows operators to retain the transport they already deploy and understand — standard TCP with a POSIX sockets interface, requiring no application modification. Presto attains ASIC-class efficiency in CPU use and power, and terabit-scale performance with microsecond tail latency. Because the data path is programmable in P4, transport logic evolves on a software release cycle rather than a vendor’s silicon cycle.
More broadly, Presto redefines the design space of high-performance TCP stacks by showing that full transport functionality fits within RMT constraints. While rooted in TCP, these principles are not specific to it. Any reliable transport shares the same structure — track in-flight data, recover from loss, regulate the send rate — and mapping stateful protocols onto programmable hardware under tight timing and resource budgets is common to every programmable data plane. By addressing these challenges, we hope this work informs the debate on programmability versus efficiency, influencing the design and evolution of hardware-efficient transport protocols for data centres.
Presto is open source, built for the Intel Tofino 2 (validated on the Netberg Aurora 810 with ConnectX NICs). If you have that hardware, you can do more than reproduce the results in this post. The repository ships a full experiment framework — Remote Procedure Call (RPC) scalability, packet-loss, incast, performance-isolation, key-value store, shared-log, and NVMe-oF benchmarks. Each is a single command with analysis and plotting built in — so you can deploy Presto in your own cluster and put your own workloads through it.
Unmodified applications run over its POSIX sockets layer, so you can use your existing applications — memcached, nginx, SPDK — on top of Presto without recompiling them. Because it speaks standard TCP, you can run it beside your existing stack and compare directly. We would welcome your results and feedback.
Presto is a joint work between the University of Washington and the Max Planck Institute for Software Systems (MPI-SWS), by Rajath Shashidhara, Antoine Kaufmann, and Simon Peter. More information about Presto can be found in our paper, at the ACM SIGCOMM 2026 conference, or on our Github.
Rajath Shashidhara is a Senior Systems Research Engineer in the Systems Research Group (SRG) at Google, where he currently focuses on the end-to-end design and deployment of tiered memory and networked systems for data centres.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.