Lavoravo per Spirent, un’azienda specializzata in test e misurazioni che sviluppa sistemi di test per reti ad alte prestazioni. Il prodotto si chiamava Test Center e, insieme a un team di grande talento, stavamo sviluppando il sistema utilizzato per testare i sistemi RoCEv2. Il mio lavoro si concentrava in particolare sul Priority Flow Control (PFC) e su come abilitarlo per il “Packet Analyzer and Generator” (noto anche come PGA) basato su FPGA da 800 Gbps.
Tuttavia, non ho mai avuto modo di esaminare concretamente il Livello 4, e questo promemoria si propone di colmare questa lacuna illustrando gli elementi chiave del Livello di Trasporto InfiniBand (L4) e visualizzandoli con alcuni diagrammi.
Il frame RoCEv2 Link to heading
Partiamo dal frame RoCEv2 vero e proprio:
Intestazione di trasporto di base (BTH) Link to heading
Campi chiave inclusi nell’intestazione BTH:
Opcode: utilizzato per specificare il tipo di operazione RDMA, come RDMA_WRITE, RDMA_READ, …
Coppia di code di destinazione: utilizzata per distinguere tra diverse coppie di code di destinazione per un pacchetto.
Richiesta di conferma: indica se il destinatario deve inviare una conferma (ACK) per questo pacchetto.
Numero di sequenza del pacchetto (PSN): utilizzato nel tracciamento della sequenza dei pacchetti per una consegna affidabile.
Poiché UDP è un protocollo inaffidabile, in cui i frame possono essere persi, fuori sequenza o duplicati, il PSN viene utilizzato per garantire la corretta consegna. Tuttavia, ciò implica anche che debba esserci un modo per l’IBTL di richiedere la ritrasmissione dei frame. Questo viene realizzato utilizzando l’intestazione AETH, descritta di seguito.
Intestazione di trasporto estesa (ETH) Link to heading
Il livello di trasporto InfiniBand dispone di diverse intestazioni estese, utilizzate per funzioni specifiche. Nel caso di RDMA, le due più interessanti sono RETH e AETH.
Intestazione di trasporto estesa RDMA (RETH) Link to heading
L’operazione RDMA_WRITE richiede diversi elementi, rappresentati nei campi dell’intestazione estesa RETH. Questa intestazione comunica all’hardware ricevente i dettagli dell’operazione di scrittura, tra cui:
Indirizzo virtuale: l’indirizzo di memoria di destinazione in cui verranno scritti i dati
Chiave remota (R_Key): la chiave di accesso che convalida le autorizzazioni per la regione di memoria
Lunghezza: la dimensione dei dati da trasferire
ACK Intestazione di trasporto estesa (AETH) Link to heading
Come spiegato in precedenza, è necessario che l’IBTL notifichi al mittente eventuali trasmissioni inaffidabili. Ciò avviene tramite l’estensione EATH, che contiene il seguente campo:
Sindrome: un campo che contiene codici di risposta che indicano successo (ACK), condizioni di errore (NAK) o stato di ricevitore non pronto (RNR), insieme alle informazioni di controllo del flusso.
Numero di sequenza del messaggio (MSN): indica il numero di sequenza del messaggio completato più di recente, il che implica che tutti i messaggi con numeri di sequenza inferiori sono stati ricevuti correttamente.
Estensioni personalizzate Link to heading
La specifica IBTL (consultare il Capitolo 9) contiene diverse estensioni, alcune delle quali hanno attirato la mia attenzione:
Confronta e scambia: consente di eseguire la sincronizzazione senza blocchi.
Invio vs Scrittura: Il primo può essere utilizzato per il flusso di controllo, mentre il secondo viene utilizzato per il flusso di dati.
Estensione immediata: consente lo scambio di metadati tramite canali laterali insieme alla memoria da trasferire.
Mi chiedevo anche come si facesse a sapere quali estensioni fossero presenti nell’intestazione. La risposta è semplice: per ogni opcode, esiste un elenco di estensioni da analizzare, definito staticamente come parte della specifica.
La sfida del flusso dell’elefante Link to heading
Come affermato da Toni Pasanen nel suo blog The Network Times:
La comunicazione tra GPU crea flussi di dati enormi, che le schede di rete compatibili con RDMA trasmettono alla velocità di linea. Questi flussi possono facilmente causare congestione nella rete di back-end.
Questa capacità di RDMA di generare traffico alla velocità di linea è straordinaria. Tuttavia, ciò crea anche un problema con la dimensione del flowlet (la dimensione del flusso tra due periodi di inattività consecutivi), per cui la probabilità di accedere a un “intervallo di inattività” diventa significativamente inferiore quando si utilizzano i flussi elephant di RDMA.
Immagine tratta da: Balanciamento del carico di rete con supporto per il riordino in rete per RDMA
La sfida del bilanciamento del carico Link to heading
Un’altra complessità riguarda il bilanciamento del carico con topologie spine-leaf, dove i pacchetti possono essere ricevuti fuori ordine su una singola coppia di code quando si utilizza il bilanciamento del carico Packet Spraying. Questo crea una complessità che Nvidia ha risolto introducendo una nuova operazione RDMA chiamata “RDMA Write Only”.
Immagine originale da: The Network Times
Conclusion Link to heading
Questo è un promemoria “attivo” che continuerò ad aggiornare man mano che troverò ulteriori informazioni sull’IBTL.
Non si può ancora giungere a una conclusione definitiva, se non che RDMA rappresenta un tentativo molto elegante di risolvere la sfida dell’efficienza di rete, pur presentando una serie di nuove problematiche.
References: