Presto: Running TCP on Programmable Switches at Terabit Speed

Presto: Running TCP on Programmable Switches at Terabit Speed

Presto: Running TCP on Programmable Switches at Terabit Speed

Data-center networks have become the critical infrastructure connecting GPUs, CPUs, storage devices, and distributed services. As AI training, inference, and distributed storage workloads push network bandwidth into the terabit-per-second range, the traditional host-based TCP/IP stack is becoming an increasingly expensive part of the system.

The problem is often described as the network CPU tax: a significant portion of host CPU capacity is consumed simply processing packets rather than executing application logic.

TCP processing requires substantially more than moving bytes. A high-speed implementation must handle:

• Packet parsing
• Checksums
• Sequence-number validation
• Receive-window management
• Out-of-order reassembly
• ACK generation
• Retransmission
• Fast retransmit
• Congestion control
• Connection state management

Even kernel-bypass stacks can consume substantial CPU resources at high packet rates.

This creates a fundamental architectural trade-off.

ASICs provide throughput, latency, and energy efficiency, but traditionally sacrifice programmability. Software stacks provide flexibility and compatibility, but consume CPU resources.

The SIGCOMM ‘26 Best Paper, Presto: A Match-Action TCP Stack for the Terabit Era, proposes a different approach: move the TCP protocol stack into the data plane of a programmable switch.

Presto demonstrates that stateful TCP processing can be mapped onto a deterministic Reconfigurable Match-Action (RMT) pipeline while retaining standard TCP semantics and POSIX socket compatibility.

The result is an architecture that attempts to combine:

• ASIC-class line-rate processing
• Programmable transport logic
• Standard TCP semantics
• POSIX socket compatibility
• Significantly lower host CPU consumption

⚖️ Why TCP Becomes a CPU Tax at Terabit Speeds

#

Host Software TCP

#

The conventional approach runs TCP entirely on the server CPU.

Linux and kernel-bypass stacks such as TAS provide excellent software flexibility and compatibility.

Their advantages include:

• Standard TCP behavior
• POSIX socket interfaces
• Flexible congestion control
• Straightforward feature development
• Compatibility with existing applications

The problem is scalability.

As network bandwidth increases, packet-processing work also increases. More packets mean more CPU cycles spent parsing headers, maintaining connection state, managing buffers, processing ACKs, and handling retransmissions.

At sufficiently high speeds, network processing can consume many CPU cores that would otherwise execute application workloads.

High packet-processing overhead can also contribute to:

• Increased latency
• Tail-latency spikes
• CPU contention
• Poor energy efficiency

Kernel bypass reduces some operating-system overhead, but it does not eliminate the fundamental cost of executing TCP logic on general-purpose processors.

Fixed-Function Hardware Offload

#

The opposite approach is to move TCP processing into dedicated hardware.

TCP Offload Engines (TOEs) and RDMA can provide:

• High throughput
• Low latency
• Low CPU utilization
• Excellent energy efficiency

However, fixed-function implementations are difficult to evolve.

New congestion-control algorithms, transport features, and protocol extensions can require hardware redesign.

RDMA also changes the programming model. Applications cannot simply use standard TCP sockets without significant architectural changes.

This makes RDMA highly effective for specific HPC and storage workloads but less attractive as a universal replacement for TCP.

SmartNIC, NPU, and FPGA Offload

#

Programmable SmartNICs, NPUs, and FPGAs provide a middle ground.

They can execute custom logic and be updated after deployment.

However, many existing implementations face challenges involving:

• Large circuit complexity
• Tight timing constraints
• Significant hardware resource consumption
• Difficult state management
• Throughput ceilings
• Partial rather than complete offload

Some designs still depend on the host CPU for portions of the protocol stack, limiting the benefits of hardware acceleration.

Presto takes a different approach by using the switch’s existing programmable packet-processing pipeline.

🧩 RMT Is Powerful—but TCP Is Fundamentally Stateful

#

Reconfigurable Match-Action (RMT) architectures are widely used in programmable switches and next-generation networking devices.

An RMT pipeline consists of multiple stages. Each stage generally performs some combination of:

1. Match packet fields.
2. Execute actions.
3. Read or update state.
4. Forward the packet to the next stage.

Packets progress through the pipeline in a deterministic direction.

This architecture is extremely effective for workloads such as:

• Routing
• ACLs
• Packet classification
• Load balancing
• Telemetry
• Header manipulation

TCP is much more difficult.

A TCP connection maintains tightly coupled state including:

• Sequence numbers
• Receive windows
• Send windows
• ACK state
• Out-of-order packet information
• Retransmission state
• Congestion-control information

A conventional CPU can read and modify the same connection state multiple times while processing one packet.

An RMT pipeline cannot freely perform those operations.

Packets cannot arbitrarily move backward through earlier stages, and pipeline memory cannot be treated like unrestricted software memory.

Three Fundamental Dependency Problems

#

Mapping TCP onto an RMT pipeline creates three major hazards.

Forward read dependency

An early stage may need a value that is not computed or validated until a later stage.

Loop write dependency

A later stage may determine that it must modify state maintained by an earlier stage.

Pipeline stalls

The pipeline could theoretically stop processing until these dependencies are resolved, but doing so destroys the throughput advantage of a line-rate architecture.

Presto’s core contribution is a set of techniques that eliminate or transform these dependencies without turning the switch pipeline into a serialized processor.

🚀 Presto’s Three Core Design Principles

#

Presto implements TCP entirely within an RMT pipeline.

The architecture decomposes TCP operations—including packet reassembly, retransmission, flow control, and congestion-control enforcement—into match-action operations that can execute at line rate.

Three design principles make this possible.

1. In-Line Processing Avoids Pipeline Stalls

#

The normal TCP datapath processes each packet through the pipeline only once.

Presto avoids:

• Packet recirculation
• In-pipeline packet caching
• Multi-pass processing on the normal path

Recirculation is expensive because it consumes additional pipeline bandwidth and increases latency.

Caching is also problematic because switch SRAM is limited and valuable.

Instead, Presto separates processing responsibilities between the Ingress and Egress pipelines.

The Ingress pipeline performs primarily read-only parsing and classification.

Mutable TCP connection state updates are placed in the Egress pipeline.

This arrangement also provides an elegant fault model.

If the Traffic Manager (TM) drops a packet, the event can be treated like ordinary network packet loss. TCP’s existing retransmission mechanisms then provide the recovery mechanism.

The switch does not need to build a completely separate reliability mechanism for every internal failure mode.

2. Optimistic Concurrency Resolves Forward Reads

#

A forward dependency occurs when an early pipeline stage needs to make a decision using information that becomes available only later.

Presto uses optimistic execution.

Instead of waiting for downstream validation, the early stage performs a speculative state update.

Later stages validate the assumption.

The design relies on the observation that the overwhelming majority of packets follow the normal path.

Conceptually:

Early pipeline
      │
      ▼
Speculative state update
      │
      ▼
Downstream validation
      │
 ┌────┴────┐
 │         │
Valid    Invalid
 │         │
 ▼         ▼
Keep     Recover
state    / rollback

The common case therefore remains fully pipelined.

Only exceptional packets trigger recovery.

3. Pseudo-Segment Injection Resolves Loop Writes

#

Loop write dependencies are more difficult.

Consider an out-of-order packet that fills a previously missing sequence range.

The rear of the pipeline can determine that a gap has been closed, but the state that must be updated—such as next-seq and avail—may be maintained in earlier stages.

The pipeline cannot simply write backward.

Presto solves this using pseudo-segment injection.

Instead of directly modifying earlier state, the datapath generates a payloadless pseudo-segment representing the newly contiguous sequence range.

That pseudo-segment is then injected into the normal processing path.

Because it travels forward through the same pipeline, existing TCP logic can perform the required state transition.

The pseudo-segment therefore turns a backward dependency into another forward pipeline operation.

🏗️ Presto Architecture

#

Presto consists of three major components:

1. Control Plane
2. Application Interface
3. RMT Data Plane

Control Plane

#

The control plane runs on the host or the switch’s onboard CPU.

It manages:

• Connection lifecycle
• Congestion-control policy
• Higher-level control logic
• Recovery operations

The RMT datapath collects the necessary metrics and enforces the resulting rate parameters.

This division is important.

Not every piece of TCP logic belongs in hardware. Presto keeps relatively complex policy calculations in software while moving high-frequency packet processing into the deterministic datapath.

Application Interface

#

Presto provides two primary application interfaces.

libPresto exposes standard POSIX socket APIs.

This preserves application compatibility but requires user data to be copied through Presto’s transmit and receive buffers.

libPresto-ZC provides a zero-copy interface.

Data-intensive applications can access Presto-managed buffers directly, eliminating unnecessary data copies.

This separation allows applications to choose compatibility or maximum data-path efficiency.

RMT Data Plane

#

The data plane consists of decoupled functional blocks that share the same pipeline hardware.

Three major workflows operate within the datapath:

• RX: network-to-host receive processing
• TX: host-to-network transmission
• SYNC: connection-state synchronization and credit updates

The design reuses the same hardware resources across these workflows rather than requiring a separate pipeline for every TCP function.

📦 Packet Reassembly Is the Hardest Part

#

TCP packet reassembly creates some of the most difficult state-management problems because packets can arrive out of order.

A conventional software stack can maintain dynamic data structures for arbitrary out-of-order segments.

An RMT pipeline cannot.

Presto therefore introduces an OOO-n model, where n represents the number of out-of-order intervals the hardware can track.

Increasing n provides greater reassembly capability but consumes additional hardware resources.

This creates an explicit performance-versus-resource trade-off rather than attempting to reproduce an unrestricted software data structure inside the switch.

🔄 Receiver-Side Reassembly

#

OOO-0 Uses Optimistic Concurrency

#

The basic receiver maintains two important state variables:

• next-seq: the next sequence number expected in order
• avail: remaining receive-window space

A conventional implementation can validate the receive window before advancing next-seq.

In the RMT pipeline, however, the two variables may reside in different stages.

That creates a forward read dependency.

Presto resolves it optimistically.

1. Early stages speculatively advance next-seq.
2. Downstream stages validate the receive-window condition using avail.
3. Valid packets retain the speculative update.
4. Invalid packets trigger recovery.

If a sender violates the receive window, the offending packet is dropped and the control plane is notified to roll back the connection state.

During recovery, a negative avail value can force subsequent packets to be dropped while the receiver advertises a zero window.

The key idea is that the normal case never waits for downstream validation.

OOO-1 Uses Pseudo-Segments

#

OOO-1 adds:

• ooo-head
• ooo-tail

to represent a single out-of-order interval.

These values are maintained as offsets relative to next-seq.

This relative representation has an important advantage: when next-seq advances, the out-of-order interval shifts automatically without requiring every stored sequence number to be rewritten.

The difficult case occurs when an incoming in-order segment fills the gap.

The rear of the pipeline detects the gap closure, but the front of the pipeline owns the state that must advance.

Presto therefore:

1. Detects the closed gap downstream.
2. Generates a payloadless pseudo-segment.
3. Encodes the newly contiguous sequence range.
4. Injects the pseudo-segment into the RX pipeline.
5. Reuses OOO-0 processing to advance next-seq.
6. Updates avail.
7. Clears the completed out-of-order interval.

Pseudo-Segments Provide Eventual Recovery

#

Pseudo-segments also inherit the system’s packet-loss model.

If a pseudo-segment is dropped because of congestion, the underlying out-of-order state remains intact.

The next relevant real packet can trigger pseudo-segment generation again.

This provides a form of eventual consistency for the state transition without requiring reliable internal delivery of the pseudo-segment itself.

Overlapping sequence ranges can also be trimmed automatically, preventing duplicate byte accounting.

OOO-n Extends the Model

#

The same concept can be extended to multiple out-of-order intervals.

Presto uses cascaded interval merging and batch pseudo-segment replay to close multiple gaps.

The implementation maintains key invariants around interval ordering and gap representation while avoiding general-purpose sorting or dynamic memory structures.

The result is a hardware-friendly approximation of TCP reassembly semantics whose resource requirements can be explicitly controlled.

💾 Receiver-Side Supporting Mechanisms

#

Data Placement

#

Out-of-order packets are written directly into host memory through DMA.

Presto uses dual virtual mappings for receive buffers to handle buffer wraparound.

This allows DMA operations to avoid unnecessary fragmentation when a circular receive buffer crosses its physical boundary.

ACK Generation

#

ACKs are generated by the datapath rather than by the host CPU.

Presto uses mirrored pseudo-segments to generate acknowledgment packets.

If an ACK pseudo-segment is lost, the result is equivalent to losing an ACK in the network, allowing TCP’s existing reliability mechanisms to handle the condition.

Outbound data packets can also piggyback acknowledgments when appropriate.

Application Notification

#

DMA transfers include notifications describing which contiguous byte ranges are ready for application consumption.

When an out-of-order gap closes, the notification can be generated immediately rather than waiting for the pseudo-segment processing to finish.

This reduces application-visible latency.

📤 Transmit and Retransmission Logic

#

Push-Based Transmission

#

Presto uses a push model for transmission.

The datapath periodically sends transmit credits to libPresto through SYNC messages.

Once the host receives credits, it actively DMAs payloads into the datapath for transmission.

This avoids the additional round-trip latency that can occur when the datapath must repeatedly pull data from the host.

Congestion Control Is Split Between Hardware and Software

#

Presto divides congestion control into two layers.

The datapath handles high-frequency metrics such as:

• ECN information
• Duplicate ACK detection
• Packet-level timing
• Rate enforcement

The control plane handles the more programmable policy logic.

Algorithms such as DCTCP and TIMELY can therefore remain in software while the datapath enforces the resulting transmission rate.

This division avoids consuming valuable pipeline resources on complex control algorithms while preserving flexibility.

SYNC Scheduling

#

The datapath periodically generates SYNC messages to deliver transmit credits and connection-management information.

Idle connections can automatically reduce or pause SYNC activity to limit overhead.

SYNC messages can also communicate timeout-based retransmission signals back to libPresto.

ACK Processing and Fast Retransmit

#

Incoming ACKs update the sender’s window state.

Three duplicate ACKs trigger fast retransmission.

The datapath notifies libPresto through DMA and synchronously adjusts transmit credits to reduce the sending rate.

The result is a hardware-assisted implementation of traditional TCP recovery behavior.

📊 Experimental Evaluation

#

Presto’s prototype was implemented on an Intel Tofino 2 programmable switch and evaluated against the Linux TCP stack, TAS, and RDMA.

The results demonstrate that programmable-switch TCP can approach the performance characteristics traditionally associated with specialized transport hardware.

RPC Performance Approaches RDMA

#

In load-latency tests, Presto achieved approximately 40 million operations per second (Mops) on a 32-core server.

Reported latency included:

• Median: approximately 18 μs
• 99.99th percentile: approximately 24 μs

Presto’s performance was reported to be virtually tied with RDMA.

TAS reached approximately 60% of Presto’s peak throughput, while Linux was approximately an order of magnitude behind in the tested configuration.

Presto also demonstrated approximately linear scaling across cores and connections, with aggregate pipeline processing capacity approaching 1 billion packets per second.

Energy Efficiency Frees CPU Cores

#

FlexKVS experiments showed that Presto achieved approximately 2x the throughput-to-power ratio of TAS’s optimal configuration.

Its 99.99th-percentile tail latency was approximately 5x lower than TAS’s best case in the reported tests.

Most importantly, TCP processing was completely removed from the host CPU datapath.

The evaluation reported that Presto could free up to 16 CPU cores for application processing.

The RMT pipeline’s dynamic power increased only slightly and approximately linearly with throughput, at around 25 Mpps/W.

This is one of the most important results of the architecture.

The goal is not merely to increase network throughput.

It is to increase the amount of useful application work per server watt by eliminating repetitive protocol processing from general-purpose CPUs.

🌊 Streaming and Storage Reach Terabit-Class Throughput

#

In single-core streaming tests, Presto reached approximately 25 Mpps of packet-processing capability.

With an 8 KB MTU, that corresponds to roughly 1.6 Tbps of network bandwidth.

The critical point is that the host CPU is not the factor limiting this throughput.

The switch pipeline performs the packet-processing work at line rate.

In NVMe-over-TCP storage experiments, Presto delivered storage IOPS and latency close to RDMA.

By comparison, the Linux TCP stack achieved only approximately one-quarter of Presto’s throughput in the reported tests.

This suggests that programmable TCP offload could make TCP-based storage significantly more competitive with specialized transports.

🛡️ Robustness Under Packet Loss and Congestion

#

Presto also demonstrated resilience under adverse network conditions.

With a random packet-loss rate of approximately 0.1%, Presto maintained near-lossless throughput in the reported evaluation.

TAS throughput dropped by approximately half under the same testing conditions.

In incast scenarios, where many senders transmit toward a common receiver simultaneously, Presto showed greater stability than the evaluated software stacks.

The architecture benefits from fast datapath-based ACK processing and retransmission signaling, reducing the latency between detecting congestion-related events and reacting to them.

🧪 Programmability Is Presto’s Most Important Feature

#

Performance alone would not distinguish Presto from a fixed-function TOE or RDMA implementation.

The more important result is that the switch-based TCP stack remains programmable.

The paper demonstrates several extensions.

Delayed ACK and SACK

#

Features such as delayed acknowledgments and Selective ACK (SACK) can be added through relatively small P4 modifications with negligible additional power consumption in the reported evaluation.

This demonstrates that the transport implementation is not permanently frozen into hardware.

TIMELY-Style Congestion Control

#

Presto can also leverage Tofino 2 hardware timestamps and filtering mechanisms to calculate RTT-related metrics.

For example, RTT samples can be processed into an exponential weighted moving average (EWMA) in the datapath.

The control plane can then use those measurements for congestion-control decisions.

This creates a useful division:

Packet arrival
      │
      ▼
Hardware timestamp
      │
      ▼
RTT measurement
      │
      ▼
EWMA / metric processing
      │
      ▼
Control-plane policy
      │
      ▼
Rate parameters
      │
      ▼
Datapath enforcement

The hardware therefore accelerates the high-frequency measurement path while software retains control over algorithmic policy.

Application and Network Co-Design

#

Presto also demonstrates that the programmable datapath can perform functions beyond traditional TCP.

One example is global ordering for shared logs.

Records originating from multiple connections can be ordered in the network before being written into a shared log.

This allows the datapath to perform ordering work that would otherwise require CPU intervention.

In a reported 32-client scenario, a single CPU core could saturate line rate using in-network ordering, while software-based solutions required approximately five cores.

This illustrates a broader possibility: programmable network hardware can become an execution layer for application-specific distributed-system primitives, not merely a faster packet forwarder.

🔬 What Presto Changes Architecturally

#

Presto challenges a long-standing assumption in networking:

Stateful protocols belong on CPUs, while switches should perform simple stateless forwarding.

The architecture shows that the boundary is not necessarily fixed.

The key is not to reproduce a software TCP implementation instruction-for-instruction.

Instead, TCP must be reformulated around the constraints of the hardware pipeline.

Presto achieves this by:

• Converting backward dependencies into forward processing
• Using speculative execution for common-case decisions
• Representing state with pipeline-friendly structures
• Using pseudo-segments as internal state-transition events
• Separating control policy from packet-level enforcement
• Treating internal packet drops as ordinary network loss where possible
• Reusing existing TCP reliability mechanisms instead of duplicating them

This is an important hardware-software co-design lesson.

A protocol does not necessarily need a general-purpose processor to be programmable.

It needs an execution model that can express the protocol’s required state transitions efficiently.

⚠️ The Remaining Trade-Offs

#

Presto does not eliminate every limitation of programmable-switch architectures.

RMT pipelines have finite:

• Pipeline stages
• SRAM
• Register resources
• Metadata width
• Arithmetic capabilities
• Packet-processing bandwidth

Complex TCP features therefore need to be carefully mapped onto hardware resources.

The OOO-n design makes this trade-off explicit: supporting more simultaneous out-of-order intervals consumes more resources.

Likewise, keeping congestion-control algorithms in the control plane preserves programmability but means that not every decision is made entirely in hardware.

The approach is therefore best understood as hardware-software co-designed TCP, rather than a conventional TCP implementation simply moved into a switch.

🔮 Presto Points Toward a New Network Architecture

#

Presto demonstrates that the traditional distinction between software TCP and fixed-function hardware offload is not the only available design space.

A programmable switch can potentially provide:

• Line-rate packet processing
• Hardware-level energy efficiency
• Standard TCP compatibility
• POSIX socket interfaces
• Programmable congestion control
• Flexible protocol extensions
• Application-specific network processing

The reported results are significant: approximately 40 Mops RPC throughput, 1.6 Tbps single-core streaming capability, up to 16 CPU cores freed, and performance approaching RDMA in several workloads.

More importantly, Presto shows how those results can be achieved without abandoning TCP’s software ecosystem.

The deeper contribution is architectural.

Instead of asking how to make a CPU execute TCP faster, Presto asks whether the network itself can execute TCP.

That shift moves transport processing from the host’s critical path into the programmable data plane, turning the switch from a passive forwarding device into an active execution engine for network protocols.

As AI clusters, distributed storage systems, and high-performance data centers continue moving toward 800G, 1.6T, and eventually higher-speed networking, eliminating the CPU tax of packet processing will become increasingly important.

Presto suggests one possible direction:

Keep TCP’s compatibility and semantics, but move its hot path to programmable hardware.

That combination could become a powerful foundation for the next generation of high-speed, CPU-efficient data-center networking.