HPE Slingshot Interconnect

• HPE Slingshot is a high-speed RDMA-capable interconnect designed for HPC, featuring high-radix switches and a Dragonfly topology for efficient and predictable performance.
• It leverages advanced hardware such as the Rosetta ASIC with 64 ports at 200 Gb/s to deliver low latency and high bandwidth across large-scale computing systems.
• The design integrates optimized Ethernet protocols with adaptive routing and hardware-based congestion control, enabling network-level isolation and seamless HPC-cloud convergence.

Searching arXiv for the cited HPE Slingshot papers to ground the article in current literature. HPE Slingshot is a high-speed, RDMA-capable network interconnect developed for HPC systems. In the literature, it is described as an interconnection network for large scale computing systems that combines high-radix switching, an optimized Ethernet protocol, adaptive routing, congestion control, and hardware-enforced traffic classes, while also supporting network-level isolation and cloud-adjacent deployment models (Sensi et al., 2020). Recent work places Slingshot at the center of converged HPC-Cloud architectures, large heterogeneous infrastructures such as Alps, GPU-stream-driven communication pipelines, topology-aware exascale diagnostics, and hardware-conscious one-sided communication libraries (Friese et al., 13 Aug 2025, Martinasso et al., 3 Jul 2025, Namashivayam et al., 2022, Grbic, 5 May 2026, Schonbein et al., 3 Jun 2026).

1. Core architecture and network design

Slingshot is based on high-radix switches. The Rosetta ASIC is described as providing 64 ports each at 200 Gb/s full-duplex, with each port using four 56 Gb/s SerDes lanes with PAM-4 encoding, and the ASIC is built on TSMC’s 16nm process with up to 250 W power consumption (Sensi et al., 2020). The switch internals are organized around 32 tile blocks in a 4x8 grid and a virtual output-queued architecture with physically separated crossbars for requests, grants, data, queue credits, and ACKs, with the stated goal of minimizing head-of-line blocking (Sensi et al., 2020). The switch achieves a median/mean port-to-port latency of 350 ns, with a 300–400 ns distribution (Sensi et al., 2020).

The default topology is a Dragonfly network. In this description, switches are clustered into groups, are fully connected within a group, and each Rosetta switch connects 16 endpoints while using remaining ports for intra-group and inter-group connectivity (Sensi et al., 2020). The topology is described as supporting at most three switch-to-switch hops between endpoints and up to ~260,000 nodes with full global bandwidth (Sensi et al., 2020). For 8 B messages, the furthest pairs have only 40% higher latency than the closest, while for messages of at least 16 KiB the difference is less than 10%, and bandwidth variations stay within 15% (Sensi et al., 2020).

These properties place Slingshot in the class of low-diameter, high-bandwidth interconnects intended for exascale and hyperscale settings. A plausible implication is that the architecture is designed not only for raw bandwidth density but also for predictable behavior across placement choices, an issue that becomes acute in systems with mixed HPC, AI, and data-intensive workloads.

2. Protocol model, interoperability, and in-fabric control

Slingshot uses an optimized Ethernet protocol and is described as fully compatible with standard Ethernet, supporting mixed operation in which optimized protocol handling is used for internal traffic and standards-compliant behavior for external connectivity (Sensi et al., 2020). The protocol optimizations reported include reducing minimum frame size to 32 B, optional header suppression for IP, and elimination of the inter-packet gap (Sensi et al., 2020). Reliability-related features include low-latency FEC, Link-Level Reliability, lane degradation, and NIC-based end-to-end retry (Sensi et al., 2020).

Adaptive routing is a central feature. For each packet, the switch evaluates congestion or load on up to four minimal and non-minimal paths and prefers less congested paths, while routing is biased toward minimal paths as a packet traverses the network (Sensi et al., 2020). Congestion information is exchanged within a switch via an intra-chip ring and between switches alongside ACKs (Sensi et al., 2020). Congestion control is hardware-based and tracks all in-flight packets per endpoint pair, distinguishing flows causing congestion from those affected and applying backpressure only to responsible sources (Sensi et al., 2020).

Slingshot also supports traffic classes selected via DSCP tags in packet headers. These classes can be assigned priorities, ordering, bandwidth minimums and maximums, and routing bias; administrators can assign minimum shares, and unused buffer is distributed as needed (Sensi et al., 2020). The same paper states that job schedulers can allocate classes per job and that libraries such as MPI can steer specific operations, such as collectives versus bulk transfers, to appropriate classes (Sensi et al., 2020).

In later systems work, these in-fabric controls are coupled to isolation mechanisms. Alps describes Slingshot as a programmable fabric supporting both high-bandwidth, low-latency transport and network-level isolation through VLANs and PKEYs, enforced at the switch level (Martinasso et al., 3 Jul 2025). This suggests that Slingshot’s control plane is used not only