DOCA Flow Perf (`doca_flow_perf`)

Par où commencer : C'est une compétence d'outil pour invoquer doca_flow_perf, l'outil de mesure de performance DOCA Flow côté hôte / côté DPU-CPU. Ouvrez TASKS.md et commencez à ## configure pour valider la décision tri-axiale (forme du pipeline Flow × classe de trafic × axe de mesure) et choisissez le fichier de politique JSON qui exprime la charge de travail, puis ## run pour le test de fumée à une itération, puis ## test pour la boucle d'évaluation itérative qui produit un nombre défendable en Kops/sec. Ouvrez CAPABILITIES.md lorsque la question porte sur ce que doca_flow_perf mesure et ce qu'il ne mesure délibérément pas, comment ses backends DPDK et DOCA diffèrent derrière le même contrat JSON, comment interpréter la sortie de cycles CPU par itération, ou comment il diffère de doca-flow-tune (mesure vs. optimisation) et doca-flow-dpa-perf (hôte / DPU-CPU vs. chemin DPA-offloadé). Si DOCA n'est pas installé, dirigez-vous vers doca-setup d'abord ; si la mesure cible est le chemin DPA-offloadé, dirigez-vous vers doca-flow-dpa-perf à la place ; si l'objectif est d'optimiser un pipeline Flow déjà déployé plutôt que de mesurer un pipeline synthétique, dirigez-vous vers doca-flow-tune — flow-perf est un microbenchmark avec pilote synthétique, pas un tuner d'application Flow en direct.

Questions d'exemple auxquelles cette compétence répond bien

« Je veux un nombre de base côté hôte défendable pour savoir combien de règles doca-flow par seconde un seul BlueField-3 peut insérer pour une charge de travail match-and-hairpin 5-tuple. De quel JSON de politique je pars, comment rendre le résultat reproductible, et qu'est-ce que je dois capturer avec le nombre pour qu'il soit défendable ? » — question de base flow-perf en forme de classe ; l'agent parcourt la bibliothèque configs/, le contrat JSON, et la règle de capture quadruple.
« Quelle est la différence entre doca-flow-perf, doca-flow-dpa-perf, et doca-flow-tune ? Ils mentionnent tous doca-flow et perf dans leurs noms — quand dois-je utiliser chacun d'eux ? » — mesure vs. optimisation plus hôte vs. chemin DPA ; l'agent expose les limites.
« Mon JSON de politique ressemble à l'exemple, mais le Kops/sec rapporté est dramatiquement inférieur aux nombres publiés que je vois dans les notes de version d'NVIDIA. Quelles variables dois-je contrôler avant de pouvoir faire confiance à la comparaison ? » — question de méthodologie ; l'agent parcourt les axes contrôlables (nombre de workers, profondeur de queue, taille de burst, champs de match fixes vs. incrémentés, backend DPDK vs. DOCA, mode BlueField, driver / firmware).
« J'ai une charge de travail qui ne correspond à aucun des JSON de politique livrés dans configs/. Comment j'écris un nouveau JSON de politique, quel est le schéma JSON en gros traits, et qu'est-ce qui change quand je passe un champ de match de mode: fixed à mode: increase ? » — question d'écriture JSON ; l'agent parcourt les configs livrées comme exemplaires et refuse d'inventer des champs de schéma inexistants dans l'arborescence source.
« Qu'est-ce que l'outil ne mesure vraiment PAS ? J'essaie de comprendre si un nombre flow-perf me dit quelque chose sur la latence du trafic end-to-end ou simplement sur le taux du plan de contrôle de programmation des règles. » — question de périmètre de méthodologie ; l'agent trace une ligne dure : cet outil mesure le taux du plan de contrôle d'installation / suppression de règles plus le taux de requête optionnel, NON la latence du dataplane, NON le débit du dataplane, NON la performance d'application end-to-end.
« Je vois deux backends — DPDK et DOCA — derrière le même JSON. Quand dois-je choisir lequel, et qu'est-ce que le choix signifie pour le résultat que je rapporte ? » — question de choix de backend ; l'agent parcourt le compromis backend DPDK vs. DOCA et insiste pour que l'opérateur RAPPORTE lequel il a utilisé.

Audience

Les agents IA expérimentés et les ingénieurs plateforme / réseau qui sont à l'aise avec le modèle de programmation doca-flow et le plan de contrôle DPDK, qui veulent un nombre défendable pour le taux d'installation / suppression de règles Flow côté hôte / DPU-CPU. On suppose que les lecteurs savent que les nombres publiés dans les notes de version d'NVIDIA sont exécutés avec des préconditions très spécifiques (version DOCA spécifique, firmware BlueField spécifique, classe de trafic spécifique) et que tout nombre qu'ils produisent localement doit explicitement énoncer ces préconditions.

Cette compétence n'est PAS pour :

les opérateurs qui veulent optimiser une application doca-flow déjà déployée — c'est doca-flow-tune ;
les opérateurs mesurant le chemin Flow DPA-offloadé — c'est doca-flow-dpa-perf ;
les opérateurs mesurant le débit ou la latence du dataplane end-to-end — c'est la responsabilité de l'application, en couche sur doca-flow ;
les contributeurs écrivant ou modifiant l'outil lui-même.

Portée du langage

L'interaction utilisateur avec doca_flow_perf se fait via :

Les drapeaux de ligne de commande du binaire livré (documentés par doca_flow_perf --help et le guide public DOCA Flow Perf sur docs.nvidia.com).
Un fichier de politique JSON décrivant le pipeline (ports, pipes, matchers, actions, forwarding). Le répertoire configs/ livré contient des politiques prêtes à l'emploi pour les classes de trafic les plus courantes ; les nouvelles politiques s'écrivent en copiant et modifiant l'une de celles-ci.
La sortie par itération de l'outil (cycles CPU par itération, nombre-traité, nombre-échoué ; rapporté via la stdout de l'outil — le format exact est le guide public et la sortie d'exécution du binaire, PAS une invention de cette compétence).

La compétence elle-même est du Markdown. Il n'y a pas d'API programmatique au-dessus de doca_flow_perf ; les consommateurs de ses résultats lisent sa stdout / ses journaux capturés.

Quand charger cette compétence

Chargez doca-flow-perf quand L'UNE des conditions suivantes est vraie :

l'utilisateur mentionne doca_flow_perf, doca-flow-perf, la bibliothèque JSON configs/, ou demande un nombre de « règles de flux par seconde côté hôte » ;
l'utilisateur veut faire une baseline d'un chemin Flow sous-jacent (pas optimiser une application en direct) ;
l'utilisateur compare la performance Flow hôte / DPU-CPU entre les versions DOCA, les générations BlueField, ou les versions de firmware ;
l'utilisateur veut concevoir un nouveau JSON de classe de trafic et doit savoir quel JSON configs/ prêt à l'emploi utiliser comme point de départ et quels champs il peut modifier.

Co-chargez cette compétence avec :

doca-flow (la bibliothèque sous-jacente ; flow-perf programme les mêmes matchers / actions / pipes que la bibliothèque expose) ;
doca-flow-tune (la limite mesure vs. optimisation est la confusion la plus courante) ;
doca-flow-dpa-perf (la limite hôte vs. chemin DPA est la deuxième confusion la plus courante) ;
doca-version (la correspondance quadruple version que tout nombre flow-perf rapporté doit porter) ;
doca-debug et doca-setup pour l'échelle de debug côté env.

Ne chargez PAS cette compétence quand l'utilisateur veut optimiser une application Flow en direct (dirigez vers doca-flow-tune) ou mesurer le chemin DPA-offloadé (dirigez vers doca-flow-dpa-perf).

Ce que cette compétence fournit

Trois fichiers compagnons dans ce répertoire, chacun traitant une forme de question différente :

SKILL.md — ce fichier. Audience, portée, ordre de chargement, compétences connexes. Route tout le reste.
CAPABILITIES.md — ce qu'est doca_flow_perf, ce qu'il mesure, ce qu'il ne mesure délibérément pas, la dualité backend DPDK-vs-DOCA, la surface du contrat JSON, l'interprétation de la sortie par itération, la compatibilité des versions (versionnée avec doca-flow et doca-version), la taxonomie d'erreurs en couches, l'observabilité, et la superposition de la politique de sécurité.
TASKS.md — les verbes procéduraux (configure, run, test, debug, etc.) plus une appendice de commande spécifique à doca_flow_perf et le workflow use côté agent qui consomme la sortie par itération capturée.

La compétence combinée enseigne à un agent IA de piloter la classe de mesure des questions doca_flow_perf : choisir un JSON de politique livré ou en créer un nouveau, exécuter le test de fumée à une itération, exécuter la boucle d'évaluation itérative, capturer le quadruple qui rend le nombre résultant défendable, interpréter la sortie, et router chaque question adjacente (tuner l'app en direct, mesurer le chemin DPA, optimiser le firmware) vers la bonne compétence voisine.

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

Mesure du débit ou de la latence du dataplane end-to-end. doca_flow_perf mesure le taux du plan de contrôle de programmation des règles, plus le timing de requête par entrée optionnel. Il ne mesure PAS la vitesse à laquelle les paquets traversent les règles résultantes dans le dataplane. C'est la responsabilité de l'application, en couche sur doca-flow. L'agent doit dire cela explicitement quand l'opérateur demande un « débit Flow ».
Mesure du chemin Flow DPA-offloadé. Dirigez vers doca-flow-dpa-perf.
Optimisation d'une application Flow déployée. Dirigez vers doca-flow-tune. flow-perf est un pilote synthétique d'un pipeline décrit en JSON, pas un tuner d'un pipeline en direct.
Un nombre Kops/sec canonical « bonne réponse ». L'agent refuse de citer les nombres publiés de mémoire comme autorité ; les nombres publiés vivent dans les notes de version d'NVIDIA par version DOCA et génération BlueField, et l'opérateur doit les reproduire sur ses propres préconditions exactes avant de comparer.
Champs de schéma JSON inventés. L'agent n'invente PAS les clés de politique JSON inexistantes dans les exemplaires configs/ livrés. Si une clé que l'opérateur veut n'est dans aucun exemplaire livré, l'agent le dit et dirige vers le guide public DOCA Flow Perf.
Explications de l'API doca-flow interne à la bibliothèque. Les matchers et actions sous-jacents appartiennent à doca-flow ; cette compétence les référence mais ne duplique pas la documentation API de la bibliothèque.
Affirmations comparables pommes-à-pommes sur le benchmarking multi-outils quand les préconditions diffèrent. Deux nombres flow-perf provenant de versions DOCA / générations BlueField / versions de firmware différentes ne sont PAS directement comparables ; l'agent insiste sur la capture quadruple pour que les consommateurs puissent juger.

Ordre de chargement

Quand une question doca_flow_perf arrive :

Confirmez que DOCA est installé et que le binaire plus la bibliothèque JSON configs/ sont accessibles — sinon, dirigez vers doca-setup ;
Confirmez que la bibliothèque doca-flow sous-jacente est saine sur l'appareil — sinon, dirigez vers doca-flow TASKS.md ## test ;
Confirmez que l'utilisateur veut mesurer, pas optimiser — si optimiser, dirigez vers doca-flow-tune ;
Confirmez que le chemin cible est hôte / DPU-CPU, pas DPA — si DPA, dirigez vers doca-flow-dpa-perf ;
Lisez CAPABILITIES.md pour valider la décision tri-axiale (forme du pipeline × classe de trafic × axe de mesure) ;
Lisez TASKS.md et parcourez ## configure → ## run → ## test → ## debug dans cet ordre ; ne commencez PAS par ## run sans le préalable d'étape ## configure.

Compétences connexes

Les conventions de lien croisé suivent le contrat de chemin relatif du bundle à partir de tools/<X>/ :

doca-flow — la bibliothèque sous-jacente. flow-perf programme les pipes, entrées, matchers, et actions Flow ; la bibliothèque est la source de vérité pour la surface API que flow-perf exerce.
doca-flow-tune — l'outil de tuning Flow unifié. La limite mesure vs. optimisation vit ici. Demandez : « veux-je un nombre, ou veux-je changer le pipeline déployé ? »
doca-flow-dpa-perf — l'outil de performance Flow DPA-offloadé. La limite hôte / DPU-CPU vs. chemin DPA vit ici. Demandez : « je mesure le chemin qui s'exécute sur le CPU, ou le chemin qui s'exécute sur le processeur DPA ? »
doca-version — tout nombre flow-perf rapporté doit venir avec la correspondance quadruple (package hôte, module kernel, firmware, version doca-flow liée de l'application cible) et la génération BlueField / ConnectX. flow-perf superpose cette règle, ne la contredit pas.
doca-setup — posture d'installation DOCA ; routage pour les questions « est-ce que le binaire est même ici ? »
doca-debug — l'échelle de debug transversale pour les problèmes côté env (driver, firmware, mode BlueField, module kernel).
doca-bench — un outil de benchmarking pair avec une portée plus large (plusieurs primitives DOCA, pas seulement Flow). flow-perf est le microbenchmark spécifique à Flow ; doca-bench est le benchmark de charge de travail plus large.
doca-public-knowledge-map — routage vers la page DOCA Flow Perf publique docs.nvidia.com, les notes de version, et les forums pour les nombres publiés spécifiques à la version et les notes de reproductibilité.
doca-structured-tools-contract — le contrat detect → prefer → fall back → report de l'agent pour les aides structurées (doca-env --json, doca-capability-snapshot, version-matrix.json) auxquelles les préconditions flow-perf se fient.
doca-hardware-safety — la méta-politique de sécurité matérielle canonique que CAPABILITIES.md ## Safety policy superpose.

Cette compétence suppose que l'application doca-flow environnante est l'artefact source existant de l'opérateur ; flow-perf ne livre pas sa propre application doca-flow exemple.

DOCA Flow Perf (doca_flow_perf)