Title: Presto: A Match-Action TCP Stack for the Terabit Era
Authors: Rajath Shashidhara (University of Washington); Antoine Kaufmann (MPI-SWS); Simon Peter (University of Washington)
Introduction
As datacenter links get faster, transport processing consumes an increasingly large share of host CPU time. Kernel-bypass TCP stacks reduce operating-system overhead, but they still execute much of the connection logic on CPU cores. RDMA and fixed-function TCP offload engines are much more efficient, yet they give up some of the flexibility and compatibility that make TCP attractive. Presto asks whether a programmable Reconfigurable Match-Action Table (RMT) pipeline can provide hardware-class TCP performance while preserving normal TCP semantics and POSIX socket compatibility.
The difficulty is that TCP and RMT were built around very different execution models. TCP reassembly, retransmission, flow control, congestion control, and bidirectional coordination all create dependent state updates. An RMT pipeline is unidirectional, stage-local, and lock-step. A direct implementation therefore runs into forward-read dependencies, circular writes, recirculation, or serialization, any of which can remove the throughput advantage of the pipeline.
Key idea and contribution:
Presto expresses TCP processing as a sequence of small match-action operations and introduces three mechanisms to handle the dependencies. Optimistic concurrency lets an early stage act on a speculative value and validates the update later. Pseudo-segment injection turns circular state dependencies into lightweight control events that pass through the same pipeline instead of stalling the original packet. Bump-in-the-wire processing keeps the common data path to a single pass and places data directly for the application.
With these mechanisms, Presto offloads core TCP transport logic for established connections, including retransmission, bounded out-of-order reassembly, flow control, congestion control, and application notification, while retaining TCP/POSIX compatibility. Connection lifecycle management and uncommon processing remain in a CPU control plane. The main Tofino 2 prototype validates the hardware data path, while the OOO-1 SACK variant is evaluated only in simulation because of compiler limitations; the authors also port the stateful egress pipeline to an FPGA SmartNIC. The broader contribution is therefore a way to map dependency-heavy stateful transport processing onto a match-action pipeline, not just a faster TCP datapath for one device.
Evaluation
The main testbed has eight 32-core Intel Xeon Gold 6430 machines with 200G Mellanox ConnectX-6 NICs configured in 100G mode, connected to a 32 x 400G Intel Tofino 2 switch. In the RPC benchmark, Presto sustains nearly 40 million operations per second, 1.67 times TAS, with about 18 microseconds median latency and 24 microseconds at the 99.99th percentile. It sustains 32K connections without a throughput drop. At pipeline scale, the system approaches 1 billion packets per second while keeping RPC tail latency around 20 microseconds. For single-core streaming, Presto reaches about 25 Mpps independent of segment size, matching RDMA. At an 8 KB MTU, that packet rate corresponds to more than 1.6 Tbps of processing capacity; it is a rate-times-packet-size extrapolation rather than a measured end-to-end 1.6 Tbps transfer. TAS is limited to roughly 5 Mpps per core.
The application results are consistent with the microbenchmarks. On FlexKVS, even the worst Presto configuration beats TAS’s best throughput-per-watt by about 1.2 times while giving roughly 5 times lower 99.99th-percentile latency; the best Presto configuration doubles TAS’s throughput-per-watt. In SPDK NVMe-over-TCP, Presto tracks NVMe-over-RDMA closely and clearly outperforms Linux in the tested high-I/O-depth regime. It also maintains full streaming throughput at a 0.1% random packet-drop rate, where TAS falls to roughly half its throughput. The FPGA port on an AMD Alveo U250 reaches 300 Mpps at 10 ns timing for 32K connections, using about 2.5% LUT and 0.78% BRAM, around 3 times Tonic’s packet rate under the same timing constraint.
Q&A
Q1: Have you considered building an FPGA or ASIC pipeline that better matches TCP requirements instead of working around the match-action pipeline?
The authors explained that they also prototyped Presto on an FPGA using a match-action pipeline compiler. Enhancing an RMT pipeline with larger stages or stronger atomic-update support is possible, but it would trade off energy efficiency. Their point is that useful TCP functionality can already be achieved with the basic RMT model while retaining a reasonable balance between flexibility and efficiency.
Q2: How does Presto handle correctness under speculative execution, and what happens if the pipeline restarts during a switch upgrade?
For speculative execution, the authors emphasized the data-center setting, microsecond-scale latency, and relatively small bandwidth-delay product. The design includes checks for correctness within its supported window and assumes no adversarial actor is trying to compromise the transport stack. Pipeline restart and recovery of ongoing connections after a switch upgrade are outside the scope of the work.
Personal thoughts
I think the paper works because it focuses on the dependency problem rather than treating RMT as a faster place to run ordinary TCP code. Optimistic validation and pseudo-segments are simple enough to understand, but they directly address the constraints that make stateful protocols awkward on a feed-forward pipeline. The evaluation also helps: RPCs, streaming, key-value storage, NVMe, loss recovery, and an FPGA port all test different parts of the claim.
The scope is still mainly the datacenter. The design benefits from short RTTs, relatively controlled paths, and hardware with a fixed set of match-action stages. More complex WAN behavior or protocols that need larger and more irregular per-flow state may fit less naturally. The Tofino 2 prototype also has platform-specific constraints, including recirculation for same-switch Presto-to-Presto connections and a compiler issue that prevented the SACK variant from receiving the same hardware evaluation. I would like to see the same ideas tested on a SmartNIC or switch generation where the full bidirectional path can be implemented without those restrictions.