NVIDIA unifie le réseau initié par GPU dans le stack CUDA grâce à DOCA GPUNetIO

NVIDIA a détaillé la manière dont son framework DOCA GPUNetIO sert de fondation unifiée pour le réseau initié par GPU à travers l'ensemble du stack logiciel CUDA. En standardisant les opérations GDA-KI (GPUDirect Async Kernel-Initiated) sous une structure commune, cette technologie remplace les implémentations fragmentées et propres à chaque bibliothèque au sein de frameworks tels que NCCL, NVSHMEM, UCX/NIXL et le SDK Aerial 5G.

Élimination des goulots d'étranglement du chemin de contrôle du CPU

Les applications GPU distribuées traditionnelles reposent sur le processeur hôte (CPU) pour gérer les transactions réseau, ce qui introduit de la latence le long des parcours de données critiques. DOCA GPUNetIO combine GPUDirect RDMA, GDRCopy et GDA-KI afin que les kernels CUDA puissent gérer directement les opérations Ethernet, RDMA, Verbs et DMA sans acheminer les transactions par le processeur hôte.

Une double distribution : open source et kit SDK complet

NVIDIA distribue GPUNetIO selon deux configurations complémentaires. Une bibliothèque open source légère fournit une implémentation axée sur Verbs pour les frameworks nécessitant des transports réseau entièrement ouverts. De son côté, le SDK DOCA complet agit comme un sur-ensemble, ajoutant la prise en charge des interfaces Ethernet, DMA et Communication Channel.

La version open source peut détecter la présence du SDK DOCA complet lors de l'exécution grâce au chargement dynamique via dlopen. Si le SDK est détecté, la couche open source fait appel aux fonctions fermées du SDK pour bénéficier de capacités étendues ; s'il est absent, elle continue de fonctionner avec son implémentation Verbs open source.

Modèles de configuration et d'exécution du chemin de contrôle

L'exécution nécessite un modèle de programmation en deux phases. Dans un premier temps, le CPU hôte exécute le chemin de contrôle en initialisant les objets de file d'attente réseau, comme les files Verbs ou Ethernet via mlx5dv, puis exporte les descripteurs de file dans la mémoire du GPU. Ensuite, les kernels CUDA prennent en charge directement le parcours des données sur le GPU en publiant des WQE (Work Queue Entries), en notifiant la carte réseau et, si nécessaire, en interrogeant les CQE (Completion Queue Entries).

Pour avertir le matériel du travail en attente, GPUNetIO prend en charge plusieurs modes de notification (« doorbell ») : les écritures directes MMIO classiques, le mode BlueFlame pour les charges de travail sensibles à la latence où les WQE complets sont écrits dans les registres de la carte, ainsi qu'un mode assisté par le CPU. Ce dernier achemine les mises à jour du GPU via une mémoire partagée scrutée par un thread du CPU hôte, ce qui permet de s'adapter aux architectures dépourvues de liaisons directes entre le GPU et la carte réseau, comme DGX Spark.

Intégration au sein des bibliothèques de communication

Cette architecture permet aux bibliothèques de haut niveau de standardiser la mécanique de transport. Depuis la version 2.27, NCCL a intégré GDA-KI à travers son interface GIN (GPU-Initiated Networking) en utilisant le backend Verbs open source de GPUNetIO, isolant ainsi les algorithmes collectifs de la gestion bas niveau des files d'attente. Des intégrations parallèles s'étendent aux modèles de programmation fondés sur PGAS comme NVSHMEM, permettant à l'ensemble de l'écosystème GPU de bénéficier d'améliorations de performances unifiées.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: How DOCA GPUNetIO Unifies GPU-Initiated Networking Across the NVIDIA Software Stack