In February, we made the case that RDMA for AI scale-out networks should be programmable, and we showed a software-defined RoCEv2 running at 800G on the Arm cores of the E1. Since then, the question we hear most often is a sharper one: programmable for what? The answer is that the rules for moving data are always changing, and operators want hardware that changes with it.
It comes down to fabric and transport. The fabric is the network inside the cluster: the switches, cables, and adapters that connect the GPUs and servers. The transport is the set of rules for moving data across it: addressing, acknowledgment, loss recovery, and how fast a sender may go when the network is busy. The wiring stays put. The rules keep changing.
Why the transport is still moving
RoCEv2 became the default transport for AI clusters because it was available and fast. It was designed for a smaller, calmer network than a GPU fabric, and that fabric keeps changing underneath it: the collective operations that move data between GPUs change from one model to the next, clusters are built with different topologies and latencies, and inference brings traffic of its own, with constant access to storage and the KV cache. So the large operators have been adjusting the transport ever since, with their own congestion control, retransmission rules, and multipath behavior. Some have written their own transport. Amazon built SRD for its Elastic Fabric Adapter (EFA). Google developed Falcon and contributed it to the Open Compute Project. Both began as storage and HPC transports. OpenAI's MRC, developed with AMD, Broadcom, Intel, Microsoft and NVIDIA, was built for large AI training fabrics: it extends RoCE to spread one connection across many paths, and it is an open specification through the Open Compute Project. The Ultra Ethernet Consortium published its first specification in 2025 as an open alternative to RoCE for AI and HPC traffic.
None of this is settled, and an operator may want to change transports well before the hardware is depreciated.
When fixed-function hardware falls behind
A conventional RDMA NIC implements its transport in dedicated logic, and what that logic can do was decided when the chip was designed, typically four or five years before deployment. When a protocol changes in a way the logic did not anticipate, the operator waits for a standards body, then a silicon generation, then a qualification cycle. Most DPUs inherit the same limitation because they evolved from NICs: a fixed pipeline handles packets, and a few Arm cores sit off to the side for the slow path.
What protocol agility means
Protocol agility is the ability to adopt, modify, or replace the transport a network runs, in software, on hardware that is already installed. In practice it shows up in tuning (changing congestion control, pacing, retransmission, and how traffic is spread across paths), extending (adding behavior a standard does not yet cover), and replacing (running a different transport altogether).
How the E1 does it
The E1 puts up to 64 Arm Neoverse N2 cores directly in the data plane, and every packet passes through them. With no separate fixed pipeline to work around, the transport is an application. A new transport, or a variant of the current one, is developed on the card and rolled out as a software update. The same holds for the rest of the data plane: network policy is applied the same way to conventional traffic and to the RDMA fabric, and encryption runs at line rate on hardware offloads.
The performance question
The objection to running a transport in software is speed. The February results answer it for the E1: sustained RDMA throughput of 800G using a portion of the available compute, with the remaining cores free for offloads, telemetry, and fabric services. The cores are the data plane, so there is no penalty for taking the programmable path.
What it changes for an operator
Buy the card once, then decide on transport later. Run one transport on the training fabric and another on the storage network from the same device. When a standard such as Ultra Ethernet matures, the question for an operator becomes a software one, on the hardware already in the racks. Debug transport behavior with the same tools and engineers as the rest of the software stack.
Frequently asked questions
E1 product details are at xsightlabs.com/dpu/e1.