Am lucrat pentru Spirent, o companie de testare și măsurare care dezvoltă sisteme de testare pentru rețele de înaltă performanță. Produsul se numea Test Center și, împreună cu o echipă foarte talentată, dezvoltam sistemul folosit pentru testarea sistemelor RoCEv2. M-am concentrat în special pe Priority Flow Control (PFC) și pe modul de activare a acestuia pentru „Packet Analyzer and Generator” (cunoscut și sub numele de PGA) bazat pe FPGA de 800 Gbps.
Totuși, nu am avut niciodată o privire concretă asupra Nivelului 4, iar acest memoriu încearcă să elimine această lacună prin articularea elementelor cheie ale Nivelului de Transport InfiniBand (L4) și vizualizarea lor cu ajutorul câtorva diagrame.
Să începem cu cadrul RoCEv2 propriu-zis:
Antet de transport de bază (BTH)
Link to heading
Câmpuri cheie incluse în antetul BTH:
Opcode: Folosit pentru a specifica tipul de operațiune RDMA, cum ar fi RDMA_WRITE, RDMA_READ, …
QP de destinație: Folosit pentru a distinge între diferite perechi de cozi de destinație pentru un pachet.
Cerere de confirmare: Indică dacă receptorul trebuie să returneze un ACK pentru acest pachet.
Numărul de secvență a pachetelor (PSN): utilizat în urmărirea secvenței pachetelor pentru o livrare fiabilă.
Întrucât UDP este un protocol nesigur, unde cadrele pot fi pierdute/în afara secvenței sau duplicate, PSN este utilizat pentru a asigura livrarea corectă. Totuși, aceasta înseamnă și că ar trebui să existe o modalitate prin care IBTL să solicite retransmiterea cadrului. Acest lucru se realizează folosind antetul AETH, care este descris mai jos.
Antet de transport extins (ETH)
Link to heading
Nivelul de transport InfiniBand are mai multe antete extinse, utilizate pentru funcții specifice. În cazul RDMA, cele două cele mai interesante sunt RETH și AETH.
Antet de transport extins RDMA (RETH)
Link to heading
Operația RDMA_WRITE necesită mai multe elemente, care sunt reprezentate în câmpurile antetului extins RETH. Acest antet informează hardware-ul receptor despre detaliile operației de scriere, inclusiv:
Adresă virtuală: Adresa de memorie destinație unde vor fi scrise datele
Cheie de acces la distanță (R_Key): Cheia de acces care validează permisiunile pentru regiunea de memorie
Lungime: Dimensiunea datelor care vor fi transferate
Antet de transport extins ACK (AETH)
Link to heading
Așa cum s-a explicat anterior, este necesar ca IBTL să notifice expeditorul în cazul unei transmisii nesigure. Acest lucru se face folosind extensia EATH, care conține următorul câmp:
Sindrom: Un câmp care conține coduri de răspuns care indică succesul (ACK), condițiile de eroare (NAK) sau starea receptorului negata (RNR), împreună cu informații de control al fluxului.
Numărul de secvență al mesajului (MSN): Indică numărul de secvență al celui mai recent mesaj completat, ceea ce înseamnă că toate mesajele cu numere de secvență mai mici au fost recepționate cu succes
Specificația IBTL (vezi Capitolul 9) conține destule extensii, dintre care unele mi-au atras atenția:
Comparare și schimb: Face posibilă sincronizarea fără blocare.
Trimitere vs. Scriere: Prima poate fi utilizată pentru controlul fluxului, în timp ce a doua este utilizată pentru fluxul de date.
Extensie imediată: Permite schimbul de metadate pe canalul lateral împreună cu transferul memoriei.
M-am întrebat și eu cum se știe ce extensii sunt prezente în antet. Răspunsul este simplu: pentru fiecare opcode, este o listă de extensii care trebuie analizate - lista este definită static, ca parte a specificației.
Provocarea fluxului de elefant
Link to heading
După cum a afirmat Toni Pasanen pe blogul său The Network Times:
Comunicarea GPU-GPU creează fluxuri masive de tip „elephant flow”, pe care plăcile de rețea compatibile cu RDMA le transmit la o rată de linie. Aceste fluxuri pot cauza cu ușurință congestie în rețeaua backend.
Această capacitate a RDMA de a genera trafic la rata unei linii este uimitoare. Dar acest lucru creează și o problemă cu dimensiunea fluxului (dimensiunea fluxului între două perioade consecutive de inactivitate), unde probabilitatea de a accesa un „interval de inactivitate” devine semnificativ mai mică atunci când se utilizează fluxuri RDMA de tip „elephant”.
Imagine din: Echilibrarea încărcării în rețea cu suport pentru reordonare în rețea pentru RDMA
Provocarea echilibrării încărcării
Link to heading
Cealaltă complexitate se referă la echilibrarea încărcării cu topologii spine-leaf, unde pachetele pot fi primite în afara ordinii pe o singură pereche de coadă atunci când se utilizează echilibrarea încărcării Packet Spraying. Aceasta creează o complexitate, pe care Nvidia a rezolvat-o prin introducerea unei noi operațiuni RDMA numită „RDMA Write Only”.
Imagine originală de la: The Network Times
Aceasta este o notă „activă” pe care o voi actualiza pe măsură ce găsesc mai multe informații despre IBTL.
Nu există încă nicio concluzie, cu excepția faptului că RDMA este o soluție foarte elegantă pentru a rezolva provocarea eficienței rețelei și vine cu un set de noi provocări.
References: