Back to the Future: Why Omni-Path Matters in the Ultra Ethernet Era
Key takeaways
Put advanced fabric capabilities to work now with CN5000. Evaluate CN5000 against representative workloads to make an informed near-term investment decision.
Lower the risk of moving to Ultra Ethernet. CN6000 is designed to support Omni-Path, RoCEv2, and Ultra Ethernet capabilities together on one SuperNIC, CN6000 provides a practical bridge between today’s infrastructure and emerging Ethernet-based fabrics.
Build on a strong foundation for the Ultra Ethernet era. Cornelis brings decades of purpose-built fabric and libfabric experience to the congestion, reliability, multipathing, and scaling challenges Ultra Ethernet is designed to address.
Why the initial architecture matters
AI and HPC teams must meet workload demands today while planning for future network standards. Their network choices can affect application performance, deployment risk, and how much existing software and infrastructure they can carry forward.
Consider self-driving cars. Some begin as conventional vehicles, then gain cameras, driver assistance, and increasingly sophisticated software over time. Others are designed for autonomous operation from the start, with sensing, decision making and control built into the platform. Both approaches can move toward autonomy, but they begin with different architectures and different bodies of experience.
High-performance networking faces a similar choice.
Ethernet was created for broad, general-purpose networking. Over time, the industry extended it with RDMA through RoCEv2, congestion mechanisms such as PFC and ECN, improved telemetry, and other capabilities for increasingly demanding workloads. These advances are meaningful, but Ultra Ethernet is not simply an incremental feature layered on top of conventional Ethernet. It introduces a new transport architecture and defines additional fabric capabilities, including optional link-level mechanisms that require support within the network, not only at the endpoints.
Cornelis approaches Ultra Ethernet from a different starting point. Omni-Path was designed from the outset for tightly coupled computing with routing, flow-control, congestion-management, and reliability mechanisms coordinated across the fabric. That gives Cornelis relevant architectural experience with many of the problems Ultra Ethernet is now addressing.
Purpose-built does not have to mean a closed ecosystem. The Cornelis roadmap brings Omni-Path experience into open standards, widely adopted software interfaces, and interoperable Ethernet environments, giving customers greater choice across compute, software, switches, and infrastructure without locking the future of the cluster to a single vendor stack.
Ultra Ethernet is a new paradigm. But the challenges it targets, and our experience solving them, are not new. The destination may be shared, but the starting architecture still matters.
Ultra Ethernet is solving familiar problems
AI clusters bring thousands of processors and accelerators into tightly coordinated communication. Traffic patterns change rapidly. Many endpoints may target the same destination at once. Congestion can create hotspots, and small delays can leave expensive compute resources waiting for data.
The HPC industry has decades of experience confronting these challenges. A 2025 UEC-sponsored white paper observes that organizations with histories developing and deploying advanced HPC interconnect technologies bring foundational expertise to Ultra Ethernet.
The current Ultra Ethernet 1.0.3 specification makes this alignment more apparent. It defines adaptive packet spraying and receiver-credit congestion control for incast at the transport layer, along with optional credit-based flow control and link-layer retry at the Ethernet link layer. These are Ultra Ethernet Transport (UET) features, not Omni-Path implementations. But Cornelis has deep experience addressing the same underlying challenges.
This distinction matters in deployment. A purpose-built Ultra Ethernet fabric can apply link-layer features across the network. A UET-capable endpoint on conventional switches can gain transport benefits, but it cannot use link-layer features on switches that lack them. Customers should evaluate the complete fabric, not just endpoint support.
Why deploy Omni-Path today
Every infrastructure decision should begin with workload requirements, existing investments, deployment timing, and operational priorities. So, the question is this: if Ultra Ethernet is the destination, why deploy Omni-Path today?
For some environments, waiting may make sense. But waiting also has a cost.
Organizations running communication-intensive HPC and AI workloads today need predictable performance, high message rates, congestion management, and efficient use of expensive CPUs and GPUs now, not after a new ecosystem matures. Cornelis CN5000 delivers those capabilities today through a 400 Gb/s Omni-Path fabric. It addresses the congestion, scaling, and communication challenges customers face now, while providing a credible path toward the Ultra Ethernet era.
Plan a staged journey to Ultra Ethernet
That is where our next generation CN6000 becomes important. CN6000 is an 800 Gb/s multi-protocol SuperNIC, designed to support Omni-Path, RoCEv2, and Ultra Ethernet capabilities on a common platform. It preserves compatibility with existing CN5000 infrastructure while also connecting to standards-based Ethernet switch ecosystems.
Software continuity matters
Libfabric was developed through the OpenFabrics Interfaces Working Group, with Intel in a principal role. Cornelis builds on that lineage as an active contributor to libfabric and the developer of the optimized OPX provider for Omni-Path. The Ultra Ethernet 1.0.3 specification defines libfabric v2.0 as the baseline API for UE-compliant endpoints and specifies how those APIs map to Ultra Ethernet Transport. Applications therefore communicate through a standardized abstraction rather than coding directly to a particular network transport or hardware implementation.
This abstraction creates a path forward. Software built on libfabric can keep much of its communication model as the network evolves from Omni-Path to Ultra Ethernet. Instead of rewriting applications for a different API, developers may be able to move to a UET-capable provider and protect their existing application and middleware investment. Compatible software versions, providers, validation, and tuning may still be needed. Cornelis helped build this ecosystem, optimized it for high-performance computing, and continues to advance it as a member of the Ultra Ethernet Consortium.
Planning considerations for AI and HPC infrastructure
When planning the next generation of AI or HPC infrastructure, ask a broader question than, “Which network is fastest today?”
What do your workloads need now?
Which congestion and scaling behaviors will matter as the cluster grows?
How much of your software and operational environment can be carried forward?
Does your fabric vendor offer a credible path toward emerging open standards?
Can you adopt capabilities today that help prepare your organization for what comes next?
Ultra Ethernet represents an important direction for AI and HPC infrastructure. Preparing for that future does not necessarily mean waiting for it. For organizations addressing demanding AI and HPC workloads today, the road to Ultra Ethernet can start with putting advanced Omni-Path fabric capabilities to work now.
How to get started
Explore the Cornelis CN5000 Omni-Path portfolio and learn how we validate CN5000 with a broad set of OEM partners to reduce deployment risk. See CN5000 deployed at scale in major production environments, including the Lynx supercomputer at Lawrence Livermore National Laboratory and the Stampede3 upgrade at the Texas Advanced Computing Center.
Explore the CN6000 multi-protocol platform to see how we are extending that foundation into an 800G future spanning Omni-Path, RoCEv2, and Ultra Ethernet.
Connect with the Cornelis team at sales@cornelis.com