DOCA PCC

Par où commencer : Cette skill suppose que DOCA est déjà installé, que le BlueField de l'utilisateur dispose d'un processeur DPA visible par l'hôte via DOCA, que le firmware du BlueField a l'emplacement custom-PCC activé, et que l'utilisateur effectue un travail custom PCC pratique depuis le côté hôte — c'est-à-dire en utilisant doca-pcc pour charger un algorithme de contrôle de congestion côté DPA sur le BlueField, l'attacher à un port gérant le trafic RDMA / RoCE, et le paramétrer depuis l'hôte. 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 PCC côté hôte peut exprimer sur cette version + cette génération de BlueField + ce firmware. Si l'utilisateur n'a pas encore installé DOCA, routez vers doca-setup d'abord ; si l'utilisateur demande comment écrire l'algorithme de contrôle de congestion côté DPA lui-même (le code qui s'exécute sur le processeur DPA, compilé par dpacc), c'est un scope différent — routez via doca-public-knowledge-map vers le guide de programmation public DOCA PCC et vers doca-dpa pour le cycle de vie DPA côté hôte sur lequel s'appuie cette skill. Si l'utilisateur veut seulement inspecter les compteurs PCC à l'exécution sans écrire un algorithme personnalisé, il s'agit de l'outil CLI pcc_counters — routez via doca-public-knowledge-map ## DOCA tools ; cette skill concerne les algorithmes personnalisés uniquement.

Exemples de questions que cette skill répond bien

Les CLASSES de questions PCC que cette skill est construite 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.

« Comment déployer mon propre algorithme de contrôle de congestion personnalisé sur un port BlueField transportant du trafic RDMA / RoCE ? » — exemple travaillé : « charger un petit algorithme PCC côté DPA et l'attacher au port BlueField qui gère mon trafic RoCE ». Répondu par le modèle de programme deux-côtés + le workflow de chargement-et-attachement côté hôte dans CAPABILITIES.md ## Capabilities and modes
- les étapes de mise en service dans TASKS.md ## configure.
« Ce BlueField + firmware permet-il réellement un algorithme PCC personnalisé, et quelles fonctionnalités PCC mon installation DOCA expose-t-elle ? » — exemple travaillé : « mon hôte dispose d'un BlueField et le PCC factory par défaut fonctionne ; puis-je y intégrer un algorithme personnalisé à la place ? ». Répondu par la règle de précondition triple-axes (la génération de BlueField doit avoir un DPA, le firmware doit avoir l'emplacement custom-PCC activé, doca_pcc_cap_* contre le doca_devinfo actif doit concorder) dans CAPABILITIES.md ## Capabilities and modes
- la checklist de précondition env dans TASKS.md ## configure étape 1.
« Pourquoi mon PCC personnalisé échoue-t-il avec DOCA_ERROR_NOT_PERMITTED alors que j'ai accès à doca_dev ? » — exemple travaillé : « le firmware BlueField sur cet hôte a l'emplacement custom-PCC désactivé ». Répondu par la matrice de permissions dans CAPABILITIES.md ## Safety policy
- le correctif côté firmware env dans TASKS.md ## configure étape 1.
« Cette bibliothèque doca-pcc est-elle le bon outil pour ce que je veux, ou préfère-je le PCC firmware par défaut ou le CLI pcc_counters ? » — exemple travaillé : « je veux juste lire les compteurs PCC sans toucher à l'algorithme ». Répondu par la règle de sélection de chemin dans CAPABILITIES.md ## Capabilities and modes
- les limites de sujet déféré dans CAPABILITIES.md ## Deferred topic boundaries qui routent vers doca-public-knowledge-map ## DOCA tools pour l'outil de compteurs.
« L'API PCC côté hôte que je lis dans la documentation est-elle sur mon DOCA installé ? » — exemple travaillé : « l'assistant de chargement côté hôte que je vois dans les docs est-il disponible sur les versions DOCA + DPACC de cet hôte ? ». Répondu par la surcouche de compatibilité de version dans CAPABILITIES.md ## Version compatibility qui croise la chaîne de détection canonique dans doca-version et ajoute la surcouche spécifique PCC DOCA doit correspondre à DPACC héritée de doca-dpa.
« Que signifie ce DOCA_ERROR_* d'un appel doca_pcc_* et quel layer l'a causé ? » — exemple travaillé : « DOCA_ERROR_DRIVER sur l'appel de chargement d'algorithme côté hôte — est-ce DOCA, l'emplacement custom-PCC côté firmware, ou l'image produite par DPACC ? ». Répondu par la surcouche PCC sur la taxonomie inter-bibliothèques dans CAPABILITIES.md ## Error taxonomy
- l'échelle en couches dans TASKS.md ## debug qui escalade vers doca-debug.

Audience

Cette skill sert les développeurs externes construisant des applications qui consomment la bibliothèque DOCA PCC depuis le côté hôte — c'est-à-dire, les utilisateurs dont le code appelle doca_pcc_* depuis C / C++ hôte pour mettre en place le contexte par instance PCC, charger une image d'algorithme PCC côté DPA que dpacc a produite à partir de leur source côté DPA, l'attacher au port BlueField qui transporte le trafic RDMA / RoCE que l'algorithme est censé contrôler, paramétrer l'algorithme, démarrer le contexte, et observer les rapports d'exécution renvoyés par l'algorithme. Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA PCC lui-même, ni l'endroit pour apprendre comment écrire l'algorithme de contrôle de congestion côté DPA lui-même (ce chemin passe par le guide de programmation public DOCA PCC et les guides companion DOCA DPA / DPACC via doca-public-knowledge-map).

Scope du langage. DOCA PCC est livré en tant que bibliothèque C côté hôte avec le nom de module pkg-config doca-pcc. L'API côté hôte est C ; l'algorithme de contrôle de congestion côté DPA est une unité de traduction séparée écrite dans un langage que le compilateur DPACC accepte et compilée par dpacc en un binaire que l'hôte empaquette dans l'exécutable en tant que l'image d'algorithme PCC. Les exemples livrés sous /opt/mellanox/doca/samples/doca_pcc/ sont écrits en C plus source côté DPA (choix de NVIDIA). Les consommateurs d'autres langages sont limités en pratique — l'algorithme côté DPA n'a pas d'échappatoire FFI car il doit être une unité de traduction que dpacc accepte — mais un wrapper Rust / Go / Python côté hôte qui pilote la configuration doca_pcc_* et charge une image d'algorithme PCC construite séparément reste utile, et la skill maintient l'orientation du cycle de vie, la découverte de capacités, les préconditions env, et les conseils de taxonomie d'erreur indépendants du langage.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait un travail DOCA PCC pratique depuis le côté hôte pour un algorithme de contrôle de congestion personnalisé, dans tout langage hôte plus une unité de traduction côté DPA construite par dpacc. Concrètement :

Initialiser un doca_pcc contre un doca_dev qui mappe au port BlueField transportant le trafic RDMA / RoCE à contrôler.
Charger une image d'algorithme PCC (doca_pcc_app) que dpacc a produite à partir de la source d'algorithme de contrôle de congestion côté DPA de l'utilisateur, dans le contexte doca_pcc.
Paramétrer l'algorithme chargé avec les boutons côté hôte que l'algorithme expose, et démarrer le contexte Core doca_pcc pour que l'algorithme commence à affecter le trafic RDMA / RoCE sur le port attaché.
Vérifier quelles fonctionnalités PCC sont supportées sur le doca_devinfo actif via la famille doca_pcc_cap_* — les générations BlueField et les révisions firmware diffèrent selon qu'elles permettent un algorithme PCC personnalisé.
Déboguer un DOCA_ERROR_* renvoyé par un appel doca_pcc_* — en particulier en désambiguïsant emplacement custom-PCC au niveau firmware désactivé de l'appareil ne supporte pas du tout le PCC personnalisé de l'image d'algorithme incompatible avec ce device de accès standard doca_dev refusé.
Concevoir des bindings côté hôte dans un langage non-C qui pilotent une image d'algorithme PCC personnalisé qu'ils ont construite séparément avec dpacc — les règles de précondition env et de découverte de capacités dans cette skill s'appliquent toujours.

Ne chargez pas cette skill pour l'orientation générale DOCA, l'installation de DOCA ou du compilateur DPACC, le modèle de programmation côté DPA lui-même (comment écrire le corps d'algorithme de contrôle de congestion qui s'exécute sur le DPA), les questions sur l'algorithme PCC factory par défaut livré dans le firmware ConnectX (aucun code doca-pcc côté hôte nécessaire — ce chemin est configuration firmware uniquement), ou les questions sur le CLI diagnostique pcc_counters (routez via doca-public-knowledge-map ## DOCA tools). Pour tous ceux-ci, routez via doca-public-knowledge-map vers le guide upstream correspondant.

Ce que cette skill fournit

C'est un chargeur fin. Le corps garde seulement l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique PCC vit dans deux fichiers companions :

CAPABILITIES.md — ce que l'API PCC côté hôte peut exprimer sur cette version + cette génération BlueField + ce firmware : le contexte doca_pcc par instance PCC, l'image d'algorithme doca_pcc_app chargée produite par dpacc, la sémantique d'attachement-au-port qui lie l'algorithme au trafic RDMA / RoCE qu'il contrôlera, la surface de requête de capacité (doca_pcc_cap_*), la taxonomie d'erreur PCC mappée sur l'ensemble DOCA_ERROR_* inter-bibliothèques, la surface d'observabilité (rapports côté hôte plus l'outil de compteurs PCC public accessible via doca-public-knowledge-map), et la politique de sécurité qui gate les préconditions env (BlueField capable DPA, emplacement custom-PCC au niveau firmware activé, versions DOCA + DPACC appairées, l'image d'algorithme et les attentes côté hôte concorde).
TASKS.md — workflows étape-par-étape pour les six verbes PCC in-scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors-scope vers la bonne skill suivante.

La skill suppose un hôte où DOCA est déjà installé à l'emplacement standard, un BlueField avec un processeur DPA est physiquement présent et visible à l'hôte, le firmware BlueField a l'emplacement custom-PCC activé, le compilateur DPACC est installé à une version appairée à l'installation DOCA selon la politique de compatibilité DOCA, et l'utilisateur sait déjà comment (au moins au niveau sketch) écrire l'algorithme PCC côté DPA que dpacc compilera. Il ne couvre pas l'installation de DOCA, l'installation du compilateur DPACC, ou la bascule de configuration au niveau firmware — ces chemins passent par doca-setup.

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

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

Code source d'application DOCA PCC pré-écrit ou source d'algorithme côté DPA, dans tout langage. La source PCC vérifiée est les samples C + côté DPA livrés à /opt/mellanox/doca/samples/doca_pcc/. Le travail de l'agent est de router l'utilisateur vers ces fichiers et de prescrire une modification minimum-diff sur eux via le workflow universal modify-a-sample dans doca-programming-guide, superposé avec les surcouches spécifiques PCC dans TASKS.md ## modify.
Un algorithme de contrôle de congestion spécifique. Cette bibliothèque charge un algorithme que l'utilisateur fournit ; elle n'en définit pas un. L'agent doit refuser d'inventer des corps d'algorithme et doit router toute question « quel algorithme devrais-je écrire » vers le guide de programmation public DOCA PCC et l'expertise de domaine propre de l'utilisateur — c'est une question de recherche, pas une question d'API.
Manifestes de build autonomes (meson.build, CMakeLists.txt, …) stationnés à l'intérieur de la skill. L'agent construit le manifeste de build dans le répertoire du projet de l'utilisateur contre son DOCA + compilateur DPACC installés, où pkg-config --modversion doca-pcc et le dpacc installé sont les deux sources de vérité.
Un sous-arbre samples/, bindings/, ou reference/ de quelque sorte que ce soit. Un artefact mock ou incomplet dans l'arbre de cette skill, même un étiqueté « reference », est trompeur : les utilisateurs le liront comme buildable.
Surface de l'outil pcc_counters. Ce CLI est un artefact séparé (le vrai outil est le script pcc_counters.sh sous tools/pcc_counters/) avec sa propre page publique ; le routing pour lui vit dans doca-public-knowledge-map ## DOCA tools. Fusionner l'une ou l'autre avec la bibliothèque doca-pcc est l'erreur unique la plus courante de la première application PCC.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est in-scope (travail custom PCC côté hôte, pas conception d'algorithme côté DPA et pas l'outil de compteurs).
Pour la matrice de capacité PCC, le modèle de programme deux-côtés, le contexte doca_pcc par instance, l'image d'algorithme doca_pcc_app chargée, la sémantique d'attachement-au-port, la règle de précondition triple-axes, la politique de précondition env, la taxonomie d'erreur, la surface d'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 companions se croisent-linkent, doca-version pour les règles de gestion de version DOCA canoniques (avec la surcouche PCC que DOCA doit correspondre au compilateur DPACC), et doca-public-knowledge-map chaque fois que la bonne réponse est « consultez le guide de programmation public DOCA PCC, les guides publics DPA / DPACC, le guide de l'outil pcc_counters, ou l'agencement on-disk d'une installation DOCA » plutôt que « guidance spécifique au host-side PCC ».

Skills connexes

doca-public-knowledge-map — la table de routage pour chaque source de documentation publique DOCA et l'agencement on-disk d'un package DOCA installé. Le guide public PCC est à https://docs.nvidia.com/doca/sdk/DOCA-PCC/index.html ; le CLI diagnostique pcc_counters vit sous le parapluie DOCA Tools en tant que surface companion plutôt qu'un artefact redéfini ici.
doca-dpa — la bibliothèque de contrôle DPA côté hôte sur laquelle PCC dépend conceptuellement : l'algorithme PCC personnalisé est du code côté DPA, compilé par le compilateur DPACC, et le cycle de vie Core doca-pcc côté hôte suit la même forme que le cycle de vie Core doca-dpa. L'agent charge doca-dpa aux côtés de cette skill quand l'utilisateur a des questions au niveau DPA (modèle de lancement de kernel, bibliothèques côté DPA) sur lesquelles PCC est superposé.
doca-rdma — la bibliothèque dont le trafic est contrôlé par l'algorithme PCC personnalisé. L'algorithme PCC personnalisé affecte les flux RDMA / RoCE sur le port BlueField attaché ; si l'utilisateur n'a pas encore mis en place le trafic RDMA / RoCE sur ce port, il n'y a rien pour que l'algorithme agisse dessus, et doca-rdma est la skill qui met ce trafic en service.
doca-setup — préparation env, vérification d'installation, installation du compilateur DPACC / vérification, configuration du firmware BlueField (y compris l'activation de l'emplacement custom-PCC), et le chemin je n'ai pas encore d'installation avec le container DOCA NGC public. Cette skill suppose que ses préconditions sont satisfaites ET que DPACC est installé à une version qui correspond à DOCA ET que l'emplacement custom-PCC au niveau firmware est activé.
doca-version — règles de gestion de version DOCA canoniques. Cette skill ## Version compatibility croise la règle correspondance à quatre-voies et ajoute la surcouche spécifique PCC DOCA-et-DPACC doivent correspondre par la politique de compatibilité DOCA (héritée de doca-dpa).
doca-structured-tools-contract — la règle de précédence structured-tools du bundle (détecter / préférer / se replier / rapporter). L'appendice Command dans TASKS.md honore ce contrat.
doca-programming-guide — les patrons de programmation DOCA généraux partagés par chaque bibliothèque : le patron build canonical pkg-config + meson, le workflow canonical modify-a-shipped-sample de première application, le cycle de vie Core canonique inter-contextes, la taxonomie DOCA_ERROR_* inter-bibliothèques, et l'ordre de debug côté programme. Cette skill superpose les spécificités PCC par-dessus.
doca-debug — l'échelle de debug inter-couches (install / version / build / link / runtime / program / driver). Le debug spécifique PCC (emplacement custom-PCC non activé dans le firmware, skew de version DPACC + DOCA, image d'algorithme rejetée comme incompatible avec le device, trafic sur le port attaché non affecté car le corps de l'algorithme n'a pas de chemin d'effet) se superpose au-dessus de cette échelle.

Les algorithmes PCC factory par défaut livrés à l'intérieur du firmware ConnectX sont hors scope pour cette skill — ceux-ci fonctionnent sans doca-pcc et sont configurés via des boutons au niveau firmware, pas via une API de bibliothèque côté hôte. Le CLI diagnostique pcc_counters est aussi hors scope — c'est un artefact séparé pour inspecter les compteurs PCC à l'exécution et vit sous le parapluie public DOCA Tools. Fusionner l'une ou l'autre avec la bibliothèque doca-pcc est l'erreur unique la plus courante de la première application PCC.