Skip to content

Chapter 20: Ultra Ethernet Consortium (UEC) · Part 8 of 10

Act 7 -- What UEC Requires From the Switch

A common question at architecture reviews: "Can I run UEC on my existing switches?"

The honest answer is: partially. UEC is explicitly designed to run over standard Ethernet switches without any protocol changes. A switch that can forward IPv4/UDP packets and mark ECN bits can forward UEC traffic. The lossless queuing configuration (headroom buffers, PFC) is simply not configured -- no new switch features required.

However, three optional switch capabilities in the UEC spec significantly improve performance:

ECN marking with per-flow granularity: Standard ECN marks per-queue when any flow in the queue is congested. UEC benefits from per-flow ECN marking (similar to per-flow RED) where the marking probability is a function of that specific flow's queue depth contribution. Broadcom Tomahawk 5 and Mellanox Spectrum-4 both support per-flow ECN marking in their latest firmware releases.

Network Performance Monitor (NPM) export: The UEC spec defines an NPM feedback channel where each switch port periodically exports per-path utilisation metrics to connected endpoints. This requires switch-side support for the NPM protocol (a UDP multicast to a well-known group). Not all switches implement this. As of March 2026, NPM support is in early firmware availability on Spectrum-4 and Broadcom Jericho3-based platforms.

Path-ID-aware forwarding: Instead of (or in addition to) 5-tuple ECMP hash, a UEC-capable switch can use the path ID field in the UET header for forwarding decisions. This requires custom TCAM/lookup programming and is available in programmable ASIC platforms (Tofino2, P4-programmable switches) and newer fixed-function ASICs with UEC-specific firmware.

UEC switch capability matrix -- baseline vs enhanced features
Baseline = minimum for UEC operation. Enhanced = full UEC performance. March 2026 availability.
FeatureTier
Mellanox SN5600
Spectrum-4
Generic Spectrum-4
Spectrum-4
Spectrum-2/3
Spectrum-2/3
Broadcom TH5
StraDNX
Intel Tofino2
Programmable
ECN markingBASELINEooooo
PFC disabledBASELINEooooo
Per-flow ECN markingENHANCED---oo
NPM feedback exportENHANCED---betaP4
Path-ID forwardingENHANCED----o
ECN markingbaseline
IPv4 ECN CE-bit marking when output queue exceeds threshold. Same as DCQCN. Required for UEC congestion control.
Sample config:
nv set qos ecn enable on
nv set qos ecn profile roce min-threshold 100KB max-threshold 500KB
Impact if missing:
Without ECN: no congestion signal. Sender runs at full rate into congested switch. Retransmit will handle eventual loss but bandwidth waste is high.
o = supported- = not supportedbeta = early firmwareP4 = P4-programmable only

The baseline deployment question

For the vast majority of AI fabrics as of March 2026: run UEC endpoints on existing Ethernet switches with ECN enabled. You get PFC-free operation and the retransmit-based reliability. You lose NPM path feedback and path-ID-aware forwarding -- the multipath is still hash-based ECMP, just like RoCEv2 with RSHP. You gain the operational simplicity of no PFC.

Whether the NPM and path-ID features justify a switch refresh is a deployment-specific calculation: how large is the cluster, how often do you see PFC events in production, how much does the PFC configuration complexity cost you operationally vs the switch refresh cost.