DOCA GPUNetIO

Par où commencer : Cette skill suppose que DOCA est déjà installé, que le toolkit CUDA est installé et correspond à l'installation DOCA, et que l'utilisateur effectue un travail pratique avec GPUNetIO — c'est-à-dire câbler une queue réseau DOCA dans un kernel CUDA sur un GPU NVIDIA. Ouvrez TASKS.md si l'utilisateur souhaite faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur ce que GPUNetIO peut exprimer sur cette version + ce GPU. Si l'utilisateur n'a pas encore installé DOCA, routez vers doca-setup en premier ; si l'utilisateur n'a pas encore configuré les queues RX/TX Ethernet sous-jacentes, c'est une question DOCA Ethernet (aucune skill de bibliothèque n'en est expédiée pour l'instant dans ce bundle — routez via doca-public-knowledge-map vers le guide public DOCA Ethernet).

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions GPUNetIO que cette skill est construite pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la classe comme l'élément porteur — l'exemple travaillé est une seule instance.

« Comment faire en sorte qu'un kernel CUDA reçoive directement des paquets de la NIC ? » — exemple travaillé : « un kernel persistant sur un GPU lit les paquets d'une doca_gpu_eth_rxq construite sur un doca_eth_rxq representor et les compte par flot ». Réponse fournie par le pattern du kernel persistant dans CAPABILITIES.md ## Capabilities and modes
- le workflow de démarrage côté GPU dans TASKS.md ## configure.
« Puis-je exécuter GPUNetIO sur ce GPU ? » — exemple travaillé : « mon hôte possède une carte Ampere et une carte Turing ; laquelle supporte la mise en réseau initiée par le GPU ? ». Réponse fournie par la règle de double découverte de capacités (DOCA cap-query ET cudaGetDeviceProperties contre l'ordinal du device CUDA) dans CAPABILITIES.md ## Capabilities and modes
- l'étape d'énumération des devices dans TASKS.md ## configure.
« Pourquoi ma configuration GPUNetIO échoue-t-elle avec DOCA_ERROR_NOT_SUPPORTED alors que doca-eth a démarré correctement ? » — exemple travaillé : « nvidia_peermem n'est pas chargé donc GPUDirect RDMA est indisponible ». Réponse fournie par les préconditions env dans CAPABILITIES.md ## Safety policy
- la checklist env dans TASKS.md ## configure étape 1.
« Comment déplacer des données entre les buffers alloués par CUDA et une queue DOCA ? » — exemple travaillé : « utiliser cudaMalloc pour le pool de buffers de réception et l'enregistrer avec DOCA via `doca_buf_arrcreate avant de démarrer le contexte »*. Réponse fournie par l'overlay allocateur-CUDA + enregistrement-DOCA dans [CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)
- l'étape de préparation du buffer dans TASKS.md ## configure étape 4.
« L'API GPUNetIO que je lis existe-t-elle dans ma combinaison DOCA + CUDA installée ? » — exemple travaillé : « l'helper du kernel persistant est-il disponible avec la version du toolkit CUDA que j'ai ? ». Réponse fournie par l'overlay de compatibilité des versions dans CAPABILITIES.md ## Version compatibility qui croise-relie la chaîne de détection canonique dans doca-version et ajoute l'overlay GPUNetIO-spécifique DOCA doit correspondre à CUDA.
*« Que signifie ce `DOCAERRORd'un appel GPUNetIO et quelle couche l'a provoqué ? »** — exemple travaillé : *«DOCA_ERROR_DRIVER surdocagpu_create` — est-ce DOCA, CUDA, ou la queue doca-eth sous-jacente ? ». Réponse fournie par l'overlay GPUNetIO sur la taxonomie inter-bibliothèques dans CAPABILITIES.md ## Error taxonomy
- l'échelle en couches dans TASKS.md ## debug qui escalade vers doca-debug.

Audience

Cette skill sert les développeurs externes construisant des applications qui consomment la bibliothèque DOCA GPUNetIO — c'est-à-dire les utilisateurs dont le code appelle doca_gpu_* depuis du C/C++ côté hôte pour mettre en place le contexte par-GPU et les handles de queue visibles par le GPU, et dont le kernel CUDA (unité de traduction .cu) utilise ces handles depuis du code device pour soumettre / recevoir des paquets. La forme cible canonique est l'application de référence GPU Packet Processing : un kernel CUDA persistant sur un GPU NVIDIA qui scrute une queue RX visible par le GPU et traite les paquets sur place sur le GPU. Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA GPUNetIO lui-même.

Portée du langage. DOCA GPUNetIO est expédié en tant que bibliothèque C / CUDA avec nom de module pkg-config doca-gpunetio. L'API côté hôte est C ; l'API côté device est CUDA C++ utilisé à l'intérieur d'un kernel .cu. Les samples expédiés et l'application de référence GPU Packet Processing sont écrits en C + CUDA C++ (choix d'NVIDIA). Les consommateurs dans d'autres langages sont limités en pratique — l'API côté device n'a aucune échappatoire FFI parce que le kernel doit être une unité de traduction CUDA — mais une enveloppe côté hôte en Rust / Go / Python qui pilote la configuration côté hôte doca_gpu_* et lance un kernel CUDA construit séparément reste utile, et la skill conserve les conseils sur le cycle de vie, la découverte de capacités, les préconditions env, et la taxonomie des erreurs dans une langue agnostique.

Quand charger cette skill

Chargez cette skill quand l'utilisateur effectue un travail pratique avec DOCA GPUNetIO, dans n'importe quel langage d'hôte plus CUDA. Concrètement :

Initialiser un doca_gpu pour un ordinal de device CUDA spécifique sur un hôte avec un ou plusieurs GPUs NVIDIA.
Créer un handle de queue visible par le GPU (doca_gpu_eth_rxq, doca_gpu_eth_txq) sur un doca_eth_rxq / doca_eth_txq existant de DOCA Ethernet, et passer le handle dans un kernel CUDA pour utilisation côté device.
Écrire ou modifier le kernel CUDA persistant qui vide la queue RX visible par le GPU dans une boucle de longue durée (la forme canonique GPU Packet Processing).
Allouer des buffers GPU via cudaMalloc et les enregistrer avec DOCA via la famille doca_buf_arr_create_* avant doca_ctx_start().
Vérifier quelles fonctionnalités GPUNetIO sont supportées sur le doca_devinfo actif (famille DOCA cap-query) ET sur le device CUDA candidat (cudaGetDeviceProperties et vérifications de version du driver CUDA).
Déboguer un DOCA_ERROR_* retourné par un appel GPUNetIO — en particulier en désambiguïsant capacité DOCA manquante de device CUDA trop ancien de nvidia_peermem pas chargé de biais de version entre driver CUDA + DOCA.
Concevoir des bindings côté hôte pour les langages non-C qui pilotent un kernel CUDA qu'ils ont construit séparément — les règles de préconditions env et de découverte de capacités dans cette skill s'appliquent toujours.

Ne chargez pas cette skill pour une orientation DOCA générale, l'installation de DOCA ou du toolkit CUDA, la configuration de la queue DOCA Ethernet sous-jacente, ou les questions de bibliothèque non-GPUNetIO. Pour celles-ci, routez via doca-public-knowledge-map vers le guide amont correspondant.

Ce que cette skill fournit

Ceci est un chargeur mince. Le corps conserve seulement l'orientation nécessaire pour choisir le bon fichier suivant. La matière substantielle spécifique à GPUNetIO vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que GPUNetIO peut exprimer sur cette version
- ce GPU : le contexte doca_gpu par-device, les handles de queue RX / TX visibles par le GPU en couches sur doca-eth, le pattern du kernel CUDA persistant comme forme d'utilisation par défaut, la surface de requête de capacité (les familles doca_eth_rxq_cap_is_type_supported / doca_eth_rxq_cap_get_* doca-eth dans doca_eth_rxq.h, plus la famille doca_eth_txq_cap_* correspondante, côté DOCA, plus cudaGetDeviceProperties côté CUDA), la taxonomie des erreurs GPUNetIO mappée sur l'ensemble inter-bibliothèques DOCA_ERROR_*, la surface d'observabilité (compteurs côté CUDA + achèvement par-task côté DOCA), et la politique de sécurité qui contrôle les préconditions env (correspondance des versions CUDA + DOCA, nvidia_peermem, enregistrement des buffers CUDA).
TASKS.md — workflows étape par étape pour les six verbes GPUNetIO en scope : configure, build, modify, run, test, debug. Plus un overlay ## rollback (démantèlement spécifique à GPUNetIO en cinq étapes qui signale au kernel persistant de drainer, désenregistre les buffers GPU dans l'ordre inverse d'enregistrement, et laisse la queue doca-eth parente intacte) et l'instanciation de la boucle debug universelle en cinq phases ajoutée à ## debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la prochaine skill appropriée.

La skill suppose un hôte où DOCA est déjà installé au lieu standard, un GPU NVIDIA est physiquement présent, le toolkit CUDA est installé et sa version correspond à l'installation DOCA selon la Politique de Compatibilité DOCA, et les queues RX/TX DOCA Ethernet sous-jacentes sont déjà configurées (cette skill se situe au-dessus de doca-eth, pas en dessous). Elle ne couvre pas l'installation de DOCA ou du toolkit CUDA — ce chemin passe par doca-setup.

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

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

Code source d'application DOCA GPUNetIO pré-écrit ou code de kernel CUDA, dans aucun langage. La source GPUNetIO vérifiée est les samples C + CUDA expédiés à /opt/mellanox/doca/samples/doca_gpunetio/ et l'application de référence GPU Packet Processing. Le rôle de l'agent est de router l'utilisateur vers ces fichiers et prescrire une modification avec diff minimal sur eux via le workflow universel modify-a-sample dans doca-programming-guide, superposé avec les overrides spécifiques à GPUNetIO dans TASKS.md ## modify.
Manifestes de compilation autonomes (meson.build, CMakeLists.txt, …) garés à l'intérieur de la skill. L'agent construit le manifeste de compilation dans le répertoire projet de l'utilisateur contre le DOCA + toolkit CUDA installés de l'utilisateur, où pkg-config --modversion doca-gpunetio et nvcc --version sont les deux sources de vérité.
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artefact simulé ou incomplet dans l'arborescence 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 en scope.
Pour la matrice de capacité GPUNetIO, le contexte per-device doca_gpu, le pattern du kernel persistant, la double requête de capacité, la politique de précondition env, la taxonomie des erreurs, la surface d'observabilité, et la politique de sécurité, consultez CAPABILITIES.md.
Pour les workflows étape par étape — configure, build, modify, run, test, debug — consultez TASKS.md.

Les deux fichiers compagnons se croisent-relient mutuellement, doca-version pour les règles canoniques de gestion des versions DOCA (avec l'overlay GPUNetIO que DOCA doit correspondre à CUDA), et doca-public-knowledge-map chaque fois que la bonne réponse est « regardez-le dans le guide public DOCA GPUNetIO, la Politique de Compatibilité DOCA, la documentation du toolkit CUDA, ou l'agencement d'installation sur le disque » plutôt que « guidance spécifique à GPUNetIO ».

Skills connexes

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et l'agencement sur disque d'un package DOCA installé. Le guide public GPUNetIO se trouve à https://docs.nvidia.com/doca/sdk/DOCA-GPUNetIO/index.html ; l'application de référence GPU Packet Processing y est accessible. Les liens de la Politique de Compatibilité CUDA toolkit et DOCA se trouvent dans la même table de routage.
doca-setup — préparation env, vérification d'installation, installation / vérification du toolkit CUDA, et le chemin je n'ai pas encore d'installation avec le container DOCA public NGC. Cette skill suppose que ses préconditions sont satisfaites ET que CUDA est installé à une version qui correspond à DOCA.
doca-version — règles canoniques de gestion des versions DOCA. La section ## Version compatibility de cette skill croise-relie la règle de correspondance quatre-voies et ajoute l'overlay spécifique à GPUNetIO DOCA-et-CUDA doivent correspondre selon la Politique de Compatibilité DOCA.
doca-structured-tools-contract — la règle de précédence des structured-tools du bundle (détecter / préférer / basculer / rapporter). L'annexe Command dans TASKS.md honore ce contrat.
doca-programming-guide — patterns de programmation DOCA généraux partagés par chaque bibliothèque : le pattern de compilation meson + pkg-config canonique, le workflow universel modify-a-shipped-sample première-app, le cycle de vie universel, la taxonomie inter-bibliothèques DOCA_ERROR_*, et l'ordre de debug côté programme. Cette skill superpose les spécificités GPUNetIO par-dessus.
doca-debug — l'échelle de debug transversale (install / version / build / link / runtime / program / driver). Le debug spécifique à GPUNetIO (biais de version CUDA + DOCA, nvidia_peermem manquant, hangs silencieux du kernel persistant, dépareillages entre allocateur CUDA + enregistrement DOCA) se superpose par-dessus cette échelle.

DOCA Ethernet est la bibliothèque compagnon obligatoire de GPUNetIO : les handles de queue RX / TX visibles par le GPU sont en couches au-dessus de doca_eth_rxq / doca_eth_txq de DOCA Ethernet. Aucune skill libs/doca-eth/ n'est expédiée dans ce bundle pour l'instant ; pour la configuration de queue Ethernet sous-jacente, routez via doca-public-knowledge-map vers le guide public DOCA Ethernet et vers les samples expédiés /opt/mellanox/doca/samples/doca_eth/.