Fournisseur DPA de DOCA Flow

Par où commencer : Cette skill suppose que DOCA est déjà installé, que l'utilisateur dispose d'un BlueField avec un processeur DPA visible par l'hôte via DOCA, que l'utilisateur programme déjà DOCA Flow depuis l'hôte (doca-flow) et exécute déjà les kernels DPA depuis l'hôte (doca-dpa / compilateur DPACC), et que l'utilisateur fait du travail pratique de fournisseur DPA Flow — c'est-à-dire utilise doca-flow-dpa-provider pour exporter un pipe DOCA Flow existant ou une ressource externe dans l'espace d'adressage DPA afin qu'un kernel DPA puisse la manipuler en ligne. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question est que peut exprimer le fournisseur sur cette version + cette génération de BlueField. Si l'utilisateur n'a pas encore installé DOCA, orientez-le vers doca-setup d'abord ; s'il n'a pas encore mis en place un pipe Flow côté hôte, orientez-le vers doca-flow d'abord ; s'il n'a pas encore mis en place l'exécution DPA côté hôte, orientez-le vers doca-dpa d'abord.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions sur le fournisseur DPA Flow auxquelles cette skill est construite pour répondre, chacune avec un exemple traité. L'agent doit traiter la classe comme l'élément porteur — l'exemple traité est une seule instance.

« Cette bibliothèque est-elle le bon outil pour ce que je veux ? » — exemple traité : « Je veux que mon pipe DOCA Flow soit lisible depuis un kernel DPA, OU je veux faire quelque chose de plus sophistiqué que ce que l'API doca-flow côté hôte expose ». Réponse fournie par la règle de décision dans CAPABILITIES.md ## Capabilities and modes (« modèle à trois programmes : quand cette bibliothèque est la bonne surface par rapport au Flow pur côté hôte par rapport au DPA pur »). La plupart des premiers demandeurs n'ont PAS besoin de cette bibliothèque ; le premier travail de la skill est de confirmer qu'ils en ont besoin.
« Comment exporter un pipe DOCA Flow existant vers le côté DPA ? » — exemple traité : « J'ai un pipe Flow avec un compteur sur chaque entrée ; je veux qu'un kernel DPA lise ces compteurs en ligne et décide ce qu'il faut faire ensuite ». Réponse fournie par la séquence d'export côté hôte dans CAPABILITIES.md ## Capabilities and modes + les étapes de mise en place dans TASKS.md ## configure.
« Comment piloter le pipe exporté depuis l'intérieur du kernel DPA ? » — exemple traité : « J'ai l'adresse de périphérique d'un pipe hash exporté ; comment désactiver une entrée depuis le DPA, et comment savoir que l'opération est terminée ? ». Réponse fournie par la surface API côté périphérique dans CAPABILITIES.md ## Capabilities and modes (« consommation côté DPA ») + l'allocation de file d'attente côté hôte + l'étape de polling côté DPA dans TASKS.md ## run.
« Que signifie ce DOCA_ERROR_* d'un appel doca_flow_dpa_*, et le bug est-il côté hôte, côté DPA, ou dans la poignée de main d'export entre les deux ? » — exemple traité : « DOCA_ERROR_BAD_STATE de doca_flow_dpa_pipe_export ». Réponse fournie par la superposition du fournisseur sur la taxonomie cross-bibliothèque dans CAPABILITIES.md ## Error taxonomy + l'échelle en couches dans TASKS.md ## debug qui escalade vers doca-debug.
« Pourquoi mon export de pipe a réussi mais mon kernel DPA ne voit jamais d'entrées ? » — exemple traité : « J'ai appelé doca_flow_dpa_pipe_export_prepare APRÈS avoir ajouté des entrées au pipe ». Réponse fournie par la règle de cycle de vie dans CAPABILITIES.md ## Safety policy + le workflow d'export par étapes dans TASKS.md ## test.
« L'API du fournisseur côté hôte / côté DPA que je lis est-elle disponible sur mon DOCA installé ? » — exemple traité : « la doca_flow_dpa_queues_create à trois types de file d'attente est-elle disponible pour les versions DOCA + DPACC sur cet hôte, ou suis-je toujours sur l'ancienne surface basée sur doca_flow_dpa_pipe_queues ? ». Réponse fournie par la superposition de compatibilité de version dans CAPABILITIES.md ## Version compatibility qui effectue un cross-lien vers la chaîne de détection canonique dans doca-version et ajoute la superposition spécifique au fournisseur héritée de doca-dpa.

Audience

Cette skill sert les développeurs externes construisant des applications consommant la bibliothèque DOCA Flow DPA Provider — c'est-à-dire les utilisateurs qui ont déjà un pipe doca-flow côté hôte et un contexte d'exécution doca-dpa côté hôte, et qui veulent câbler les deux ensemble afin qu'un kernel DPA puisse lire les compteurs / muter les entrées / lire ou écrire les ressources externes liées à ce pipe Flow en ligne, au lieu de faire des allers-retours via le CPU hôte. Ce n'est pas pour les développeurs NVIDIA contribuant à la bibliothèque du fournisseur elle-même, ni pour les utilisateurs qui ont besoin uniquement de programmation Flow côté hôte (c'est doca-flow) ou qui ont besoin uniquement de calcul DPA générique sans rapport avec Flow (c'est doca-dpa).

Portée linguistique. DOCA Flow DPA Provider est livré en tant que bibliothèque appairée : une bibliothèque C côté hôte (module pkg-config doca-flow-dpa-provider, en-tête doca_flow_dpa_provider.h) plus une bibliothèque de périphérique côté DPA que le compilateur DPACC lie à l'unité de traduction côté DPA quand le kernel inclut doca_flow_dpa_provider_dev.h. Les deux moitiés sont en C. Les samples livrés (sous l'arborescence DOCA des samples installés) incluent les deux unités de traduction. Les consommateurs côté hôte dans d'autres langages peuvent faire une FFI sur la bibliothèque C côté hôte, mais le kernel côté DPA n'a pas d'échappatoire FFI (le compilateur DPACC accepte une seule unité de traduction par image de kernel). La skill maintient le cycle de vie, la découverte de capacités, l'env-condition préalable, et les conseils de taxonomie d'erreur indépendants du langage côté hôte, et pointe toutes les questions de programmation de kernel côté DPA vers les guides publics DOCA DPA et DOCA Flow via doca-public-knowledge-map.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait du travail pratique avec DOCA Flow DPA Provider, dans n'importe quel langage hôte plus une unité de traduction côté DPA compilée par dpacc. Concrètement :

Initialisation d'un doca_flow_dpa_ctx par rapport à un flexio_process qui mappe sur un BlueField avec un processeur DPA visible par l'hôte ET un port doca-flow côté hôte déjà mis en place par rapport au même appareil.
Allocation des trois types de file d'attente côté DPA (général / entrées, écriture-ressources, lecture-ressources) pour un port via doca_flow_dpa_queues_create.
Export d'un doca_flow_pipe côté hôte dans l'espace d'adressage DPA via la séquence doca_flow_dpa_pipe_export_prepare → _pipe_export → _pipe_get_device_addr, AVANT que toute entrée soit ajoutée au pipe.
Export d'une ressource Flow externe (ressource de sélecteur d'index, ressource de mémoire) vers le DPA via la famille correspondante doca_flow_dpa_external_resource_*.
Transmission du pointeur de périphérique doca_flow_dpa_addr résultant au kernel côté DPA afin que le kernel puisse appeler doca_flow_pipe_hash_* / doca_flow_external_resource_* / doca_flow_queue_poll_completion sur celui-ci.
Débogage d'un DOCA_ERROR_* d'un appel doca_flow_dpa_* — en particulier disambiguation export appelé trop tard dans le cycle de vie du pipe de files d'attente pas encore créées de file d'attente côté DPA pleine et non purgée.
Conception de liaisons côté hôte dans un langage non-C qui pilotent la configuration côté hôte du fournisseur et transmettent l'adresse de périphérique à une image d'application DPA compilée séparément avec dpacc.

Ne chargez pas cette skill pour la programmation générale DOCA Flow (utilisez doca-flow), le travail DPA générique côté hôte (utilisez doca-dpa), ou l'écriture de kernel côté DPA elle-même (pointez via doca-public-knowledge-map vers les guides publics de programmation DOCA DPA / DPACC / Flow).

Ce que cette skill fournit

C'est un chargeur léger. Le corps ne conserve que l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique au fournisseur vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que l'API du fournisseur côté hôte et côté DPA peut exprimer sur cette version + cette génération de BlueField : le contexte doca_flow_dpa_ctx par port, les trois types de file d'attente (DOCA_FLOW_DPA_QUEUE_TYPE_GENERAL / _RESOURCES_WRITE / _RESOURCES_READ), la poignée de main d'export de pipe (préparer → exporter → obtenir-adresse-périphérique), la poignée de main d'export de ressource externe parallèle, l'API de périphérique côté DPA pour la manipulation d'entrée de pipe hash (doca_flow_pipe_hash_enable_index / _hash_disable_index / _hash_replace_index), l'API de périphérique côté DPA pour les ressources externes (doca_flow_external_resource_index_selector_modify*, doca_flow_external_resource_memory_update, doca_flow_external_resource_memory_read*), le polling de file d'attente de complétion (doca_flow_queue_poll_completion), la règle du modèle à trois programmes (hôte doca-flow + hôte doca-dpa + kernel côté DPA), la taxonomie d'erreur mappée sur l'ensemble cross-bibliothèque DOCA_ERROR_*, la surface d'observabilité, et la politique de sécurité qui fait la porte du cycle de vie d'export.
TASKS.md — workflows étape par étape pour les verbes de fournisseur en portée : install, configure, build, modify, run, test, debug, use. Plus un bloc Deferred task verbs qui pointe les questions hors de portée vers la bonne prochaine skill.

La 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 par l'hôte, le compilateur DPACC installé à une version correspondant à l'installation DOCA selon la politique de compatibilité DOCA, l'utilisateur sait déjà comment mettre en place un port doca-flow et créer un doca_dpa côté hôte (ou son équivalent FlexIO) pour l'exécution de kernel, et l'utilisateur dispose d'au moins une esquisse du kernel côté DPA qui consommera l'adresse de périphérique du pipe exporté.

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

Cette skill est une orientation pour agent, pas un bundle de samples ou de modèles. Pour garder la limite claire, elle délibérément ne contient pas — et les demandes de tirage ne devraient pas ajouter :

Code source d'application DOCA Flow DPA Provider pré-écrit ou kernel côté DPA, dans n'importe quel langage. Le source du fournisseur vérifié sont les samples C + côté DPA livrés sous l'arborescence DOCA des samples installés (pointez via doca-public-knowledge-map pour le chemin d'arborescence de sample par installation). Le travail de l'agent est d'orienter l'utilisateur vers ces fichiers et de prescrire une modification à diff-minimum sur ceux-ci via le workflow universel modify-a-sample de doca-programming-guide, stratifié avec les substitutions spécifiques au fournisseur dans TASKS.md ## modify.
Manifestes de compilation autonomes (meson.build, CMakeLists.txt, …) stationnés à l'intérieur de la skill. L'agent construit le manifeste de compilation dans le répertoire de projet de l'utilisateur par rapport aux DOCA + compilateur DPACC installés de l'utilisateur, où pkg-config --modversion doca-flow-dpa-provider (avec doca-flow et doca-dpa) et le dpacc installé sont les sources de vérité communes.
Une sous-arborescence samples/, bindings/, ou reference/ d'une sorte quelconque. Un artefact simulé ou incomplet dans l'arborescence de cette skill, même s'il est étiqueté « reference », est trompeur : les utilisateurs le liront comme compilable.
Contenu de spécification de pipe doca-flow côté hôte. C'est la portée de doca-flow ; cette skill exporte un pipe déjà construit et ne redéfinit pas comment le construire.
Généralités de programmation de kernel côté DPA. Écrire le corps de fonction côté DPA, allouer la mémoire DPA à l'intérieur du kernel, les intrinsèques, les bibliothèques côté DPA comme doca-dpa-comms et doca-dpa-verbs — hors de portée. Pointez vers les guides publics DOCA DPA / DPACC via doca-public-knowledge-map.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en portée (travail de pipe Flow exporté vers DPA, pas du travail doca-flow pur et pas du travail doca-dpa générique).
Pour la matrice de capacité du fournisseur, le modèle à trois programmes, le doca_flow_dpa_ctx par port, les trois types de file d'attente, les poignées de main d'export de pipe et de ressource externe, la surface API de périphérique côté DPA, le modèle de complétion, la taxonomie d'erreur, la surface d'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows étape par étape — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Les deux fichiers compagnons s'effectuent un cross-lien, doca-flow et doca-dpa pour les surfaces côté hôte que cette bibliothèque relie, doca-version pour les règles de gestion de version DOCA canoniques (avec la superposition DOCA-et-DPACC héritée de doca-dpa), et doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez-le dans les guides publics de programmation DOCA Flow / DOCA DPA / DPACC, ou dans la disposition d'installation sur disque » plutôt que « orientation spécifique au fournisseur ».

Skills connexes

doca-flow — la skill canonique de programmation Flow côté hôte. Le pipe Flow que cette bibliothèque exporte DOIT être mis en place par rapport à doca-flow CAPABILITIES.md ## Capabilities and modes d'abord ; cette skill ajoute seulement la couche d'export DPA par-dessus.
doca-dpa — la bibliothèque de contrôle DPA côté hôte. Le kernel DPA qui consomme l'adresse de périphérique exportée est chargé et lancé via doca-dpa (ou son équivalent de processus FlexIO) ; cette skill hérite du modèle à deux programmes, la règle de correspondance de version DPACC-et-DOCA, et la matrice env-condition préalable de là.
doca-public-knowledge-map — table de routage pour chaque source de documentation DOCA publique (guide DOCA Flow à https://docs.nvidia.com/doca/sdk/doca-flow/index.html ; guide DOCA DPA à https://docs.nvidia.com/doca/sdk/doca-dpa/index.html ; guide du compilateur DPACC et parapluie DPA Tools accessibles à partir de la même table de routage) et la disposition sur disque d'un package DOCA installé.
doca-setup — préparation env, vérification d'installation, installation du compilateur DPACC / vérification, et le chemin Je n'ai pas encore d'installation avec le container DOCA NGC public. Cette skill suppose que ses conditions préalables sont satisfaites ET que DPACC est installé à une version qui correspond à DOCA.
doca-version — règles canoniques de gestion de version DOCA. Le ## Version compatibility de cette skill effectue un cross-lien vers la règle de correspondance quatre-voies et ajoute la superposition spécifique au fournisseur DOCA-et-DPACC doivent correspondre selon la politique de compatibilité DOCA (héritée de doca-dpa).
doca-structured-tools-contract — la règle de préséance des outils structurés du bundle (détecter / préférer / revenir / rapporter). L'appendice Command dans TASKS.md honore ce contrat.
doca-programming-guide — motifs généraux de programmation DOCA : le motif de compilation pkg-config + meson canonique, le workflow premier-app universel modify-a-shipped-sample, le cycle de vie du contexte Core universel, la taxonomie DOCA_ERROR_* cross-bibliothèque, et l'ordre de débogage côté programme. Cette skill stratifie les spécificités du fournisseur par-dessus.
doca-debug — l'échelle de débogage cross-cutting (install / version / build / link / runtime / program / driver). Débogage spécifique au fournisseur (ordre du cycle de vie entre la création du pipe Flow, la création de file d'attente, la préparation d'export, l'ajout d'entrée, l'export ; file d'attente pleine sur le polling côté DPA ; adresse de périphérique du pipe remise à un kernel qui cible un doca_flow_dpa_ctx différent) se stratifie par-dessus.
doca-hardware-safety — meta-politique de sécurité matérielle cross-cutting que le ## Safety policy de cette skill se stratifie par-dessus. Parce que le pipe exporté est muté en ligne par du code kernel côté DPA, la discipline validate-before-commit de doca-flow plus la discipline rebuild-two-side-program de doca-dpa TOUS les deux s'appliquent, et la meta-politique fournit le cadrage cross-cutting.