Initiateur DOCA RDMA

Par où commencer : Cette compétence suppose que DOCA est déjà installé et que l'utilisateur fait du travail pratique RDMI sur un hôte ou BlueField avec l'ensemble de paquets DOCA qui livre la librairie doca-rdmi. 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 concerne ce que RDMI peut exprimer sur cette version — le modèle d'objets, les types de handles côté DPA, la relation à doca-rdma, la politique du tag EXPERIMENTAL, et la couche de sécurité.

Les questions « walk me through doca-rdmi » de bout en bout sont répondables entièrement à partir de cette compétence. Allez directement à TASKS.md ## end-to-end (quickref), qui porte la démonstration auto-contenue install-check → découverte device/cap → sample → build pkg-config → run → debug avec les commandes exactes. Vous n'avez pas besoin d'ouvrir doca-setup ou doca-programming-guide pour répondre à une question de build/run/debug RDMI. Dirigez vers doca-setup seulement quand l'utilisateur n'a aucune installation DOCA du tout.

Exemples de questions auxquelles cette compétence répond bien

Les CLASSES de questions RDMI que cette compétence est conçue pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la classe comme la pièce maîtresse — l'exemple travaillé est une seule instance.

« Dois-je utiliser doca-rdmi ou doca-rdma pour ce cas ? » — exemple travaillé : « J'ai un kernel DPA qui doit faire des écritures RDMA de 1 MB vers un répondeur distant ; quelle librairie ? ». Répondu par la règle de sélection initiator-side vs general-purpose dans CAPABILITIES.md ## Capabilities and modes tableau de surface + le routage vers doca-rdma quand le cas d'usage est deux-sided ou lancé par le CPU hôte.
« Comment mettre en place une connexion RDMI sur le chemin de données DPA ? » — exemple travaillé : « créer un doca_rdmi_connection, attacher un contexte de completion DPA, passer le handle côté DPA à mon kernel ». Répondu par le cycle de vie de l'objet connexion dans CAPABILITIES.md ## Capabilities and modes
- la démonstration de configuration dans TASKS.md ## configure.
« Comment la connexion et le poster se rapportent-ils — quand ai-je besoin des deux ? » — exemple travaillé : « mon application reçoit des demandes de travail ET poste des écritures RDMA ; ai-je besoin d'un doca_rdmi_connection plus un doca_rdmi_poster, ou juste l'un d'eux ? ». Répondu par le modèle à deux objets dans CAPABILITIES.md ## Capabilities and modes
- le tableau d'emplacement modify-from-sample dans TASKS.md ## modify.
« Comment piloter les completions côté DPA ? » — exemple travaillé : « connecter la connexion à un doca_dpa_completion pour que mon kernel sonde directement les completions ». Répondu par le schéma d'attachement completion côté DPA dans CAPABILITIES.md ## Capabilities and modes
- le câblage côté run dans TASKS.md ## run, avec lien croisé vers doca-dpa pour la surface de programmation DPA elle-même.
« Le symbole que je veux est-il disponible — et est-il assez stable pour être livré ? » — exemple travaillé : « doca_rdmi_poster_post est-il GA sur mon DOCA installé, ou encore EXPERIMENTAL ? ». Répondu par la politique EXPERIMENTAL-tag dans CAPABILITIES.md ## Version compatibility
- la règle de découverte de version (pkg-config --modversion doca-rdmi) épinglée dans TASKS.md ## configure.
« Que signifie cette erreur DOCA_ERROR_* d'un appel doca_rdmi_* ? » — exemple travaillé : « DOCA_ERROR_BAD_STATE depuis doca_rdmi_connection_dpa_completion_attach ». Répondu par la couche RDMI sur la taxonomie inter-librairies dans CAPABILITIES.md ## Error taxonomy
- l'échelle stratifiée dans TASKS.md ## debug qui monte vers doca-debug.

Audience

Cette compétence sert les développeurs externes construisant des applications DOCA résidentes DPA / GPU qui ont besoin d'initier des opérations RDMA one-sided contre un répondeur distant — c'est-à-dire les utilisateurs dont le code côté accélérateur veut poster des sends, writes, ou reads directement depuis l'accélérateur sans passer par le CPU hôte. L'appelant canonique est un kernel DPA qui a été compilé avec doca-dpacc-compiler et s'exécute sur le chemin de données DPA BlueField ; un appelant côté GPU qui pilote les queues RDMA du DPU est le cas sœur couvert par doca-gpi. Cette compétence n'est pas pour les développeurs NVIDIA contribuant à DOCA RDMI lui-même, et ce n'est pas la bonne surface pour le RDMA two-sided général du CPU hôte — cela appartient à doca-rdma.

Portée du langage

DOCA RDMI est livré comme une librairie C avec le nom de module pkg-config doca-rdmi. La surface côté hôte de la librairie (doca_rdmi_connection_*, doca_rdmi_poster_*) est C ; la surface côté DPA que le kernel accélérateur utilise est aussi C, compilée contre la chaîne d'outils DOCA DPA documentée dans doca-dpa. Les consommateurs d'autres langages (Rust, Go, Python, …) consomment le *.so côté hôte via FFI ; la contribution de la compétence dans ce cas est de garder la connexion / cycle de vie du poster, la politique EXPERIMENTAL-tag, les règles de handoff côté DPA, et la couche de sécurité indépendantes du langage, et de router l'agent vers l'ABI C public comme la surface faisant autorité que tout wrapper appellera finalement. La surface côté DPA n'est pas encapsulable dans un autre langage — elle est compilée et liée dans le binaire DPA lui-même.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur fait du travail DOCA RDMI pratique sur un hôte ou BlueField avec DOCA installé. Concrètement :

Décider entre doca-rdmi et doca-rdma pour une nouvelle charge de travail one-sided RDMA qui s'exécute depuis le chemin de données DPA.
Créer un doca_rdmi_connection ou doca_rdmi_poster, attacher un doca_dpa_completion ou un doca_verbs_cq, et démarrer le contexte sur le chemin de données DPA.
Câbler le handle côté DPA retourné par doca_rdmi_connection_get_dpa_handle / doca_rdmi_poster_get_dpa_handle dans un kernel DPA qui appelle le header device-side correspondant (doca_rdmi_dev_connection.h, doca_rdmi_dev_poster.h, doca_rdmi_dev_cqe.h).
Acquitter les completions de réception côté hôte via doca_rdmi_connection_recv_ack après que le kernel DPA les ait consommés.
Auditer quels symboles RDMI sont EXPERIMENTAL sur la version DOCA installée, avant de déclarer un composant utilisant RDMI stable en production.
Déboguer un DOCA_ERROR_* retourné par un appel doca_rdmi_* et déterminer si la cause est une erreur de configuration, un bug d'ordre de cycle de vie, une capacité non supportée sur ce device, ou une couche sous DOCA.

Ne chargez pas cette compétence pour l'orientation générale DOCA, l'installation de DOCA lui-même, ou les questions RDMA two-sided du CPU hôte. Pour cela, utilisez doca-public-knowledge-map, doca-setup, et doca-rdma respectivement.

Ce que cette compétence fournit

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

CAPABILITIES.md — ce que RDMI peut exprimer sur cette version : le modèle d'objets doca_rdmi_connection et doca_rdmi_poster, le schéma d'attachement completion côté DPA, la relation à doca-verbs (RDMI s'appuie sur un doca_verbs_context) et à doca-dpa (le chemin de données accélérateur), la règle EXPERIMENTAL-tag pour la gestion des versions, la couche RDMI sur la taxonomie inter-librairies DOCA_ERROR_*, la surface d'observabilité (événements completion sur le PE / completions côté DPA), et la politique de sécurité qui gère le posting de travail depuis un kernel accélérateur dans la mémoire d'un répondeur distant.
TASKS.md — les flux de travail étape par étape pour les huit verbes en portée : install, configure, build, modify, run, test, debug, use. Plus une couche ## rollback (démantèlement RDMI-spécifique en cinq étapes pour les verbs / connexion / attachement DPA / pile MR) et l'instantiation de la boucle debug universelle à cinq phases ajoutée à ## debug. Plus un bloc Deferred task verbs qui pointe les questions hors portée vers la bonne compétence suivante.

La compétence suppose un hôte ou BlueField où DOCA est déjà installé à l'emplacement standard et l'utilisateur a les privilèges que son profil d'installation public attend. Elle ne couvre pas l'installation de DOCA lui-même — ce chemin passe par doca-setup.

Ce que cette compétence ne livre délibérément pas

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

Code source d'application DOCA RDMI pré-écrit, dans n'importe quel langage. Le rôle de l'agent est de router l'utilisateur vers le code de référence vérifié sur le DOCA installé de l'utilisateur et de prescrire une modification minimum-diff via le flux de travail universel modify-a-sample dans doca-programming-guide, stratifié avec les surcharges spécifiques à RDMI dans TASKS.md ## modify. Parce que chaque symbole RDMI est EXPERIMENTAL au moment de la rédaction, la compétence refuse de créer le code source RDMI à partir de prose de documentation — l'API peut changer entre les releases et le code résultant peut même ne pas compiler.
Manifestes de build autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) stationnés dans la compétence. L'agent construit le manifeste de build dans le répertoire du projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-rdmi est la source de vérité.
Templates de kernels côté DPA. La surface côté DPA est détenue par doca-dpa ; les headers RDMI côté DPA sont consommés par le modèle de programmation DPA documenté là. Cette compétence nomme le handoff spécifique à RDMI (le type de handle DPA, l'appel d'attachement completion) mais n'écrit pas de kernels DPA.
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artefact simulé ou incomplet dans l'arbre de cette compétence, même un é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 portée.
Pour le modèle d'objets RDMI, le schéma de handoff côté DPA, la politique EXPERIMENTAL-tag, la taxonomie d'erreurs, l'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
Pour les flux de travail étape par étape — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Les deux fichiers compagnons font un lien croisé l'un l'autre et vers doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez-le dans les docs publiques ou la disposition du paquet installé » plutôt que « guidance spécifique à RDMI ».

Compétences connexes

doca-rdma — la librairie RDMA de plus haut niveau couvrant le RDMA two-sided et lancé par le CPU hôte. RDMI est la surface initiator-side focalisée ; doca-rdma est la bonne réponse pour la majorité des cas d'usage RDMA. Le tableau de sélection dans CAPABILITIES.md ## Capabilities and modes est l'aide à la décision maîtresse.
doca-dpa — la surface de programmation DOCA DPA. RDMI retourne des handles côté DPA (doca_dpa_dev_rdmi_connection_t, doca_rdmi_dev_poster_t) que le kernel DPA utilise via les headers device-side (doca_rdmi_dev_connection.h, doca_rdmi_dev_poster.h, doca_rdmi_dev_cqe.h) ; la chaîne d'outils DPA, le build du kernel, et le modèle d'exécution sont détenus par cette compétence.
doca-gpi — la compétence sœur côté GPU de celle-ci. GPI est la surface channel/queue qu'un kernel CUDA utilise pour initier RDMA ; RDMI est la surface côté DPA. Les deux s'appuient sur le même substrat DOCA RDMA / verbs ; l'une ou l'autre peut s'appliquer selon que l'initiateur est sur le DPA ou sur le GPU.
doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un paquet DOCA installé.
doca-setup — préparation env, vérification d'installation, et le chemin je n'ai pas encore d'installation avec le conteneur DOCA NGC public.
doca-programming-guide — motifs de programmation DOCA généraux partagés par chaque librairie : le motif de build canonique pkg-config + meson, le flux de travail universel modify-a-shipped-sample first-app, le cycle de vie Core-context universel, la taxonomie inter-librairies DOCA_ERROR_*. Cette compétence stratifie les spécificités RDMI par-dessus.
doca-debug — l'échelle de debug transversale (install / version / build / link / runtime / program / driver). Les couches de debug spécifiques à RDMI par-dessus.
doca-hardware-safety — le meta-politique de sécurité matérielle au niveau du bundle. L'ancrage ## Safety policy dans CAPABILITIES.md l'utilise en lien croisé.
doca-version — la détection de version / la règle d'appariement à quatre voies que chaque ancrage ## Version compatibility par artefact construit dessus. Cette compétence cite seulement la couche spécifique à RDMI.
doca-structured-tools-contract — les contrats de schéma JSON pour les aides structurées préférées par l'agent (sonde env, snapshot de capacité, recherche de matrice de version) ; l'Appendix de commandes dans TASKS.md leur donne priorité avant de revenir à la chaîne manuelle.