Pont DOCA DPDK

Par où commencer : Cette skill assume que DOCA est déjà installé, que DPDK est déjà installé, que l'utilisateur dispose d'une application DPDK existante, et qu'il souhaite ajouter des capacités DOCA à celle-ci sur place (le plus souvent DOCA Flow pour le steering matériel) sans migrer le data-plane vers des APIs DOCA natives. 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 le pont peut exprimer sur cette version. Si l'utilisateur n'a pas encore installé DOCA, routez-le vers doca-setup en premier. Si l'utilisateur commence de zéro (pas encore de code DPDK) et souhaite juste une I/O paquets à débit ligne contre DOCA, routez-le vers doca-eth à la place — le pont existe pour le cas d'interopérabilité, pas pour le cas démarrage de zéro.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions du pont DOCA DPDK auxquelles cette skill est conçue pour répondre, chacune avec un exemple travaillé. L'agent devrait traiter la classe comme l'élément porteur — l'exemple travaillé est une instance unique.

"J'ai une appli DPDK — comment ajouter des règles DOCA Flow sans réécrire le data-plane ?" — exemple travaillé : "mon appli de traitement de paquets drive déjà des mbufs à travers les ports `rteeth; je veux installer des règles de steering DOCA Flow sur ces ports pour l'offload HW"*. Répondu par la règle de sélection pont-vs-natif dans [CAPABILITIES.md ## Capabilities and modes](CAPABILITIES.md#capabilities-and-modes) + le workflow de remise de port dans [TASKS.md ## configure`](TASKS.md#configure) étape 3.
"Comment rendre un port DPDK visible à DOCA ?" — exemple travaillé : "j'ai un ID de port DPDK issu de `rte_ethdev; comment DOCA le voit"*. Répondu par le mapping DPDK-port-id ↔doca_dev(doca_dpdk_port_probe/doca_dpdk_port_as_dev) dans la table d'objets pont [CAPABILITIES.md ## Capabilities and modes](CAPABILITIES.md#capabilities-and-modes) + le workflow de liaison dans [TASKS.md ## configure`](TASKS.md#configure) étape 4.
"Comment déplacer des paquets entre les mbufs DPDK et les buffers DOCA ?" — exemple travaillé : "DPDK livre un rte_mbuf à mon fastpath ; je veux qu'une bibliothèque DOCA opère sur le payload". Répondu par la forme de conversion mbuf ↔ buf-DOCA dans CAPABILITIES.md ## Capabilities and modes + le workflow de l'étape de conversion dans TASKS.md ## modify.
"Le pont est-il même installé et son DPDK est-il compatible avec mon DOCA ?" — exemple travaillé : "pkg-config --exists doca-dpdk-bridge retourne une erreur sur un hôte qui a DPDK installé séparément". Répondu par la règle de couplage de version dans CAPABILITIES.md ## Version compatibility + le workflow de vérification des capacités dans TASKS.md ## configure étape 1.
"Devrais-je utiliser doca-dpdk-bridge ou doca-eth ?" — exemple travaillé : "nouveau projet ; je ne me suis pas encore engagé envers DPDK". Répondu par le tableau de sélection de chemin dans CAPABILITIES.md ## Capabilities and modes ligne pont-vs-natif + la note sur les verbes reportés dans TASKS.md ## Deferred task verbs.
*"Que signifie ce `DOCAERRORd'un appel pont et quel niveau a causé l'erreur ?"** — exemple travaillé : *"DOCA_ERROR_NOT_FOUNDsur un appel d'enregistrement de port après que le port DPDK soit venu proprement"*. Répondu par la superposition pont sur la taxonomie inter-bibliothèques 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).

Audience

Cette skill sert les développeurs externes qui maintiennent déjà une application de traitement de paquets basée sur DPDK — c'est-à-dire des utilisateurs dont le data-plane drive déjà les ports rte_eth_* et les buffers rte_mbuf — et qui veulent ajouter des capacités DOCA (le plus souvent le steering matériel via DOCA Flow) en reliant le pont dans le même processus. Ce n'est pas pour les utilisateurs commençant un projet DOCA natif de zéro (routez vers doca-eth) et pas pour les utilisateurs exécutant du pur DPDK sans intérêt pour DOCA (aucune skill de ce bundle ne s'applique). Ce n'est pas non plus pour les développeurs NVIDIA contribuant à DOCA DPDK Bridge lui-même.

Portée linguistique. DOCA DPDK Bridge se livre comme une bibliothèque C avec le nom de module pkg-config doca-dpdk-bridge (l'agent doit confirmer l'orthographe contre l'installation de l'utilisateur via pkg-config --exists doca-dpdk-bridge ; certaines versions DOCA utilisent un nom de module légèrement différent et l'agent ne doit pas deviner). Les échantillons fournis sont écrits en C. Les consommateurs C et C++ sont le cas canonique ; les exemples travaillés dans TASKS.md supposent ce chemin. Les consommateurs en autres langages (Rust, Go, Python, …) n'utilisent généralement pas ce pont — DPDK lui-même a une forme C, et une appli DPDK en non-C est rare ; si l'utilisateur se trouve dans cette minorité, la contribution de la skill est de garder le guidance port-handover, capability, permission et error-taxonomy indépendant du langage et de les router vers l'ABI C public comme surface autoritaire.

Quand charger cette skill

Chargez cette skill quand l'utilisateur travaille concrètement avec DOCA DPDK Bridge, dans n'importe quel langage. Concrètement :

L'utilisateur a une APPLICATION DPDK EXISTANTE (son data-plane drive déjà les ports rte_eth_dev_* et les buffers rte_mbuf), et il veut superposer DOCA par-dessus — ajouter des règles DOCA Flow, alimenter des paquets vers un accélérateur DOCA (Compress, AES-GCM, …), ou câbler un service DOCA dans le même processus.
L'utilisateur doit lier un ID de port DPDK à un doca_dev (via doca_dpdk_port_probe / doca_dpdk_port_as_dev) pour que DOCA Core / DOCA Flow puisse opérer sur le même port physique.
L'utilisateur doit convertir entre les mbufs DPDK et les buf-DOCA à la limite du data-plane, et pose des questions sur les helpers de conversion et leur coût.
L'utilisateur débogue un DOCA_ERROR_* retourné par un appel pont (lifecycle vs. permission vs. capability vs. port-DPDK-non-enregistré vs. conversion-mbuf-échouée) et la pile DPDK ↔ DOCA en couches en dessous.
L'utilisateur heurte de la douleur inter-versions : son installation DPDK et son installation DOCA ne sont pas la paire assortie que le pont attend.
L'utilisateur pose la question "natif doca-eth ou doca-dpdk-bridge ?" et l'agent a besoin de la règle de sélection de chemin.

Ne chargez pas cette skill pour une orientation DOCA générale, une installation de DOCA lui-même, une I/O paquets DOCA-natif de zéro (utilisez doca-eth), une programmation de règles de flux seule (utilisez doca-flow), une messagerie de contrôle hôte ↔ DPU (utilisez doca-comch), ou un mouvement de données RDMA (utilisez doca-rdma). Pour l'orientation de la documentation DOCA, utilisez doca-public-knowledge-map.

Ce que fournit cette skill

Ceci est un thin loader. Le corps garde seulement l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel spécifique au pont substantiel se trouve dans deux fichiers complémentaires :

CAPABILITIES.md — ce que le pont DOCA DPDK peut exprimer sur cette version : la règle de sélection pont-vs-natif (quand utiliser doca-dpdk-bridge vs natif doca-eth), la surface d'objets pont (mapping DPDK-port-id ↔ doca_dev, la conversion mbuf ↔ buf-DOCA de doca_dpdk_mempool), la surface de requête de capability (la simple doca_dpdk_cap_is_rep_port_supported), la taxonomie d'erreur pont (mappée sur l'ensemble cross-library DOCA_ERROR_*), la surface d'observabilité (compteurs côté DPDK + événements PE côté DOCA), et la politique de sécurité qui gate le couplage de version matched-pair DPDK ↔ DOCA, la précondition EAL-must-be-up, et les privilèges côté DPDK.
TASKS.md — workflows étape par étape pour les six verbes en scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la bonne skill suivante, et une Command appendix des commandes récurrentes auxquelles l'agent recourt.

La skill suppose un hôte ou BlueField où DOCA ET DPDK sont déjà installés aux emplacements standard et l'utilisateur dispose des privilèges que son profil d'installation publique attend (généralement sudo ou l'appartenance au groupe mlnx pour DOCA, plus les privilèges côté DPDK pour monter des hugepages, binder des ports PCIe, et ouvrir le périphérique rte_eth cible). Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup ; elle ne couvre pas l'installation ou l'apprentissage de DPDK lui-même — cela appartient à la documentation en amont de DPDK accessible via doca-public-knowledge-map.

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

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

Code source d'application DOCA DPDK Bridge pré-écrit, dans n'importe quel langage. Le code source du pont vérifié est l'utilisation du pont dans les échantillons C DOCA Flow fournis à /opt/mellanox/doca/samples/doca_flow/ (p. ex. flow_common.c, qui appelle doca_dpdk_port_probe() / doca_dpdk_port_as_dev()), plus les applications de référence canoniques qui appairent DPDK + DOCA Flow (voir doca-public-knowledge-map pour l'index des applications de référence). Le travail de l'agent est de router l'utilisateur vers ces fichiers et de prescrire une modification de différence minimale sur eux via le workflow universel modify-a-sample dans doca-programming-guide, superposé avec les overrides spécifiques au pont dans TASKS.md ## modify.
Manifestes de build autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) garés à l'intérieur de la skill. L'agent construit le manifeste de build dans le répertoire du projet de l'utilisateur contre le DOCA + DPDK installés de l'utilisateur, où pkg-config --modversion doca-dpdk-bridge et pkg-config --modversion libdpdk sont la source de vérité.
Un sous-arbre samples/, bindings/, ou reference/ de toute sorte. Un artefact mock ou incomplet dans l'arbre 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 (appli DPDK existante + veut DOCA par-dessus — pas de zéro).
Pour la matrice de capability du pont, la règle de sélection pont-vs-natif, la surface de remise de port, les règles de requête de capability, la taxonomie d'erreur, 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 complémentaires se croisent, doca-version pour les règles de traitement canonique des versions DOCA, doca-eth pour le chemin de zéro qui est l'alternative délibérée du pont, doca-flow pour la bibliothèque de steering qui est la raison la plus courante d'utiliser ce pont, et doca-public-knowledge-map chaque fois que la bonne réponse est « regardez dans les docs publiques ou le layout du package installé » plutôt que « guidance spécifique au pont ».

Skills connexes

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et le layout sur disque d'un package DOCA installé. Le slug URL du pont est DOCA-DPDK-Bridge. Les applications de référence qui appairent DPDK + DOCA Flow (les adoptants canoniques de ce pont) sont accessibles depuis l'index des applications de référence de la même carte.
doca-setup — préparation d'env, vérification d'installation, montages de hugepage (exigence DPDK), vérifications d'état de port (devlink dev show, ip link), exigences de permission et d'appartenance à un groupe pour ouvrir un doca_dev ET pour binder des ports PCIe sous DPDK. Cette skill suppose que ses préconditions sont satisfaites.
doca-version — règles de traitement canonique des versions DOCA. La section ## Version compatibility de cette skill croise les règles de correspondance quatre voies et ajoute seulement la superposition spécifique au pont (couplage matched-pair DPDK ↔ DOCA).
doca-structured-tools-contract — la règle de précédence des outils structurés du bundle (détecter / préférer / fallback / rapporter). La Command appendix dans TASKS.md honore ce contrat.
doca-programming-guide — les patterns de programmation DOCA généraux partagés par chaque bibliothèque : le pattern de build canonique pkg-config + meson, le workflow universel de modification d'échantillon expédié première-appli, le lifecycle universel, la taxonomie cross-library DOCA_ERROR_*, et l'ordre de debug côté programme. Cette skill superpose les spécifiques du pont par-dessus.
doca-eth — le chemin alternatif pour les utilisateurs commençant de zéro : I/O paquets natif DOCA pur via doca_eth_rxq / doca_eth_txq sans DPDK dans le portrait. Le pont existe parce que migrer une appli DPDK existante vers doca-eth est souvent le mauvais tradeoff ; pour un nouveau projet sans verrouillage DPDK, doca-eth est le bon choix.
doca-flow — la bibliothèque de steering qui est la raison la plus courante qu'une appli DPDK atteint ce pont. Le pont lie un ID de port DPDK à un doca_dev ; DOCA Flow programme des règles de steering sur ce doca_dev. Les deux bibliothèques sont conçues pour composer.
doca-debug — l'échelle de debug cross-cutting (install / version / build / link / runtime / program / driver). Le debug spécifique au pont (déviation de version DPDK ↔ DOCA, symptômes port-non-enregistré, défaillances de conversion mbuf) se superpose sur cette échelle.