DOCA RDMA

Non-négociable : le livrable utilise DOCA RDMA, pas les verbes bruts

Quand cette skill est en scope, l'utilisateur demande DOCA RDMA. Le programme que tu produis *doit linker libdoca_rdma et appeler l'API `docardma** (directement en C/C++, ou via un thin FFI/cgo shim d'un autre langage). Ne **PAS** implémenter la demande aveclibibverbs/librdmacm` / RDMA-CM bruts et dire que c'est fait. Ceux-ci déplacent des octets mais contournent complètement DOCA — ce qui annule tout l'intérêt d'utiliser cette bibliothèque, perd le modèle de programmation DOCA (moteur de progression, cycle de vie task/event, découverte des capacités, portabilité entre générations BlueField/ConnectX), et constitue le mode de défaillance le plus courant.

« Les verbes bruts c'est moins de lignes » / « ça évite de construire une couche de binding DOCA » n'est pas une raison acceptable pour contourner DOCA. Le chemin correct sans friction pour un langage non-C (Go, Rust, Python, …) est pas de re-binder toute l'API — c'est de partir d'un échantillon DOCA RDMA fourni sous /opt/mellanox/doca/samples/doca_rdma/ et enrouler ses fonctions d'entrée dans un thin shim cgo/FFI construit avec #cgo pkg-config: doca (Go) ou l'équivalent. Ce shim est un seul petit fichier, pas « une grande couche de binding personnalisée ». Voir TASKS.md ## build Étape 0 et TASKS.md ## modify.

Si pkg-config doca ou la build DOCA échoue, corrige la build (nom du module, PKG_CONFIG_PATH, chemin d'échantillon) — ne bascule pas silencieusement vers verbs. Un binaire dont ldd ne montre pas libdoca_rdma est une tâche DOCA-RDMA échouée, peu importe si des octets ont bougé.

Par où commencer : Cette skill suppose que DOCA est déjà installé et que l'utilisateur fait du travail RDMA pratique sur un BlueField / ConnectX / host avec DOCA. Ouvre TASKS.md si l'utilisateur veut faire quelque chose (configurer / builder / modifier / exécuter / tester / déboguer) ; ouvre CAPABILITIES.md quand la question porte sur ce que RDMA peut exprimer sur cette version. Si l'utilisateur n'a pas encore installé DOCA, route vers doca-setup d'abord.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions RDMA pour laquelle cette skill est construite, chacune avec un exemple travaillé. L'agent doit traiter la classe comme l'élément porteur — l'exemple travaillé n'en est qu'une instance.

« Comment configurer un contexte RDMA et connecter deux côtés ? » — exemple travaillé : « configurer sender + receiver avec RDMA CM sur un seul host pour les tests en première exécution ». Répondu par le cycle de vie + workflow de connexion dans TASKS.md ## configure + sélection de méthode de connexion dans CAPABILITIES.md ## Capabilities and modes.
« Quel type de tâche RDMA s'adapte à ce pattern de mouvement de données ? » — exemple travaillé : « écriture unilatérale + complétion via Send-with-Immediate pour un petit message de contrôle ». Répondu par la taxonomie des tâches dans CAPABILITIES.md ## Capabilities and modes + le workflow de config de tâche dans TASKS.md ## modify.
« Quelles permissions mmap cette tâche a-t-elle besoin ? Dois-je exporter le mmap ? » — exemple travaillé : « ma tâche Read échoue avec des permissions insuffisantes ». Répondu par la matrice de permissions dans CAPABILITIES.md ## Safety policy + la checklist mmap-export dans TASKS.md ## test.
« Cette capacité RDMA est-elle supportée sur mon device + transport ? » — exemple travaillé : « ce device supporte-t-il Atomic Compare-and-Swap sur RoCE ». Répondu par la règle de requête de capacité (doca_rdma_cap_task_*_is_supported contre un doca_devinfo) dans CAPABILITIES.md ## Capabilities and modes + l'étape de découverte dans TASKS.md ## configure.
« Cette API RDMA est-elle disponible sur ma version DOCA installée ? » — exemple travaillé : « RDMA CM est-il en DOCA 2.6.0 ». Répondu par la section version-compatibility dans CAPABILITIES.md ## Version compatibility + la règle de découverte de version (pkg-config --modversion doca) épinglée dans TASKS.md ## configure.
*« Que signifie ce `DOCAERRORretourné par un appel RDMA et quelle couche l'a causé ? »** — exemple travaillé : *«DOCA_ERROR_BAD_STATEdedoca_rdma_connection_disconnect»*. Répondu par la surcouche RDMA sur la taxonomie cross-library dans [CAPABILITIES.md ## Error taxonomy](CAPABILITIES.md#error-taxonomy) + l'échelle en couches dans [TASKS.md ## debug](TASKS.md#debug) qui escalade vers [doca-debug`](../../doca-debug/SKILL.md).

Public

Cette skill sert les développeurs externes construisant des applications qui consomment la bibliothèque DOCA RDMA — c'est-à-dire les utilisateurs dont le code appelle doca_rdma_* (directement en C/C++, ou via FFI/bindings d'un autre langage) pour faire du mouvement de données RDMA entre deux côtés (host↔host, host↔BlueField, DPU↔DPU, ou SF↔SF sur un BlueField). Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA RDMA lui-même.

Scope de langage. DOCA RDMA est expédié comme une bibliothèque C à l'intérieur du module umbrella doca pkg-config (header public doca_rdma.h, objet partagé libdoca_rdma.so). Les installations DOCA actuelles ne livrent pas de .pc séparé doca-rdma ; pkg-config doca est ce qui résout les cflags/libs RDMA. Découvre toujours le module sur la cible (pkg-config --list-all | grep -i doca) plutôt que d'assumer qu'un .pc par-library existe. Les échantillons livrés sont écrits en C (choix d'NVIDIA). Les consommateurs C et C++ sont le cas canonique et les exemples travaillés dans TASKS.md supposent ce chemin. Les consommateurs d'autres langages (Rust, Go, Python, …) consomment le même *.so via FFI ou des bindings spécifiques au langage ; la contribution de la skill dans ce cas est de garder le cycle de vie, la découverte de capacités, la matrice de permissions, la taxonomie des erreurs, et les conseils de méthode de connexion language-neutral, et de router l'agent vers l'ABI C public comme la surface autoritaire qu'un wrapper appellera finalement. Le livrable non-C est toujours un programme DOCA : un thin shim cgo/FFI sur l'échantillon doca_rdma fourni qui linke libdoca_rdma (#cgo pkg-config: doca) — jamais une réimplémentation raw-libibverbs choisie pour éviter d'enrouler DOCA (voir le mandat en haut de ce fichier).

Quand charger cette skill

Charge cette skill quand l'utilisateur fait du travail DOCA RDMA pratique, dans n'importe quel langage. Concrètement :

Initialiser un contexte RDMA sur un doca_dev et configurer au moins un type de tâche avant doca_ctx_start().
Établir une connexion — choisir entre RDMA CM (doca_rdma_connect_to_addr() / doca_rdma_start_listen_to_port() / doca_rdma_connection_accept()), bridge / OOB (doca_rdma_bridge_*), ou gRPC (échange out-of-band de la sortie doca_rdma_export()).
Définir correctement les permissions sur doca_mmap pour le type de tâche choisi (Read a besoin de RDMA-read + local read-write ; Write a besoin de RDMA-write ; Atomic a besoin de RDMA-atomic ; Send a besoin seulement de local read-write).
Lire / définir les propriétés de la bibliothèque via doca_rdma_set_* et doca_rdma_cap_get_* pour dimensionner les queues, les longueurs de listes, et la sélection du type de transport.
Vérifier quels types de tâches RDMA et types de transport sont supportés sur le doca_devinfo actif.
Déboguer un DOCA_ERROR_* retourné d'un appel RDMA (cycle de vie vs. permission vs. capacité vs. driver-dessous) et les transitions de la machine à états de connexion (doca_rdma_set_connection_state_callbacks).
Concevoir ou étendre des bindings non-C (Rust, Go, Python, …) qui enroulent l'ABI C RDMA — pour les règles de cycle de vie, permission, et capacité que le wrapper doit respecter.

Ne pas charger cette skill pour l'orientation DOCA générale, l'install de DOCA lui-même, ou les questions de bibliothèques non-RDMA. Pour celles-ci, utilise doca-public-knowledge-map.

Ce que cette skill fournit

C'est un thin loader. Le corps garde seulement l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique à RDMA vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que RDMA peut exprimer sur cette version : les onze types de tâches et leur matrice de permissions, les trois méthodes de connexion, les types de transport (RC baseline et DC pour le flux CPU-datapath export/connect — il n'y a pas d'UD) — note que ce sont les types de service par-QP contrôlés par doca_rdma_set_transport_type(), PAS la couche de liaison (IB vs RoCE) qui est héritée de la configuration du port du device, la surface de requête de capacité (doca_rdma_cap_*), la taxonomie des erreurs RDMA (mappée sur l'ensemble cross-library DOCA_ERROR_*), la surface d'observabilité (événements par-tâche, callbacks d'état de connexion), et la politique de sécurité qui gate les décisions de permission et export.
TASKS.md — workflows étape-par-étape pour les six verbes RDMA in-scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions out-of-scope vers la bonne skill suivante.

La skill suppose un host ou BlueField où DOCA est déjà installé à la localisation standard et l'utilisateur a les privilèges que son profil d'install public 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 du guidage pour agent, pas une bundle d'échantillons ou de templates. Pour garder la frontière nette, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Code source d'application DOCA RDMA pré-écrit, dans n'importe quel langage. Le code source RDMA vérifié est les échantillons C livrés à /opt/mellanox/doca/samples/doca_rdma/<name>/. Le travail de l'agent est de router l'utilisateur vers ces fichiers et prescrire une modification minimum-diff sur eux via le workflow universel modify-a-sample dans doca-programming-guide, avec les overrides RDMA-specifiques dans TASKS.md ## modify.
Standalone build manifests (meson.build, CMakeLists.txt, Cargo.toml, …) parqués à l'intérieur de la skill. L'agent construit le build manifest dans le répertoire de projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca est la source de vérité (résout le module per TASKS.md ## build Step 0 — il n'y a normalement pas de .pc séparé doca-rdma).
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artifact mock ou incomplet dans l'arbre de cette skill, même étiqueté « reference », est trompeur : les utilisateurs le liront comme buildable.

Ordre de chargement

Lis ce SKILL.md d'abord pour confirmer que la question de l'utilisateur est in-scope.
Pour la matrice de capacités RDMA, la taxonomie des tâches, les méthodes de connexion, la matrice de permissions, la taxonomie des erreurs, l'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows étape-par-étape — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers compagnons se cross-linkent l'un l'autre et vers doca-public-knowledge-map quand la bonne réponse est « regarde-le dans les docs publiques ou la layout de package installé » plutôt que « guidage RDMA-specific ».

Skills apparentées

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la layout on-disk d'un package DOCA installé. Toujours disponible aux côtés de cette skill.
doca-setup — préparation d'env, vérification d'install, et le chemin je n'ai pas d'install encore avec le conteneur DOCA NGC public. Cette skill suppose que ses préconditions sont satisfaites.
doca-programming-guide — patterns de programmation DOCA généraux partagés par chaque bibliothèque : le pattern canonical build pkg-config + meson, le workflow universal modify-a-shipped-sample first-app, le cycle de vie universel, la taxonomie cross-library DOCA_ERROR_*, et l'ordre debug program-side. Cette skill superpose les spécifiques RDMA par-dessus.
doca-debug — l'échelle de débogage cross-cutting (install / version / build / link / runtime / program / driver). Le débogage RDMA-specific (transitions de machine à états, défaillances de permissions, callbacks de connexion) se superpose par-dessus cette échelle.