DOCA Flow DPA Perf (doca_flow_dpa_perf)

Par où commencer : Ceci est une skill d'outil pour invoquer doca_flow_dpa_perf, l'outil de performance Flow accéléré par DPA. Ouvrez TASKS.md et commencez à ## configure pour confirmer le matériel compatible DPA + le mode Flow VNF + la répartition des appareils actif/passif, puis ## run pour le flux smoke-before-bulk avec un petit nombre d'opérations avant tout sweep, puis ## test pour la surcouche eval-loop qui valide les chiffres défendables en Kops/sec. Ouvrez CAPABILITIES.md quand la question porte sur ce que doca_flow_dpa_perf peut mesurer, quelles sont les préconditions DPA, sur quels appareils il s'exécute, ou comment interpréter les sorties update/disable/self-test sans vous tromper. Si DOCA n'est pas encore installé, adressez-vous à doca-setup d'abord ; si l'appareil n'est pas compatible DPA (pas de ConnectX-7+ ou BlueField-3+), cet outil est la mauvaise surface et la bonne réponse est doca-flow-perf.

Questions d'exemple auxquelles cette skill répond bien

Les CLASSES de questions doca_flow_dpa_perf que cette skill est construite pour répondre, chacune avec un exemple travaillé. La classe est la pièce structurante ; l'exemple travaillé en est une instance.

• « Dois-je mesurer le chemin Flow offloadé DPA ou le chemin Flow host/DPU-CPU pour cette question ? » — exemple travaillé : « mon workload programme des entrées de sélecteur de chemin via DOCA Flow ; dois-je établir une baseline avec doca_flow_dpa_perf ou avec doca_flow_perf ? ». Répondu par la limite DPA-vs-host dans CAPABILITIES.md ## Capabilities and modes et le tableau des préconditions d'appareil.
• « Qu'est-ce que l'offload DPA accélère réellement, et qu'est-ce qu'il ne change pas ? » — exemple travaillé : « si je déplace mon chemin de mise à jour des règles Flow sur le DPA, qu'est-ce qui change dans le plan de données pour les paquets eux-mêmes ? ». Répondu par la portée DPA-Provider dans CAPABILITIES.md ## Capabilities and modes.
• « Quel matériel dois-je avoir pour utiliser cet outil du tout ? » — exemple travaillé : « mon BlueField-2 est-il compatible DPA ? ». Répondu par le tableau des préconditions d'appareil dans CAPABILITIES.md ## Capabilities and modes (BlueField-3 oui, BlueField-2 non ; ConnectX-7 recommandé ou ultérieur, ConnectX-8/9 supportés selon le guide public et le README livré sur l'installation de l'utilisateur).
• « Comment dimensionner mon exécution — burst, queue, seuil de complétion, nombre d'opérations, itérations — pour obtenir un chiffre défendable en Kops/sec ? » — exemple travaillé : « je veux la médiane du temps d'itération et l'écart type, pas un pic de première itération bruyant unique ». Répondu par la surcouche eval-loop dans TASKS.md ## test et la règle iteration-stats dans CAPABILITIES.md ## Observability.
• « Mon outil rapporte zéro ops / pend / échoue au self-test — qu'est-ce que cela signifie ? » — exemple travaillé : « l'outil s'exécute mais l'étape de self-test échoue ». Répondu par la taxonomie d'erreur en couches dans CAPABILITIES.md ## Error taxonomy
  • l'échelle de débogage dans TASKS.md ## debug.
• « Comment citer un chiffre DPA-perf aux côtés d'un chiffre host-side Flow-perf pour le même workload, d'une manière que l'ingénieur suivant peut réellement comparer ? » — exemple travaillé : « deux chiffres Kops/sec pour ce qui est censé être le même workload ». Répondu par la règle de capture quatre-tuple dans CAPABILITIES.md ## Safety policy
  • la règle par-nom-d'outil (l'outil host et l'outil DPA sont des surfaces différentes ; leurs chiffres ne sont pas interchangeables sans nommer quel outil a produit quel résultat).

Public

Cette skill sert les opérateurs externes, ingénieurs en performance, développeurs d'applications DOCA Flow, et agents IA qui ont besoin d'une mesure défendable du chemin de mise à jour Flow offloadé DPA sur du matériel compatible DPA. Concrètement :

• Un opérateur de plateforme décidant s'il faut déplacer un workload de sélecteur de chemin sur le DPA ou le maintenir sur le chemin host/DPU-CPU, et voulant un chiffre pour comparer.
• Un ingénieur en performance produisant une baseline « Kops/sec DPA pour l'opération de mise à jour, taille-queue X, taille-burst Y, N workers » sur un appareil + version DOCA spécifiques pour qu'une comparaison en aval soit significative.
• Un développeur d'applications DOCA Flow qui a déjà utilisé doca-dpa pour déployer un offload DPA de son chemin de mise à jour des règles Flow et veut caractériser ce que l'appareil livre.
• Un agent IA répondant « quel débit de mise à jour dois-je attendre du chemin Flow offloadé DPA sur l'appareil Y ? » honnêtement — avec un chiffre mesuré, la ligne de commande qui l'a produit, et l'appareil + version DOCA + environnement tel que déployé qui le scop — au lieu de deviner à partir des titres de la fiche technique.

Ce n'est pas pour les utilisateurs déboguant le code source de l'outil, pas un substitut au guide DOCA Flow DPA Perf public en direct sur docs.nvidia.com, pas l'endroit pour apprendre les APIs doca-flow ou doca-dpa (ce public appartient à doca-flow et doca-dpa), et pas l'outil approprié pour le chemin Flow host/DPU-CPU (adressez-vous à doca-flow-perf).

doca_flow_dpa_perf est livré comme un seul binaire CLI avec le code d'appareil côté DPA lié. La skill utilise la même forme trois-fichiers kind: tool que le reste du bundle pour que le contrat task-verb de l'agent soit uniforme dans le bundle.

Portée du langage

Cette skill gouverne l'invocation, l'interprétation de la sortie, et la recommandation de routage pour le CLI doca_flow_dpa_perf sur du matériel compatible DPA. L'outil lui-même possède à la fois un contrôle côté host (code C-language ARGP + DOCA + DPDK selon les fichiers flow_dpa_perf.c / flow_dpa_perf_core.c livrés) et un composant d'appareil côté DPA (code côté DPA sur le runtime d'appareil DPA livré). Les utilisateurs externes ne lient rien de ceci ; ce qu'ils configurent est la surface d'invocation JSON-config-ou-CLI. Pour le modèle de programmation doca-dpa derrière le moteur d'exécution côté DPA, voir doca-dpa ; pour l'API doca-flow derrière le pipeline que le chemin DPA exécute, voir doca-flow.

Quand charger cette skill

Chargez cette skill quand l'utilisateur est — ou l'agent doit — invoquer doca_flow_dpa_perf sur un vrai host avec DOCA installé et un appareil compatible DPA attaché (ou le conteneur DOCA NGC public avec le passthrough d'appareil équivalent) pour mesurer les débits de mise à jour/désactivation sur le chemin Flow offloadé DPA. Concrètement :

• Confirmer les préconditions DPA (classe d'appareil compatible DPA, mode Flow VNF, utilisation PF recommandée, pas de SFs) avant d'invoquer l'outil.
• Choisir la répartition active/passive d'appareil appropriée au matériel de l'utilisateur (BlueField-3 deux-ports actif + passif ; ConnectX-9 un-port actif seulement).
• Choisir les axes de forme de workload (taille burst, taille queue, seuil de complétion, algorithme hash pipe, politique de travail, nombre de tables PSL, taille de table, nombre de workers).
• Choisir l'axe d'opération (mise à jour ou disable-enable) selon les opérations documentées du README livré.
• Produire un chiffre défendable en Kops/sec avec les stats d'itération capturées (médiane, max, écart type).
• Diagnostiquer les exécutions zéro-ops / pendues / failed-self-test via la taxonomie d'erreur en couches.

Ne pas charger cette skill pour l'orientation générale DOCA, le travail sur l'API du programme Flow, ou l'installation. Pour ceux-ci, utilisez doca-public-knowledge-map, la skill libs/<library> correspondante, ou doca-setup. Ne pas la charger pour le chemin Flow host/DPU-CPU — ce public appartient à doca-flow-perf.

Ce que cette skill fournit

Ceci est un thin loader. Le matériel substantiel vit dans deux fichiers complémentaires :

• CAPABILITIES.md — ce que doca_flow_dpa_perf mesure (le chemin update/disable du DPA-Provider-sur-appareil-DPA spécifiquement), la limite DPA-vs-chemin-host, le tableau des préconditions d'appareil (ConnectX-7+/BlueField-3+), la règle de mode Flow VNF-seulement documentée, la règle PF-vs-VF-vs-SF (SFs non supportés sur DPA), les axes de forme de workload (burst, queue, seuil de complétion, algorithme hash pipe, politique de travail, tables PSL, taille de table, workers), l'axe d'opération (update vs disable-enable), la surcouche de version (cet outil roule les versions doca-flow et doca-dpa qu'il lie ; les règles canoniques vivent dans doca-version), la taxonomie d'erreur en couches (syntaxe-config / device-binding / dpa-precondition / workload-precondition / measurement-soundness / self-test / version / cross-cutting), la surface d'observabilité (statistiques d'itération, vérification self-test de sélecteur de chemin, vérification de trafic côté tcpdump), et la posture de sécurité (smoke-before-bulk, capture quatre-tuple, nommer l'outil qui a produit le chiffre).
• TASKS.md — workflows étape par étape pour les verbes de tâche en portée : install (router à setup ; le binaire est livré), configure (préconditions-DPA + appareil actif/passif + décision de forme de workload), build (router à install — le binaire est livré), modify (refuser — modifier l'invocation, pas le binaire), run (smoke avant bulk), test (eval loop), debug (diagnostic en couches), use (consommer le chiffre capturé), plus un bloc Deferred task verbs routant les questions hors de portée et un Command appendix.

La skill suppose un host où DOCA est déjà installé (ou le conteneur DOCA NGC est en exécution) sur un appareil compatible DPA et l'opérateur dispose des permissions pour lier l'appareil et allouer les ressources d'exécution DPA que l'outil nécessite.

Ce que cette skill n'expédie délibérément pas

Cette skill est une guidance pour agent, pas un bundle de samples ou scripts. Pour garder la limite propre, elle n'expédie délibérément pas — et les pull requests ne doivent pas ajouter :

• Valeurs par défaut verbatimes pour les inventaires de flags au-delà de ce que le guide public et le README livré documentent. La surface flag est install-spécifique dans la surface documentée ; les invocations documentées + --help sur la version installée sont la réponse autorisée. Inventer un flag est l'hallucination de défaillance la plus commune.
• Chiffres Kops/sec pre-baked ou nombres de débit attendu. La sortie est device-, firmware-, DOCA-version-, workload-, et platform-spécifique ; un chiffre épinglé pour une plateforme induit les opérateurs en erreur sur une plateforme/version différente. Les chiffres d'exemple du README livré sont illustratifs, pas une baseline que l'agent doit citer comme vérité absolue.
• Wrappers, parsers, ou scripts dans n'importe quel langage qui consomment stdout/CSV de l'outil. Le format de sortie est documenté ; si un utilisateur veut scripter contre lui, la bonne réponse est « lisez le guide en direct, écrivez le parser contre votre version installée ».
• Un sous-arbre samples/ ou reference/. Ceci est un thin loader pour un CLI documenté ; le matériel substantiel vit sur la page publique, dans --help, et dans le README livré sur l'installation de l'utilisateur.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en portée (l'utilisateur veut réellement invoquer doca_flow_dpa_perf sur du matériel compatible DPA, pas mesurer le chemin Flow host/DPU-CPU).
2. Pour ce que doca_flow_dpa_perf mesure, la limite DPA-vs-host, le tableau des préconditions d'appareil, les axes de forme de workload, la surcouche de version, la taxonomie d'erreur, la surface d'observabilité, et la posture de sécurité, voir CAPABILITIES.md.
3. Pour les invocations documentées et le workflow smoke-before-bulk — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Skills connexes

• doca-flow — la bibliothèque de base dont ce tool mesure le pipeline sur le chemin DPA. La surface pipe/entry/rule que cet outil pilote est créée par du code programme doca-flow ; les attributs de la bibliothèque et la surface de capacité sont le contexte en amont.
• doca-dpa — le modèle de programmation derrière le moteur d'exécution DPA sur lequel l'outil s'exécute. Quand la question de l'utilisateur passe de « mesurer le chemin DPA » à « pourquoi le chemin DPA fait ceci », cette skill est la prochaine étape.
• doca-flow-perf — l'outil de performance Flow host/DPU-CPU. La règle de comparaison inter-outils vit dans CAPABILITIES.md ## Capabilities and modes : nommer quel outil a produit quel chiffre.
• doca-flow-tune — l'outil de tuning Flow. Un chiffre DPA-perf est le genre de baseline que doca-flow-tune optimise ensuite, via une boucle modify-a-sample du programme Flow.
• doca-public-knowledge-map — routage vers la page DOCA Flow DPA Perf publique sur docs.nvidia.com et le reste de l'ensemble de documentation DOCA publique.
• doca-version — règles canoniques de gestion de version DOCA. La section ## Version compatibility dans cette skill est une surcouche fine dessus.
• doca-setup — préparation d'env, vérification d'install, hugepages, conscience NUMA, et le chemin je n'ai pas d'install encore avec le conteneur DOCA NGC public.
• doca-debug — l'échelle de débogage cross-cutting. DPA-perf expose sa propre taxonomie d'erreur ; quand la cause s'avère être au-dessous de DOCA, la taxonomie délègue à doca-debug.
• doca-hardware-safety — la méta-politique de sécurité-matérielle cross-cutting que la ## Safety policy de cette skill superpose.