🤖 AI

OpenURMA: A Clean-Room Open Implementation of the Unified Bus Protocol

Questo documento presenta OpenURMA, la prima implementazione open-source in clean-room del protocollo Unified Bus di Huawei, che dimostra mediante simulazioni RTL, SystemC e gem5 che il disaccoppiamento dello stato per applicazione dallo stato di trasporto riduce la latenza di recupero remoto di 64 byte di 4,37 volte e aumenta la capacità di elaborazione di 2,80 volte rispetto alle tradizionali linee di base RoCEv2.

Autori originali: Bojie Li

Pubblicato 2026-05-28

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Bojie Li

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Il Grande Problema: Il Collo di Bottiglia del "Periferico"

Immaginate un moderno datacenter come un enorme edificio per uffici in cui migliaia di dipendenti (applicazioni) devono parlarsi istantaneamente.

Attualmente, il modo standard in cui comunicano è il seguente:

Il Problema del Periferico: La scheda di rete (NIC) è trattata come un dispositivo periferico, simile a una stampante o a un mouse collegati a un computer. Si trova "fuori" dal cervello principale (la CPU).
Il Sistema di Code: Per inviare un messaggio, un dipendente deve scrivere un promemoria (una "Richiesta di Lavoro"), portarlo alla cassetta della posta della scheda di rete (il "Doorbell") e attendere. La scheda di rete lo raccoglie quindi, lo elabora e scrive un promemoria "Fatto" nella cassetta della posta.
Il Ingorgo: Poiché la scheda di rete è "fuori", ogni singolo promemoria deve attraversare un'autostrada trafficata (il bus PCIe) quattro volte solo per essere inviato e confermato.
La Crisi della Memoria: La scheda di rete deve mantenere un raccoglitore personale per ogni singola coppia di dipendenti che parlano tra loro. Se avete 1.000 dipendenti che parlano con altri 1.000, la scheda ha bisogno di 1 milione di raccoglitori. Rimane senza spazio sulla scrivania (memoria on-chip) e deve iniziare a correre all'archivio nel seminterrato (RAM host) per prendere i file. Questo rallenta tutto a un passo di lumaca.

Il Risultato: Anche se i cavi internet (il "filo") sono incredibilmente veloci, l'intero sistema è bloccato nel traffico a causa di come la scheda di rete è collegata e organizzata.

La Soluzione: Il Bus Unificato (UB) di Huawei

Huawei ha proposto un nuovo design chiamato Bus Unificato (UB) (nel loro chip Ascend 950) per risolvere questo problema. Non hanno solo riparato il vecchio sistema; hanno cambiato le regole della strada.

1. Spostare l'Ufficio Dentro l'Edificio
Invece di avere la scheda di rete come periferica fuori dall'edificio, UB colloca il controller di rete all'interno dell'edificio nel corridoio principale (il bus on-chip).

Analogia: Invece di uscire nell'atrio per spedire una lettera, ora potete semplicemente consegnarla a un collega che sta proprio accanto alla vostra scrivania. Non dovete attraversare l'autostrada quattro volte; basta un solo passo.

2. Dividere il Sistema di Archiviazione
Il vecchio sistema manteneva un unico raccoglitore gigante per ogni coppia di persone che parlava. UB divide questo sistema:

Jetty: Una piccola scheda per la parte tua della conversazione.
Canale TP: Una scheda condivisa per la parte dell'altra persona.
Analogia: Invece di aver bisogno di un raccoglitore unico per ogni coppia di persone (il che esplode in termini di dimensioni), avete bisogno solo di una scheda per voi stessi e di una scheda condivisa per la persona con cui state parlando. Il numero totale di raccoglitori cresce lentamente (in modo additivo) invece di esplodere (in modo moltiplicativo). Questo impedisce alla scrivania della scheda di rete di traboccare.

3. La Scorciatoia "Load/Store"
Poiché il controller è ora all'interno dell'edificio, la CPU può parlargli direttamente utilizzando istruzioni standard (come LOAD o STORE), proprio come leggere una variabile in un programma.

Analogia: Non dovete compilare un modulo, andare alla cassetta della posta e aspettare una ricevuta. Prendete semplicemente i dati di cui avete bisogno istantaneamente.

4. Regole Opzionali (Ordinamento su Scelta)
Il vecchio sistema imponeva regole rigide: "Devi ricevere i messaggi nell'ordine esatto in cui sono stati inviati, non importa cosa". Questo è lento e inutile per molte attività.

Analogia: UB dice: "Possiamo consegnare i messaggi il più velocemente possibile. Se davvero ne avete bisogno in ordine, alzate la mano e rallenteremo per ordinarli. Se non vi importa, li metteremo semplicemente nella vostra casella di posta man mano che arrivano". Questo fa risparmiare tempo a tutti coloro che non hanno bisogno di un ordine rigoroso.

Cosa Ha Fatto OpenURMA

Il chip di Huawei esiste, ma è una "scatola nera". Nessuno può vedere come funziona all'interno, misurarlo o costruirvi sopra.

OpenURMA è la prima implementazione open-source, clean-room di questo nuovo sistema.

"Clean-room" significa che è stato costruito da zero utilizzando solo il regolamento pubblico (la specifica), senza guardare il codice segreto di Huawei.
Hanno costruito tre versioni per testarlo:
1. RTL: Il progetto effettivo per i chip hardware (testato su una scheda FPGA).
2. SystemC: Una simulazione computerizzata super-dettagliata della rete.
3. gem5: Una simulazione completa di un computer che esegue un sistema operativo reale.

Hanno confrontato il loro nuovo sistema (OpenURMA) con lo standard vecchio (RoCEv2) utilizzando gli stessi identici strumenti per garantire una gara equa.

I Risultati: Quanto è Più Veloce?

Il documento afferma miglioramenti massicci, specificamente per operazioni piccole e veloci (come il recupero di un minuscolo pezzo di dati):

Velocità: Il nuovo sistema è 4,37 volte più veloce (circa 500 nanosecondi) rispetto al vecchio sistema (circa 2.186 nanosecondi) per un recupero dati standard.
Throughput: Può gestire 2,8 volte più dati al secondo.
Efficienza: Utilizza molto poco spazio sul chip (solo circa il 14% dello spazio disponibile su una scheda di test).
Scalabilità: Man mano che si aggiungono più utenti (da 1 a 1.024), il vecchio sistema rallenta drasticamente perché rimane senza spazio sulla scrivania. Il nuovo sistema rimane veloce e costante perché il suo sistema di archiviazione è efficiente.

Perché Questo È Importante (Secondo il Documento)

Il documento sostiene che il modo attuale in cui colleghiamo i computer nei datacenter (trattando la scheda di rete come una periferica) è fondamentalmente rotto per i carichi di lavoro moderni di AI e big data.

L'Alternativa "Coerente": Esistono altre tecnologie (come CXL o NVLink) che cercano di far apparire la memoria "condivisa" e "coerente". Tuttavia, il documento sostiene che queste tecnologie collassano quando si cerca di scalare verso grandi cluster (molti rack di server) perché richiedono troppo tracciamento dello stato e non possono gestire bene gli errori di rete.
Il Vantaggio UB: UB accetta che la rete non è perfetta e non cerca di imporre una "coerenza perfetta" in tutto l'edificio. Invece, fornisce all'applicazione gli strumenti per gestire l'ordine solo quando necessario, permettendole di scalare a migliaia di server senza il crollo delle prestazioni osservato in altri sistemi.

Riassunto

Pensate al vecchio sistema come a un ufficio postale dove dovete camminare al bancone, compilare un modulo, fare la fila e ottenere una ricevuta per ogni singola lettera.
Pensate al nuovo sistema OpenURMA come a un corriere privato che siede proprio accanto a voi, sa esattamente con chi state parlando e può consegnare una lettera nella vostra mano istantaneamente senza alcuna burocrazia, a meno che non chiediate specificamente una ricevuta.

Il documento dimostra che questo nuovo modo di organizzare la rete non è solo una teoria, ma un design funzionante e aperto che è significativamente più veloce e scalabile di ciò che usiamo oggi.

Riepilogo Tecnico: OpenURMA

Enunciato del Problema
L'RDMA (Remote Direct Memory Access) dei moderni data center è strutturalmente limitato dal collo di bottiglia dell'astrazione "NIC periferica" ereditata da InfiniBand e RoCE. In questo modello, la Network Interface Card (NIC) risiede dietro il bus PCIe e la comunicazione segue un modello di programmazione a Coppie di Code (Queue-Pair, QP). Questa progettazione impone due costi critici che sono diventati insostenibili per i carichi di lavoro di addestramento AI caratterizzati da fanout massicci (migliaia di GPU) e dimensioni dei messaggi ridotte (gradienti da 64 byte):

Esplosione dello Stato: Una QP fonde l'identità dell'applicazione con l'affidabilità del trasporto, richiedendo uno stato per connessione per ogni coppia (applicazione locale, endpoint remoto). A una scala di 1024x1024, ciò richiede ~537 MB di stato, superando la SRAM on-chip e costringendo le operazioni a pagare un round trip PCIe per ricaricare il contesto.
Latenza di Attraversamento PCIe: Poiché la NIC è una periferica, ogni operazione attraversa il confine PCIe quattro volte (doorbell MMIO, fetch DMA WQE, scrittura DMA CQE e polling CPU con mancato riscontro). Su un'operazione da 64 byte, questi attraversamenti consumano ~1,5 µs di un round trip di ~2 µs, gonfiando la latenza di un ordine di grandezza oltre la velocità del cavo.

I lavori precedenti (patch software come FaSST, ottimizzazioni hardware come SRNIC o substrati programmabili) hanno affrontato i sintomi ma lasciato intatta l'astrazione fondamentale.

Metodologia
Il documento presenta OpenURMA, la prima implementazione open a codice pulito della specifica Unified Bus (UB) di Huawei (2025), che sostituisce l'astrazione NIC periferica. UB disaccoppia lo stato dell'endpoint per applicazione dallo stato del trasporto per host, sposta il controller sul bus on-chip ed espone l'ordinamento come una funzionalità opzionale.

L'implementazione è realizzata utilizzando la toolchain OpenClickNP, che riduce una singola descrizione sorgente in tre livelli di modellazione per un confronto rigoroso, "mela con mela", rispetto a una baseline OpenRoCE (RoCEv2 RC) corrispondente:

RTL Sintetizzabile: Implementato su un FPGA Alveo U50, con chiusura a 322 MHz.
Simulazione a Livello di Ciclo: Un simulatore SystemC a due nodi che modella entrambi gli endpoint, il cavo e le gerarchie di memoria.
Struttura di Sistema Completa: Un ambiente gem5 che esegue binari ARM reali e un driver Linux contro la NIC SystemC.

La metodologia di valutazione tiene esplicitamente conto dei costi bidirezionali, inclusi i trasferimenti NIC-DRAM lato destinazione e gli attraversamenti PCIe, evitando le misurazioni di latenza "solo invio" comuni nella letteratura precedente.

Principali Spostamenti Architetturali
OpenURMA implementa quattro spostamenti architetturali definiti nella specifica UB:

Divisione dei Livelli (Stato Limitato): Separa il livello transazione (per applicazione Jetty) dal livello trasporto (per host TP Channel). Lo stato scala additivamente come $O(N+M)$ invece che moltiplicativamente come $O(N \cdot M)$ .
Controller On-Chip: Con lo stato limitato a ~110 KB (adatto alla SRAM on-chip), il controller risiede sul bus on-chip della CPU, eliminando il confine PCIe.
Percorso Load/Store: La CPU può accedere alla memoria remota tramite istruzioni native ld/st direttamente al controller, bypassando code di lavoro, doorbell e DMA.
Ordinamento Opzionale: L'ordinamento è esposto come quattro assi ortogonali (modalità di servizio, ordine di esecuzione, fence, ordine di completamento) a cui le applicazioni aderiscono su base opzionale. La logica di gating riutilizza i contatori esistenti, aggiungendo zero cicli di pipeline per le operazioni non ordinate.

Risultati Chiave
Sul fetch remoto canonico da 64 byte (LOAD su UB vs READ su RoCEv2):

Latenza: Il percorso load/store di UB raggiunge una latenza end-to-end di ~500 ns, una riduzione di 4,37× rispetto alla baseline DMA RoCE corrispondente (2186 ns). Anche sulle verbosità che richiedono il percorso della coda di lavoro, UB è ~2,2× più veloce grazie all'eliminazione degli attraversamenti PCIe.
Throughput: UB sostiene un throughput di richieste di lavoro 2,80× superiore rispetto a OpenRoCE.
Scalabilità dello Stato: A 1024x1024 endpoint, OpenURMA utilizza 110,6 KB di stato contro 536,9 MB per RoCE, una riduzione di 4.855×. Ciò previene la "scogliera di latenza" in cui le prestazioni di RoCE degradano bruscamente una volta che il numero di connessioni supera ~23 (punto di overflow SRAM).
Costo dell'Ordinamento: L'ordinamento opzionale è "quasi gratuito"; le operazioni che bypassano il gating non incurrono in cicli di pipeline.
Affidabilità e Congestione: OpenURMA implementa l'acknowledgement selettivo (SACK) e un controllore di congestione C-AQM, mostrando un goodput superiore e una latenza di coda inferiore in caso di perdita rispetto a Go-Back-N e DCQCN.
Scale-Out vs Tessuti Coerenti: Il documento sostiene che i tessuti coerenti (CXL, NVLink) non possono scalare a livello di rack a causa della crescita dello stato della directory ( $O(N)$ ) e dei costi di broadcast di invalidazione. L'approccio non coerente e opzionale di UB evita queste scogliere, mantenendo una latenza piatta all'aumentare delle dimensioni del cluster.

Significato e Affermazioni
Il documento afferma che OpenURMA fornisce la prima validazione empirica delle promesse architetturali del protocollo Unified Bus senza fare affidamento su silicio chiuso. Il significato risiede nel dimostrare che i tre impegni architetturali – stato limitato, controller sul bus e ordinamento opzionale – sono mutuamente portanti:

Lo stato limitato è necessario per mantenere il controller on-chip.
Il controller on-chip è necessario per abilitare il percorso load/store.
La divisione dei livelli è necessaria per rendere l'ordinamento opzionale a costo zero.

Gli autori concludono che OpenURMA sostituisce l'astrazione NIC periferica con un modello peer-to-peer che scala ai carichi di lavoro di addestramento AI, offrendo una strada verso l'accesso alla memoria remota sub-microsecondo strutturalmente impossibile sotto l'attuale paradigma PCIe/QP. L'implementazione è rilasciata come RTL open-source e harness di simulazione per abilitare ulteriori ricerche e prototipazione.