DOCA DPA

Par où commencer : Ce skill suppose que DOCA est déjà installé, que le BlueField de l'utilisateur dispose d'un processeur DPA et que l'hôte peut le voir via DOCA, et que l'utilisateur effectue un travail DPA pratique depuis le côté hôte — c'est-à-dire en utilisant doca-dpa pour charger une image d'application DPA, lancer des kernels DPA et échanger des données avec le processeur DPA. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur ce que l'API DPA côté hôte peut exprimer sur cette version + cette génération de BlueField. Si l'utilisateur n'a pas encore installé DOCA, routez vers doca-setup d'abord ; si l'utilisateur demande comment écrire le kernel côté DPA lui-même (le code qui s'exécute sur le processeur DPA, compilé par dpacc), c'est un périmètre différent — routez via doca-public-knowledge-map vers les guides publics DOCA DPA / DPACC / DPA-Comms / DPA-Verbs (ce skill ne redéfinit pas ces surfaces côté DPA).

Exemples de questions que ce skill répond bien

Les CLASSES de questions DPA que ce skill est conçu pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la classe comme la partie essentielle — l'exemple travaillé est une seule instance.

« Comment exécuter un calcul sur le processeur DPA depuis mon programme hôte ? » — exemple travaillé : « charger un kernel DPA qui compte les événements dans une boucle et rapporte le nombre à l'hôte ». Répondu par le modèle de programme à deux côtés + le workflow de lancement côté hôte dans CAPABILITIES.md ## Capabilities and modes + les étapes de mise en service dans TASKS.md ## configure.
« Est-ce que ce BlueField a même un DPA, et quelles fonctionnalités DPA mon installation DOCA expose-t-elle ? » — exemple travaillé : « mon hôte a un BlueField ; puis-je utiliser le DPA pour une charge de travail de contrôle programmable ? ». Répondu par la règle de capacité à deux axes (axe génération BlueField via doca_dpa_cap_* contre le doca_devinfo actif plus l'axe installation DOCA via pkg-config --modversion doca-dpa) dans CAPABILITIES.md ## Capabilities and modes + l'étape d'énumération des appareils dans TASKS.md ## configure.
« Pourquoi ma configuration DPA côté hôte échoue-t-elle avec DOCA_ERROR_NOT_SUPPORTED bien que DOCA Core semble sain ? » — exemple travaillé : « la génération BlueField sur cet hôte est antérieure à la fonctionnalité DPA que mon code utilise ». Répondu par la matrice des préconditions d'environnement dans CAPABILITIES.md ## Safety policy + la liste de vérification d'environnement dans TASKS.md ## configure étape 1.
« Comment passer des arguments et des résultats entre mon programme hôte et mon kernel DPA ? » — exemple travaillé : « transmettre un pointeur de buffer et une longueur au kernel DPA en tant qu'arguments de lancement ; lire un achèvement quand le kernel se termine ». Répondu par la superposition argument de lancement + achèvement dans CAPABILITIES.md ## Capabilities and modes + les étapes de lancement + drainage dans TASKS.md ## run.
« L'API DPA côté hôte que je lis est-elle disponible sur mon DOCA installé ? » — exemple travaillé : « l'assistant de lancement côté hôte que je vois dans les docs est-il disponible pour les versions DOCA + DPACC sur cet hôte ? ». Répondu par la superposition de compatibilité des versions dans CAPABILITIES.md ## Version compatibility qui relie la chaîne de détection canonique dans doca-version et ajoute la superposition DPA-spécifique DOCA doit correspondre à DPACC.
« Qu'est-ce que ce DOCA_ERROR_* d'un appel doca_dpa_* signifie et quelle couche l'a provoqué ? » — exemple travaillé : « DOCA_ERROR_DRIVER sur un appel de lancement côté hôte — est-ce DOCA, l'image produite par DPACC, ou le processeur DPA lui-même ? ». Répondu par la superposition DPA sur la taxonomie entre bibliothèques dans CAPABILITIES.md ## Error taxonomy + l'échelle en couches dans TASKS.md ## debug qui remonte à doca-debug.
« Comment mon kernel DPA envoie-t-il un petit message à un autre thread DPA sur le même processeur DPA ? » — exemple travaillé : « deux threads DPA dans la même doca_dpa_app chargée ; le thread A envoie une valeur de compteur au thread B sur un endpoint de comms côté DPA et le thread B signale l'hôte via doca_dpa_completion ». Répondu par la règle de routage DPA-Comms, les familles de primitives, la règle de budget de capacité côté hôte et la superposition d'erreur DPA-Comms dans CAPABILITIES.md ## comms plus la superposition configure / build / modify / run / test / debug dans TASKS.md ## comms. Désambiguïse le composant de comms côté appareil DPA du doca-comch côté hôte et du doca-rdma côté hôte.
« Comment faire du RDMA directement depuis mon kernel DPA vers un pair distant, sans aller-retour à l'hôte ? » — exemple travaillé : « mon kernel DPA doit aller chercher le buffer d'entrée de 4 KiB suivant depuis un nœud distant via lecture RDMA avant de continuer le calcul ; l'aller-retour hôte est le goulot d'étranglement mesuré ». Répondu par la matrice RDMA à 4 voies, la règle de couplage hôte-configure-QP / DPA-utilise-QP, la règle de requête de cap côté hôte pour le verbe spécifique et la superposition d'erreur DPA-Verbs dans CAPABILITIES.md ## verbs plus la superposition de workflow dans TASKS.md ## verbs. Inclut la règle de remontée pour quand la prémisse de réglage de latence cesse de tenir.

Public

Ce skill sert les développeurs externes qui construisent des applications qui consomment la bibliothèque DOCA DPA depuis le côté hôte — c'est-à-dire les utilisateurs dont le code appelle doca_dpa_* depuis le C/C++ hôte pour établir le contexte par instance DPA, charger une image d'application DPA que dpacc a produite à partir de leur source côté DPA, créer un ou plusieurs threads DPA, lancer des kernels DPA avec des arguments et drainer les complétions. Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA DPA lui-même, ni c'est l'endroit pour apprendre comment écrire le code kernel côté DPA (ce chemin passe par les guides publics DOCA DPA, DPACC, DPA-Comms et DPA-Verbs via doca-public-knowledge-map).

Portée linguistique. DOCA DPA est fourni en tant que bibliothèque C côté hôte avec le nom de module pkg-config doca-dpa. L'API côté hôte est en C ; le kernel côté DPA est une unité de traduction séparée écrite dans le langage que le compilateur DPACC accepte et compilée par dpacc en un binaire que l'hôte empaquète dans l'exécutable en tant qu'image d'application DPA. Les échantillons fournis sous /opt/mellanox/doca/samples/doca_dpa/ sont écrits en C plus source côté DPA (choix d'NVIDIA). Les consommateurs d'autres langages sont limités en pratique — le kernel côté DPA n'a pas d'échappatoire FFI car il doit être une unité de traduction que dpacc accepte — mais un wrapper côté hôte Rust / Go / Python qui pilote les appels doca_dpa_* de configuration et lance une image kernel DPA construite séparément reste utile, et le skill maintient la guidance de cycle de vie, découverte de capacité, précondition d'environnement et taxonomie d'erreur indépendante du langage.

Quand charger ce skill

Chargez ce skill quand l'utilisateur effectue un travail DOCA DPA pratique depuis le côté hôte, dans n'importe quel langage hôte plus une unité de traduction côté DPA construite par dpacc. Concrètement :

Initialisation d'un doca_dpa contre un doca_dev qui correspond à un BlueField avec un processeur DPA visible à l'hôte.
Chargement d'une image d'application DPA (doca_dpa_app) que dpacc a produite à partir de la source côté DPA de l'utilisateur, dans le contexte doca_dpa.
Création d'un ou plusieurs contextes d'exécution DPA (doca_dpa_thread) pour que les kernels DPA aient un endroit où s'exécuter sur le processeur DPA.
Lancement d'une fonction kernel DPA avec des arguments depuis l'hôte via la famille doca_dpa_kernel_launch_update_*, et raisonnement sur quelle forme d'argument est supportée sur cette installation.
Attachement d'un doca_dpa_completion pour observer quand le travail DPA asynchrone se termine, et drainage depuis le côté hôte.
Vérification des fonctionnalités DPA supportées sur le doca_devinfo actif via la famille doca_dpa_cap_* — les générations BlueField diffèrent dans le support matériel DPA.
Débogage d'un DOCA_ERROR_* renvoyé par un appel doca_dpa_* — en particulier disambiguïsation de DPA absent sur ce BlueField de fonctionnalité DPA trop nouvelle pour cette génération matérielle de image produite par DPACC mal assortie à l'installation DOCA côté hôte de couche de pilote DPA rapportant une défaillance.
Conception de bindings côté hôte dans un langage non-C qui pilotent une image d'application DPA qu'ils ont construite séparément avec dpacc — les règles de précondition d'environnement et découverte de capacité dans ce skill s'appliquent toujours.
Écriture de code kernel côté DPA qui appelle le composant de comms côté appareil DPA libdoca_dpa_dev_comm.a (en-tête doca_dpa_dev_comch_msgq.h) — pour la messagerie entre threads DPA ou les signaux de coordination entre threads DPA sur la même doca_dpa_app. La règle de routage DPA-Comms, les familles de primitives, la règle de capacité (il n'y a pas de famille de requête de cap par primitive côté hôte — la découverte DPA côté hôte est seulement doca_dpa_cap_is_supported / doca_dpa_cap_get_max_kernel_time_alive_supported), la superposition d'erreur (_AGAIN → le kernel doit être cédé ; désambiguïsation _BAD_STATE de la _BAD_STATE côté hôte du parent) et la superposition configure / build / modify / run / test / debug vivent dans CAPABILITIES.md ## comms et TASKS.md ## comms sous ce même skill.
Écriture de code kernel côté DPA qui appelle le composant de verbs côté appareil DPA libdoca_dpa_dev_verbs.a (en-tête doca_dpa_dev_verbs.h) — pour le RDMA depuis l'intérieur du kernel DPA vers un pair distant quand l'aller-retour hôte est le goulot d'étranglement de latence mesuré. La matrice RDMA à 4 voies, la règle de couplage hôte-configure-QP / DPA-utilise-QP, la règle de capacité (aucune famille de requête de cap par verbe côté hôte n'existe ; la disponibilité du verbe suit la génération BlueField + l'installation DOCA/DPACC appairée, lire depuis doca_dpa_dev_verbs.h et l'échantillon fourni), la superposition IO_FAILED → inspection CQE et la règle de remontée vivent dans CAPABILITIES.md ## verbs et TASKS.md ## verbs sous ce même skill.

Ne chargez pas ce skill pour l'orientation DOCA générale, l'installation de DOCA ou du compilateur DPACC, le modèle de programmation côté DPA lui-même (comment écrire un kernel DPA ; les composants de comms et verbs côté appareil DPA (libdoca_dpa_dev_comm.a / libdoca_dpa_dev_verbs.a) qui s'exécutent à l'intérieur du kernel DPA) ou les questions de bibliothèque non-DPA. Pour ces cas, routez via doca-public-knowledge-map vers le guide approprié en amont.

Ce que ce skill fournit

C'est un chargeur léger. Le corps garde seulement l'orientation nécessaire pour choisir le bon fichier suivant. La matière DPA-spécifique substantielle vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que l'API DPA côté hôte peut exprimer sur cette version + cette génération BlueField : le contexte par instance doca_dpa, l'image chargée doca_dpa_app produite par dpacc, le contexte d'exécution doca_dpa_thread, la surface de lancement de kernel initiée par l'hôte (doca_dpa_kernel_launch_update_*), le mécanisme doca_dpa_completion, la surface de requête de capacité (doca_dpa_cap_*), la taxonomie d'erreur DPA mappée sur l'ensemble DOCA_ERROR_* entre bibliothèques, la surface d'observabilité (complétions côté hôte plus la surface d'outils de développeur public DPA accessible via doca-public-knowledge-map), et la politique de sécurité qui contrôle les préconditions d'environnement (BlueField capable DPA, versions DOCA + DPACC appairées, l'image côté DPA et les points d'entrée attendus côté hôte concordent).
TASKS.md — workflows pas à pas pour les six verbes DPA en périmètre : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors périmètre vers le skill suivant approprié.

Le skill suppose un hôte où DOCA est déjà installé à l'emplacement standard, un BlueField avec un processeur DPA physiquement présent et visible à l'hôte, le compilateur DPACC installé à une version correspondant à l'installation DOCA selon la Politique de Compatibilité DOCA, et l'utilisateur sait déjà comment (au moins au niveau sketch) écrire le kernel côté DPA que dpacc compilera. Il ne couvre pas l'installation de DOCA ou du compilateur DPACC — ce chemin passe par doca-setup.

Ce que ce skill volontairement ne livre pas

Ce skill est une guidance d'agent, pas un bundle d'échantillons ou de templates. Pour garder la frontière nette, il ne contient volontairement pas — et les pull requests ne doivent pas ajouter :

Code source d'application DOCA DPA préécrit ou code kernel côté DPA, dans n'importe quel langage. La source DPA vérifiée est les échantillons C + côté DPA fournis à /opt/mellanox/doca/samples/doca_dpa/. Le travail de l'agent est de router l'utilisateur vers ces fichiers et prescrire une modification à différence minimale sur eux via le workflow universel modify-a-sample dans doca-programming-guide, en couches avec les surcouches DPA-spécifiques dans TASKS.md ## modify.
Manifestes de build autonomes (meson.build, CMakeLists.txt, …) stationnés à l'intérieur du skill. L'agent construit le manifeste de build dans le répertoire de projet de l'utilisateur contre le DOCA + compilateur DPACC installés de l'utilisateur, où pkg-config --modversion doca-dpa et le dpacc installé sont les deux sources de vérité.
Un sous-arbre samples/, bindings/ ou reference/ de n'importe quel type. Un artefact simulé ou incomplet dans l'arbre de ce skill, même étiqueté « reference », est trompeur : les utilisateurs le liront comme compilable.
Contenu côté appareil DPA pour les composants de comms / verbs (libdoca_dpa_dev_comm.a / libdoca_dpa_dev_verbs.a). Ce sont des archives côté DPA fournies dans le cadre de doca-dpa (PAS des modules pkg-config séparés) : leurs symboles sont appelés depuis l'intérieur du kernel DPA et liés à l'image DPA par dpacc, pas depuis l'hôte. Leurs guides publics sont accessibles via doca-public-knowledge-map. Ce skill les nomme et route ; il ne les redéfinit pas.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en périmètre (travail DPA côté hôte, pas écriture de kernel côté DPA).
Pour la matrice de capacité DPA, le contexte par instance doca_dpa, l'image chargée doca_dpa_app, le contexte d'exécution doca_dpa_thread, le modèle de lancement de kernel + achèvement, la requête de capacité duale, la politique de précondition d'environnement, la taxonomie d'erreur, la surface d'observabilité et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows pas à pas — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers compagnons se relient entre eux, à doca-version pour les règles canoniques de gestion des versions DOCA (avec la surcouche DPA que DOCA doit correspondre au compilateur DPACC) et à doca-public-knowledge-map chaque fois que la bonne réponse est « regardez dans le guide public DOCA DPA, DPACC, DPA-Comms ou DPA-Verbs, ou dans la mise en page d'installation sur disque » plutôt que « guidance DPA spécifique côté hôte ».

Skills connexes

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la mise en page sur disque d'un paquet DOCA installé. Le guide public DPA est sur https://docs.nvidia.com/doca/sdk/DOCA-DPA/index.html ; le guide du compilateur DPACC, le guide DPA-Comms (communications côté DPA), le guide DPA-Verbs (verbs côté DPA) et le parapluie DPA Tools (CLIs de développeur / administrateur pour DPA) vivent dans la même table de routage et sont des surfaces compagnon à ce skill plutôt que redéfinies par lui.
doca-setup — préparation d'environnement, vérification d'installation, installation / vérification du compilateur DPACC et le chemin je n'ai pas encore d'installation avec le conteneur DOCA NGC public. Ce skill suppose que ses préconditions sont satisfaites ET que DPACC est installé à une version qui correspond à DOCA.
doca-version — règles canoniques de gestion des versions DOCA. La ## Version compatibility de ce skill relie la règle d'appairage à quatre voies et ajoute la surcouche DPA-spécifique DOCA-et-DPACC doivent correspondre selon la Politique de Compatibilité DOCA.
doca-structured-tools-contract — la règle de priorité des outils structurés du bundle (détecter / préférer / repli / rapporter). L'appendice Commande 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 build meson + pkg-config canonique, le workflow first-app universel modify-a-shipped-sample, le cycle de vie du contexte Core universel, la taxonomie DOCA_ERROR_* entre bibliothèques et l'ordre de debug côté programme. Ce skill superpose les spécificités DPA par-dessus.
doca-debug — l'échelle de debug entre coupes (install / version / build / link / runtime / programme / pilote). Le debug DPA-spécifique (skew DPACC + DOCA version, DPA absent sur cette génération BlueField, kernels DPA qui restent bloqués sans achèvement côté hôte, incompatibilités de forme d'argument de lancement entre l'appel de lancement côté hôte et la signature de fonction côté DPA) se superpose par-dessus cette échelle.

Les composants côté appareil DPA du DOCA DPA — l'archive de comms libdoca_dpa_dev_comm.a (primitives de communication que le kernel DPA lui-même appelle, en-tête doca_dpa_dev_comch_msgq.h) et l'archive de verbs libdoca_dpa_dev_verbs.a (verbs RDMA de type ibverbs que le kernel DPA lui-même appelle, en-tête doca_dpa_dev_verbs.h) — sont des archives côté DPA livrées au sein de doca-dpa, pas des modules pkg-config séparés, et chacune a son propre guide public. Aucune skill de bibliothèque n'est livrée pour elles dans ce bundle encore ; pour toute question côté DPA, routez via doca-public-knowledge-map vers les guides publics DOCA DPA Comms et DOCA DPA Verbs et vers les échantillons fournis /opt/mellanox/doca/samples/doca_dpa/ (qui incluent les deux unités de traduction côté hôte et côté DPA). Les confluer avec doca-dpa est l'erreur de conception d'application first-app DPA la plus courante.