Within data centre operations, TCP has emerged as one of the costliest workloads that CPUs must handle. Network interface hardware continues advancing at impressive rates while maintaining reasonable power budgets — an NVIDIA ConnectX-7 NIC processes 400Gbps and 300Mpps using only about 25W. By contrast, software-based network stacks have failed to keep pace with this hardware evolution, becoming the primary constraint preventing applications from realizing the full benefits of modern network capabilities.

The performance gap has grown severe. Even the most optimized kernel-bypass stacks force communication-heavy applications to dedicate as much as 74% of CPU cycles to transport processing rather than application work. As link speeds approach terabit rates, this overhead translates into dozens of wasted cores, hundreds of watts of excess power consumption, unutilized bandwidth capacity, and elevated tail latencies.

Operators have faced a difficult tradeoff. Software TCP implementations offer flexibility, broad compatibility, and reliability but consume significant CPU resources. Hardware-based transports like Remote Direct Memory Access (RDMA) and TCP offload engines deliver speed and power efficiency but sacrifice adaptability and prove fragile when deployed at cloud scale. RDMA exemplifies this problem — designed originally for small, lossless networks with tight controls, retrofitting it to large-scale data centre fabrics has proven error-prone and slow, constrained by hardware development cycles. Once transport logic is fixed in silicon, operators lose the ability to debug, trace, manage, or rapidly adjust the stack to meet new application requirements or deployment scenarios. Hardware transports consequently remain confined to specialized domains such as storage systems and high-performance computing clusters, while software stacks remain the default everywhere else.

Presto addresses this tension by implementing TCP on the Reconfigurable Match-action Table (RMT) architecture that powers programmable switches such as Intel Tofino and growing numbers of SmartNICs including AMD's Pensando. RMT achieves deterministic line-rate packet processing at billions of packets per second, with sub-microsecond latency and ASIC-class power efficiency, all while remaining fully programmable in Programming Protocol-Independent Packet Processors (P4). TCP's intricate state machine, however, conflicts with RMT's strictly unidirectional execution model. Presto's design principles reshape TCP into a complete stack expressed entirely as match-action operations, unlocking ASIC performance and efficiency while preserving software programmability.

Challenges for TCP on RMT

The RMT architecture processes each packet by parsing it into a header vector, then passing that vector through a fixed sequence of match-action stages. Each stage performs simple Arithmetic Logic Unit (ALU) operations against its own local memory, all synchronized in lockstep. Every packet follows the same path in the same number of cycles, and each stage has only a fixed, small budget of match-action logic. This rigidity creates RMT's determinism and efficiency but also its programming difficulty.

TCP, by contrast, demands complex, interdependent state updates. Window boundaries, sequence numbers, and out-of-order bookkeeping may require updates multiple times in any order. An RMT pipeline permits none of this: state remains local to each stage, packets move only forward, and cannot return to earlier stages. Direct TCP implementations on RMT encounter three fundamental problems:

  1. If an early stage requires a value that only becomes available downstream, a forward read dependency emerges that the pipeline cannot satisfy.
  2. Deferring the update until the value is known requires a write to flow backward to an earlier stage — a circular write dependency resolvable only by looping the packet back through the pipeline. This approach doubles latency on the common path, consumes bandwidth, exposes stale state transiently, and forces every stage to distinguish original packets from recirculated ones, consuming precious match-action budget.
  3. Serializing updates to avoid both problems introduces pipeline stalls that waste the parallelism making the pipeline fast in the first place.

Reconciling TCP state with RMT constraints

Presto addresses each RMT constraint with a corresponding design technique.

  • Bump-in-the-wire processing avoids pipeline stalls by ensuring each segment makes at most one pass through the pipeline, with no recirculation on the common path and no buffering of segments within the pipeline. This preserves both bandwidth and low latency under tight memory constraints.
  • Optimistic concurrency with deferred validation handles forward read dependencies. Presto executes 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 through 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 — fed back to the pipeline head. It carries no application payload, but every stage treats it as an ordinary segment, so existing match-action logic performs exactly the required updates. Because only this rare synthetic segment loops back, the real segment never delays: the common path incurs none of the latency or bandwidth cost of recirculation.

A modular data-path, and why that matters

Unlike fixed-function offloads, Presto's data-path is programmable end-to-end. To make this practical, the RMT data path executes core transport logic — window management, reassembly, acknowledgment generation, sequence-to-address translation for Direct Memory Access (DMA), and rate control — not as a single monolithic unit, but as a sequence of decoupled, independently programmable functional blocks, each spanning several match-action stages. This modularity lets operators evolve transport semantics, change congestion-control mechanisms, or integrate application co-designs by editing a few lines of P4 rather than redesigning the entire pipeline.

Presto redefines the software TCP design space

The researchers built a full prototype on an Intel Tofino 2 switch (a Netberg Aurora 810) and compared it against Linux, the TCP Acceleration Service (TAS) kernel-bypass stack, and RDMA. The original tradeoff — performance, efficiency, flexibility — is what Presto dissolves:

  • Performance: A single TCP connection on a single CPU core can now stream at 25Mpps, sufficient to exceed 1.6Tbps at 8K Maximum Transmission Unit (MTU).
  • Efficiency: The CPU tax reaches zero. The RMT pipeline sustains 1.2 billion packets per second 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 becomes 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 maintains 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 specific to Tofino. 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 enables operators to keep the transport they already deploy and understand — standard TCP with a POSIX sockets interface, requiring no application modification. It achieves 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 demonstrating that full transport functionality fits within RMT constraints. While rooted in TCP, these principles apply to any reliable transport sharing the same structure — tracking in-flight data, recovering from loss, regulating 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, the 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). 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. Unmodified applications run over its POSIX sockets layer, so existing applications — memcached, nginx, SPDK — work on top of Presto without recompiling. Because it speaks standard TCP, it can run beside existing stacks for direct comparison.

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. 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.