DOCA GPI

Par où commencer : Cette skill suppose que DOCA est déjà installé et que l'utilisateur fait du travail GPI pratique sur un hôte disposant à la fois d'un appareil BlueField / ConnectX et d'un GPU NVIDIA accessible via PCIe. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (installer / configurer / compiler / modifier / exécuter / tester / déboguer / utiliser) ; ouvrez CAPABILITIES.md quand la question porte sur ce que GPI peut exprimer sur cette version — le modèle d'objet domain + channel, le transfert de handle côté GPU, la relation avec doca-gpunetio et doca-verbs, les objets attribute, et la couche de sécurité. Si l'utilisateur n'a pas encore installé DOCA, router vers doca-setup d'abord.

Exemples de questions que cette skill traite bien

Les CLASSES de questions GPI que cette skill est construite pour répondre, chacune avec un exemple développé. L'agent devrait traiter la classe comme la partie porteuse — l'exemple développé est une seule instance.

« Dois-je utiliser doca-gpi ou doca-gpunetio pour ce cas ? » — exemple développé : « mon kernel CUDA a besoin de poster des écritures RDMA directement sur la mémoire d'un DPU distant — est-ce que je veux la surface Send/Receive de niveau supérieur ou la surface channel/queue de niveau inférieur ? ». Répondu par la règle de sélection channel-level vs Send/Receive-level dans le tableau de sélection de surface de CAPABILITIES.md ## Capabilities and modes.
« Comment j'établis un canal GPI et le connecte à un pair distant ? » — exemple développé : « créer le GPI, définir le dimensionnement des attributs domain + channel, créer le canal, échanger les infos de connexion d'endpoint avec le distant, connecter l'endpoint ». Répondu par le cycle de vie du canal object dans CAPABILITIES.md ## Capabilities and modes
- la marche de configuration dans TASKS.md ## configure.
« Qu'est-ce que le handle côté GPU et comment je le passe à mon kernel CUDA ? » — exemple développé : « doca_gpi_gpu_channel_get retourne un `doca_gpu_gpi_channel— comment je fais entrer cela dans la liste d'arguments de mon kernel CUDA ? »*. Répondu par le pattern de transfert GPU dans [CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
- le câblage côté run dans TASKS.md ## run, avec lien croisé vers doca-gpunetio pour la surface de programmation CUDA elle-même.
« À quoi doit ressembler mon stack de versions CUDA + GPU + DOCA ? » — exemple développé : « j'ai BlueField-3 + A100 ; quelle Toolkit CUDA et quelle version DOCA j'ai besoin ? ». Répondu par la couche de version dans CAPABILITIES.md ## Version compatibility
- les vérifications d'installation dans TASKS.md ## install.
« Comment j'dimensionne les canaux et files de travail que je veux ? » — exemple développé : « je veux 64 canaux dans un domain, chacun avec une file d'envoi de 1024 entrées ; quels setters expriment cela ? ». Répondu par la règle de dimensionnement des objets attribute (doca_gpi_domain_attr_set_num_channels, doca_gpi_channel_attr_set_sq_wqe_num) dans CAPABILITIES.md ## Capabilities and modes
- l'étape de dimensionnement dans TASKS.md ## configure.
« Que signifie ce DOCA_ERROR_* d'un appel doca_gpi_* ? » — exemple développé : « `DOCAERRORde doca_gpi_gpu_channel_get»*. Répondu par la couche GPI sur la taxonomie inter-bibliothèques dans [CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
- l'échelle en couches dans TASKS.md ## debug qui s'escalade vers doca-debug.

Audience

Cette skill sert les développeurs externes construisant des applications DOCA résidentes sur GPU qui ont besoin de piloter directement les files RDMA depuis des kernels CUDA — c'est-à-dire les utilisateurs dont le code côté accélérateur veut poster du travail RDMA depuis la mémoire GPU sans faire un aller-retour par le CPU hôte. L'appelant canonique est un kernel CUDA qui s'exécute sur un GPU NVIDIA sur le même hôte qu'un appareil BlueField / ConnectX, a un accès de style GPUDirect aux files RDMA du DPU via la pile DOCA GPU-NetIO, et utilise le handle channel + queue GPI pour piloter l'initiation RDMA. Cette skill n'est pas pour les développeurs NVIDIA contribuant à DOCA GPI lui-même, et ce n'est pas la bonne surface pour l'API GPU NetIO Send/Receive de niveau supérieur en forme Ethernet — celle-ci appartient à doca-gpunetio.

Portée linguistique

DOCA GPI est fourni comme bibliothèque C avec le nom de module pkg-config doca-gpi. La surface côté hôte de la bibliothèque (doca_gpi_*) est C ; la surface côté GPU — le handle doca_gpu_gpi_channel* et les appels côté device qu'un kernel CUDA utilise contre ce handle — est compilée avec nvcc contre l'ensemble d'en-têtes côté device DOCA GPU NetIO documenté dans doca-gpunetio. Les consommateurs d'autre langage (Rust, Go, Python, …) consomment le *.so côté hôte via FFI ; la contribution de la skill en ce cas est de garder le cycle de vie du channel / queue, le transfert de handle GPU, la discipline de version, et la couche de sécurité indépendants du langage, et de router l'agent vers l'ABI C publique comme la surface faisant autorité qu'un wrapper finira par appeler. La surface côté GPU n'est pas encapsulable dans un autre langage — elle est compilée et liée dans le binaire CUDA lui-même.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait du travail DOCA GPI pratique sur un hôte disposant à la fois d'un appareil BlueField / ConnectX et d'un GPU NVIDIA. Concrètement :

Choisir entre doca-gpi (la surface channel/queue de niveau inférieur) et doca-gpunetio (la surface Send/Receive de niveau supérieur) pour une nouvelle charge de travail RDMA initiée par GPU.
Créer un doca_gpi sur un doca_dev, le configurer via la famille doca_gpi_set_* (compte de domain, index GID, port) et dimensionner les domains et canaux via les setters doca_gpi_domain_attr_* / doca_gpi_channel_attr_* avant doca_gpi_start().
Créer un canal avec doca_gpi_channel_create et récupérer son handle côté GPU avec doca_gpi_gpu_channel_get, puis passer le handle côté GPU à un kernel CUDA.
Échanger les infos de connexion d'endpoint avec un pair distant en utilisant doca_gpi_channel_ep_conn_info_create / doca_gpi_channel_ep_connect pour établir le bout à bout du canal piloté par GPU.
Attacher des régions mémoire à un domain GPI avec doca_gpi_domain_attach_local_mmap / doca_gpi_domain_attach_remote_mmap (chacune appuyée par un doca_mmap que l'application a créé).
Déboguer un DOCA_ERROR_* retourné par un appel doca_gpi_* et décider si la cause est un bug d'ordre de cycle de vie, une assignation de datapath GPU incorrecte, une incompatibilité de version CUDA, ou une couche en dessous de DOCA.

Ne chargez pas cette skill pour une orientation DOCA générale, l'installation de DOCA lui-même, le RDMA initié par CPU hôte, ou l'API GPU NetIO Send/Receive en forme Ethernet de niveau supérieur. Pour ceux-ci, utilisez doca-public-knowledge-map, doca-setup, doca-rdma, et doca-gpunetio respectivement.

Ce que cette skill fournit

C'est un loader mince. Le corps ne garde que l'orientation nécessaire pour choisir le bon fichier suivant. La matière spécifique à GPI substantielle vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que GPI peut exprimer sur cette version : le modèle d'objet doca_gpi / doca_gpi_domain / doca_gpi_channel, le transfert de handle côté GPU, la relation à doca-gpunetio (qui possède la surface device doca_gpu_gpi_channel* côté GPU) et à doca-verbs et doca-dpa (les couches transport et DPA que GPI construit dessus), les objets attribute de domain et de channel, la déclaration de maturité (chaque symbole doca_gpi_* est DOCA_EXPERIMENTAL), la couche GPI sur la taxonomie inter-bibliothèques DOCA_ERROR_*, la surface d'observabilité (scrutin de canal côté CUDA, échange de mmap-attach), et la politique de sécurité qui contrôle l'initiation RDMA côté GPU.
TASKS.md — workflows pas à pas pour les huit verbes dans scope : install, configure, build, modify, run, test, debug, use. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la skill suivante appropriée.

La skill suppose un hôte où DOCA est déjà installé à l'emplacement standard, une Toolkit CUDA compatible avec le DOCA installé est présente, et l'utilisateur a les privilèges que son profil d'installation publique attend. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup.

Ce que cette skill ne livre délibérément pas

Cette skill est une guidance pour l'agent, pas un bundle de samples ou templates. Pour garder la limite claire, elle ne contient délibérément pas — et les pull requests ne devraient pas ajouter :

Code source d'application DOCA GPI pré-écrit, dans n'importe quel langage. Le job de l'agent est de router l'utilisateur vers le code de référence vérifié (les samples DOCA GPU-NetIO livrés sur le set de packages installé sont les exemples développés canoniques pour le transfert côté GPU) et de prescrire une modification minimum-diff via le workflow universel modify-a-sample dans doca-programming-guide. Parce que chaque symbole GPI est tagué DOCA_EXPERIMENTAL dans l'en-tête public, la skill refuse d'écrire du source GPI à partir de prose documentaire.
Manifestes de compilation autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) parkés dans la skill. L'agent construit le manifeste de compilation dans le répertoire projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-gpi est la source de vérité.
Templates de kernel CUDA. La surface côté CUDA est possédée par doca-gpunetio ; le handle côté GPU de GPI est consommé par le modèle de programmation CUDA documenté là. Cette skill nomme le transfert GPI-spécifique (le type doca_gpu_gpi_channel*, l'appel de connexion du canal) mais n'écrit pas de kernels CUDA.
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artifact simulé ou incomplet dans l'arbre de cette skill, même étiqueté « reference », est trompeur : les utilisateurs le liront comme compilable.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est dans scope.
Pour le modèle d'objet GPI, le pattern de transfert côté GPU, les objets attribute de domain et de channel, la règle de compatibilité de version, la taxonomie d'erreur, l'observabilité et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows pas à pas — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Les deux fichiers compagnons se lient de manière croisée l'un à l'autre et à doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez-le dans les docs publiques ou dans la disposition du package installé » plutôt que « guidance spécifique à GPI ».

Skills connexes

doca-gpunetio — la bibliothèque GPU NetIO qui expose l'E/S Ethernet en forme Send/Receive pour les kernels CUDA et possède la surface device côté GPU que GPI transfert : le type doca_gpu_gpi_channel* et son API côté device .cuh vivent dans doca-gpunetio, et doca_gpi.h inclut doca_gpunetio.h. Les deux peuvent coexister dans la même application. Le tableau de sélection dans CAPABILITIES.md ## Capabilities and modes est l'aide décisionnelle porteuse.
doca-verbs et doca-dpa — les couches transport et DPA que GPI construit dessus. dependencies/meson.build liste doca-dpa, doca-gpunetio, et doca-verbs (plus les externals libmlx5 / libibverbs) ; doca_gpi_get_dpa retourne le doca_dpa* possédé par GPI pour le tuning des attributs DPA. Le type transport RDMA, la sélection GID / port, et la sémantique de permission vivent à la couche verbs ; GPI la consomme plutôt que de lier une file doca-rdma.
doca-rdmi — la surface d'initiateur côté DPA sœur. GPI et RDMI existent tous deux pour « piloter l'initiation RDMA depuis un accélérateur sans le CPU hôte sur le chemin de données » ; GPI est le cas GPU, RDMI est le cas DPA.
doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un package DOCA installé.
doca-setup — préparation de l'env, vérification d'installation, et le chemin je n'ai pas encore d'installation avec le conteneur NGC DOCA public.
doca-programming-guide — patterns de programmation DOCA généraux partagés par chaque bibliothèque : le pattern de compilation pkg-config + meson canonique, le workflow d'app première modify-a-shipped-sample universel, le cycle de vie Core-context universel, la taxonomie inter-bibliothèques DOCA_ERROR_*. Cette skill ajoute des spécifiques GPI par dessus.
doca-debug — l'échelle de debug transversale (install / version / build / link / runtime / program / driver). Overlays de debug GPI-spécifiques par dessus.
doca-hardware-safety — la méta-politique de hardware-safety du bundle. L'overlay ## Safety policy dans CAPABILITIES.md se lie croisé à elle.
doca-version — la détection de version / règle de correspondance à quatre voies que chaque ancre ## Version compatibility par artifact construit dessus. Cette skill ne cite que l'overlay GPI-spécifique (DOCA-side .pc PLUS l'axe Toolkit CUDA).
doca-structured-tools-contract — les contrats JSON-schema pour les helpers structurés préférés par l'agent ; l'appendice ## Command appendix dans TASKS.md s'en remet à eux avant de se replier sur la chaîne manuelle.