NVIDIA vereinheitlicht GPU-initiiertes Networking im gesamten Software-Stack mit DOCA GPUNetIO

Die CPU vom kritischen Pfad nehmen

Nach Angaben von NVIDIA brauchen GPU-Anwendungen zunehmend Networking und Datenbewegung als GPU-gesteuerte Operationen statt als hostgesteuerte Dienste. Steht die CPU bei jeder Netzwerktransaktion im Mittelpunkt, wird sie zum Engpass auf dem kritischen Pfad: Sie erhöht die Latenz und begrenzt, wie gut verteilte Anwendungen in Echtzeit reagieren können.

DOCA GPUNetIO wird als GPU-zentrierte Networking-SDK-Schicht für Paketverarbeitung und Datenbewegung in Echtzeit beschrieben. Es kombiniert Technologien wie GPUDirect RDMA, GPUDirect Async Kernel-Initiated (GDA-KI) und GDRCopy, sodass CUDA-Kernel Ethernet-, RDMA-, Verbs- und DMA-Operationen direkt ansteuern können, während die CPU nicht auf dem kritischen Pfad liegt.

Das Framework besteht aus zwei Teilen: CPU-Funktionen auf dem Control Path, die mit DOCA Ethernet, DOCA Verbs, DOCA DMA und DOCA CommChannel erzeugte Transportobjekte in den GPU-Speicher exportieren, sowie GPU-CUDA-Funktionen auf dem Data Path, mit denen Kernel diese exportierten Objekte bearbeiten.

Eine gemeinsame Implementierung statt vieler

NVIDIA zufolge hatte jede Kommunikationsbibliothek, bevor GPUNetIO zur gemeinsamen Basis wurde, ihre eigene GPU-initiierte RDMA-Implementierung im Stil von GDA-KI entwickelt, mit eigenen Annahmen, eigenem Code und eigenem Wartungsaufwand. Gemeinsamkeiten gab es nicht.

Das Framework ist inzwischen in NVSHMEM, NCCL, das Aerial 5G SDK, UCX/NIXL, NVQLink mit dem Holoscan Sensor Bridge Operator, den Holoscan Advanced Network Operator, DeepEP/HybridEP und weitere Komponenten integriert. NVIDIA argumentiert, die Konvergenz auf eine einzige GDA-KI-Implementierung schaffe einen gemeinsamen Ort für Funktionen, Optimierungen und Fehlerbehebungen, verringere doppelten Entwicklungsaufwand über SDKs hinweg und bringe Neuerungen aus einem Framework schneller in andere.

• NCCL GIN nutzt seit Version 2.27 den quelloffenen GPUNetIO-Verbs-Pfad als Backend, sodass Collective-Algorithmen auf Geräteseite RDMA-Operationen direkt von der GPU aus steuern können.
• NVSHMEM 3.7 führte einen GPUNetIO-basierten Transport ein, der laut NVIDIA die Implementierungskomplexität senkt und die IBGDA-Performance erhält. Vom Unternehmen angeführte Benchmarks zeigen, dass GDA-KI bei kleinen Nachrichtengrößen eine bessere Skalierung von CTA und QP ermöglicht.
• NVQLink erreicht mit dem auf GPUNetIO basierenden Operator GPU RoCE Transceiver eine minimale Round-Trip-Latenz von rund 2,6 Mikrosekunden für Quanten-klassische Workflows auf IGX Thor mit Blackwell-GPU und ConnectX-7.

Open-Source- und SDK-Version

NVIDIA liefert GPUNetIO in zwei Varianten aus. Die Version im vollständigen DOCA SDK ist die Obermenge, im DOCA Programming Guide dokumentiert und deckt die Integration von Verbs, Ethernet, DMA und Comm Channel ab. Das Open-Source-Projekt ist eine schlankere, auf RDMA Verbs fokussierte Implementierung für Frameworks, die bei der Einbindung von Netzwerktransporten vollständig offen bleiben wollen.

Die Aufteilung solle nicht zu zwei auseinanderlaufenden Stacks führen, so das Unternehmen. Die Open-Source-Implementierung kann das DOCA SDK zur Laufzeit erkennen und, falls es vorhanden ist, ausgewählte Funktionen des proprietären SDK per dlopen aufrufen. Dafür muss eine dokumentierte Umgebungsvariable mit dem korrekten SDK-Pfad gesetzt sein. Ohne das SDK läuft die Open-Source-Version eigenständig. Für den Verbs-Pfad bieten beide Varianten eine ähnliche CUDA-Device-API, wodurch das GPU-Programmiermodell weitgehend einheitlich bleibt.

Das Programmiermodell

Anwendungen durchlaufen zunächst eine hostseitige CPU-Phase für den Control Path und verlagern den Data Path dann in CUDA-Kernel auf der GPU. Der Control Path initialisiert GPU und Netzwerkgeräte, reserviert Speicher und erzeugt anschließend Netzwerktransportobjekte. DOCA Verbs oder DOCA Ethernet legen beispielsweise über mlx5dv auf der CPU ein Netzwerk-Queue-Objekt an. Eine GPUNetIO-CPU-Funktion exportiert dann die relevanten Elemente dieser Queue in einen Deskriptor im GPU-Speicher und liefert dafür eine GPU-Adresse zurück. Die Anwendung startet einen CUDA-Kernel und übergibt diesen Deskriptor als Eingabeparameter.

Um die Einrichtung von DOCA Verbs zu vereinfachen, führte NVIDIA übergeordnete Funktionen wie doca_gpu_verbs_create_qp_hl ein, die die Schritte zum Erstellen und Verbinden von RDMA-QPs bündeln. Sie sind sowohl in der SDK- als auch in der Open-Source-Version enthalten. Im Data Path setzen CUDA-Threads Work Queue Entries (WQEs) ab, etwa RDMA Write oder RDMA Read.

Was das für Entwickler bedeutet

Für Teams, die auf NCCL, NVSHMEM oder UCX/NIXL aufbauen, bedeutet die Änderung, dass Verbesserungen beim GPU-initiierten Networking künftig in einer gemeinsamen Codebasis landen sollen statt in mehreren parallelen. NVIDIA verweist auf weniger doppelten Code, weniger Fragmentierung im Verhalten und eine tragfähigere Basis für die langfristige Weiterentwicklung. Entwickler können mit dem GPUNetIO-Programmierleitfaden des DOCA SDK, dem Open-Source-Repository von GPUNetIO und der GIN-Device-API in den NCCL-Tests als Referenzcode einsteigen.