Algorithme DOCA PCC ZTR RTTCC

Par où commencer : Cette compétence 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 (un appareil de génération BlueField-3 selon le README), que le firmware BlueField a le slot PCC personnalisé activé, que le compilateur DPACC est installé dans une version correspondante selon la politique de compatibilité DOCA, et que l'utilisateur effectue un déploiement pratique de l'algorithme de référence ZTR RTTCC livré avec DOCA sur un port BlueField qui porte déjà du trafic RoCE-v2 — c'est-à-dire soit le déployer comme baseline sans configuration requise, soit régler ses paramètres documentés, soit l'évaluer par rapport à un algorithme personnalisé que l'utilisateur envisage d'écrire. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (installer / configurer / compiler / modifier / exécuter / tester / déboguer / utiliser) ; ouvrez CAPABILITIES.md quand la question est que peut exprimer l'algorithme, quelles sont ses variantes et paramètres, qu'est-ce qu'il livre ou non. Si l'utilisateur n'a pas encore installé DOCA, accédez d'abord à doca-setup ; si l'utilisateur n'a pas encore mis en place le framework doca-pcc côté hôte, accédez d'abord à doca-pcc (cet algorithme est une bibliothèque consommée par le framework PCC, pas un programme autonome) ; si l'utilisateur veut seulement inspecter les compteurs PCC à l'exécution sans changer l'algorithme en cours, accédez à doca-pcc-counters ; si l'utilisateur veut écrire son propre algorithme à partir de zéro, cela concerne la bibliothèque doca-pcc plus le guide public de programmation PCC — cette compétence concerne spécifiquement l'algorithme de référence livré.

Exemples de questions que cette compétence répond bien

Les CLASSES de questions ZTR RTTCC que cette compétence est construite pour répondre, chacune avec un exemple travaillé. L'agent devrait traiter la classe comme la partie essentielle — l'exemple travaillé est une seule instance.

« L'algorithme de référence ZTR RTTCC est-il la bonne baseline pour mon déploiement, ou dois-je écrire un algorithme personnalisé ? » — exemple travaillé : « J'ai un BlueField-3 portant du trafic RoCE-v2 de production en provenance d'un cluster GPU ; l'algorithme livré est-il une bonne valeur par défaut ou ai-je besoin de logique personnalisée ? ». Répondu par la règle de décision dans CAPABILITIES.md ## Capabilities and modes (« quand utiliser la référence par rapport au personnalisé ») + les préconditions env dans TASKS.md ## install.
« Comment intégrer l'algorithme livré dans l'application DOCA PCC qui s'exécute déjà sur mon hôte ? » — exemple travaillé : « /opt/mellanox/doca/applications/pcc compile déjà à partir de sources d'exemple ; qu'est-ce que je change pour que le rappel algo utilisateur envoie à doca_pcc_dev_ztr_rttcc_algo sous un slot algo choisi ? ». Répondu par la séquence d'intégration dans CAPABILITIES.md ## Capabilities and modes + les édits sur place dans TASKS.md ## modify.
« Quelle variante de l'algorithme je reçois — RTT-CC vanilla, mode migration de chemin, mode taux RX, multichemin, multichemin avec crédits, fenêtre-sans-probe ? » — exemple travaillé : « la bibliothèque livrée expose un symbole public doca_pcc_dev_ztr_rttcc_algo mais la source côté appareil livre plusieurs variantes ; comment je sais laquelle je reçois et comment je choisis une autre ? ». Répondu par le tableau des variantes dans CAPABILITIES.md ## Capabilities and modes.
« Comment je confirme que l'algorithme module vraiment mon trafic RDMA / RoCE, et qu'il ne fait que se charger ? » — exemple travaillé : « J'ai suivi les étapes d'intégration ; l'application démarre ; comment je sais que l'algorithme façonne les flux en charge ? ». Répondu par la surface d'observabilité dans CAPABILITIES.md ## Observability + la boucle de surveillance des compteurs dans TASKS.md ## test qui accède à doca-pcc-counters.
« Quels paramètres ajustables l'algorithme expose-t-il, et comment je les change depuis l'hôte sans reconstruire l'image côté DPA ? » — exemple travaillé : « ma charge de travail est plus sensible à la latence que le profil par défaut ne l'assume — quel paramètre je dois ajuster ? ». Répondu par la surface de paramètres dans CAPABILITIES.md ## Capabilities and modes + le flux de travail doca_pcc_dev_set_ztr_rttcc_params dans TASKS.md ## use.
« Que signifie ce DOCA_PCC_DEV_STATUS_FAIL ou DOCA_ERROR_* d'un appel doca_pcc_dev_ztr_rttcc_* et quelle couche l'a causé ? » — exemple travaillé : « mon rappel d'init retourne DOCA_PCC_DEV_STATUS_FAIL au premier lancement ». Répondu par l'overlay algorithme sur la taxonomie PCC côté hôte dans CAPABILITIES.md ## Error taxonomy + l'échelle en couches dans TASKS.md ## debug qui escalade via doca-pcc et doca-debug.

Public cible

Cette compétence sert les développeurs externes exploitant un DPU de classe BlueField-3 qui veulent déployer l'algorithme PCC de référence livré par NVIDIA sur du trafic RoCE-v2, OU qui l'évaluent par rapport à un algorithme personnalisé qu'ils envisagent d'écrire. L'algorithme de référence est sans contact par conception — la baseline sans configuration requise — et le cas d'usage canonique est de le placer sur un port et de confirmer qu'il façonne correctement les flux en congestion. Ce n'est pas pour les développeurs NVIDIA contribuant à l'algorithme lui-même, ni pour les utilisateurs qui veulent la théorie générale de la programmation PCC (accédez via le guide public de programmation PCC DOCA), ni pour les utilisateurs qui veulent seulement inspecter les compteurs PCC (accédez à doca-pcc-counters).

Portée du langage. L'algorithme est livré comme une bibliothèque côté DPA (module pkg-config doca-pcc-ztr-rttcc-algo) plus un header public doca_pcc_dev_ztr_rttcc_algo.h que les unités de traduction côté DPA incluent. Le binaire de l'algorithme livré est la bibliothèque statique libdoca_pcc_ztr_rttcc_algo_dev.a selon le README ; l'unité de traduction côté appareil qui la consomme est du C compilé par DPACC. Le côté hôte qui pilote le contexte PCC vient de doca-pcc ; cette bibliothèque n'ajoute PAS une surface côté hôte au-delà des helpers côté hôte (aussi livrés comme libdoca_pcc_ztr_rttcc_algo.{a,so} selon le README) que le framework doca-pcc lie. Les wrappers côté hôte dans d'autres langages autour de doca-pcc peuvent piloter cet algorithme via le même cycle de vie décrit dans doca-pcc ; l'intégration côté DPA reste toujours du C via DPACC.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur effectue un déploiement pratique, un réglage ou une évaluation de l'algorithme de référence ZTR RTTCC livré avec DOCA sur un port BlueField portant du trafic RoCE-v2, dans n'importe quel langage hôte plus l'unité de traduction côté DPA compilée par dpacc. Concrètement :

Décider si l'algorithme livré est la bonne baseline pour la charge de travail RoCE-v2 de l'utilisateur, ou si l'utilisateur a besoin d'un algorithme personnalisé.
Intégrer l'algorithme dans l'exemple d'application DOCA PCC en corrigeant les rappels user-algo / user-init / user-set-algo-params selon les étapes que le README livré documente.
Choisir laquelle des variantes documentées de l'algorithme (vanilla, migration de chemin, taux RX, taux RX + PM, multichemin, multichemin + crédits, fenêtre-sans-probe) correspond à l'intention de l'utilisateur — et exposer que la surface publique ne livre qu'un seul symbole (doca_pcc_dev_ztr_rttcc_algo) ; les variantes vivent dans la source côté DPA que l'utilisateur compile.
Régler les paramètres fixés par l'hôte que l'algorithme expose (selon la liste de paramètres dans doca_pcc_dev_ztr_rttcc_algo.h et le doca_pcc_dev_set_ztr_rttcc_params livré).
Observer si l'algorithme en cours module vraiment les flux RoCE-v2 en charge (accédez à doca-pcc-counters pour le côté inspection en lecture seule).
Décider quand remplacer l'algorithme livré par un personnalisé parce que les exigences de cible de latence, politique d'équité, ou comportement de convergence divergent de ce que la référence fournit.

Ne pas charger cette compétence pour l'orientation générale DOCA ; pour le cycle de vie côté hôte doca-pcc (accédez à doca-pcc) ; pour écrire un algorithme personnalisé à partir de zéro (accédez à doca-pcc et au guide de programmation PCC public via doca-public-knowledge-map) ; pour l'inspection des compteurs PCC en lecture seule (accédez à doca-pcc-counters) ; ou pour les algorithmes PCC livrés par défaut du firmware qui prédate entièrement Programmable Congestion Control (pas de code côté hôte, pas de compilation DPACC — c'est un chemin firmware uniquement accédé via doca-public-knowledge-map).

Ce que cette compétence fournit

C'est un chargeur mince. Le corps ne garde que l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique à l'algorithme vit dans deux fichiers complémentaires :

CAPABILITIES.md — ce que l'algorithme ZTR RTTCC livré exprime sur cette version + cette génération BlueField + ce firmware : la surface API DPA-side publique (doca_pcc_dev_ztr_rttcc_init, doca_pcc_dev_ztr_rttcc_algo, doca_pcc_dev_set_ztr_rttcc_params, doca_pcc_dev_ztr_rttcc_get_param_num, doca_pcc_dev_ztr_rttcc_get_counter_num, doca_pcc_dev_ztr_rttcc_get_num_of_histograms), les variantes documentées (vanilla / migration de chemin / taux RX / multichemin / fenêtre-sans-probe — choisissez-en une à la compilation côté DPA), la relation au framework doca-pcc côté hôte (ceci est un corps d'algorithme que le framework charge), la relation à l'outil doca-pcc-counters (qui est la surface d'inspection canonique), la surface de paramètres et compteurs de l'algorithme (signal de congestion basé sur RTT, blocs de paramètres par fonctionnalité), la taxonomie d'erreur dans DOCA_PCC_DEV_STATUS_OK / _FAIL, et la politique de sécurité.
TASKS.md — des flux de travail étape par étape pour les verbes d'algorithme dans la portée : install, configure, build, modify, run, test, debug, use. Plus un bloc Deferred task verbs qui pointe les questions hors de portée à la bonne compétence suivante.

La compétence suppose que DOCA + le compilateur DPACC + le framework doca-pcc côté hôte sont déjà installés ; le BlueField est une génération qui expose le processeur DPA (l'algorithme s'exécute sur le DPA) ; le firmware BlueField a le slot PCC personnalisé activé (hérité de doca-pcc CAPABILITIES.md ## Safety policy) ; et le port BlueField que l'algorithme va moduler porte du trafic RoCE-v2 réellement en cours d'exécution (l'algorithme module du trafic RDMA / RoCE existant — sans trafic, il n'y a rien pour lui à faire).

Ce que cette compétence ne livre pas délibérément

Cette compétence est une guidance pour agent, pas un bundle d'exemples ou de modèles. Pour garder la limite nette, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Le corps de l'algorithme lui-même, dans n'importe quel langage. L'algorithme livré est la bibliothèque statique libdoca_pcc_ztr_rttcc_algo_dev.a (plus les helpers côté hôte) installée par le package DOCA hôte correspondant selon le README. La tâche de l'agent est de router l'utilisateur vers la bibliothèque et le header installés (doca_pcc_dev_ztr_rttcc_algo.h) et de prescrire les édits sur place documentés dans le README sur la source de l'exemple DOCA PCC livré, pas d'écrire l'algorithme.
Une application PCC autonome. L'application DOCA PCC qui héberge cet algorithme est l'exemple C livré sous /opt/mellanox/doca/applications/pcc/ (selon le README). La tâche de l'agent est de prescrire les modifications diff minimum que le README documente et de guider l'utilisateur à travers la reconstruction — pas d'écrire une application parallèle.
Une description du comportement de chaque variante interne. La source côté DPA livre plusieurs variantes (vanilla, migration de chemin, taux RX, multichemin, multichemin + crédits, fenêtre-sans-probe). L'agent nomme l'ensemble de variantes, dit laquelle est accessible via le symbole public sur cette installation, et route les questions de conception d'algorithme au guide de programmation PCC public via doca-public-knowledge-map. Il ne redéfinit pas le comportement mathématique de chaque variante.
Un tutoriel spécifique sur un algorithme de contrôle de congestion. Théorie du contrôle de congestion, analyse d'équité RoCE-v2, réglage spécifique à la charge de travail — hors de portée. Accédez à l'expertise propre du domaine de l'utilisateur et au guide DOCA PCC public.

Ordre de chargement

Lisez ce SKILL.md d'abord pour confirmer que la question de l'utilisateur est dans la portée (déploiement / réglage / évaluation de l'algorithme de référence livré, pas conception d'algorithme à partir de zéro et pas inspection des compteurs en lecture seule).
Pour la matrice de capacités d'algorithme, la surface API DPA-side publique, l'ensemble de variantes, la surface de paramètres et compteurs, la relation du framework doca-pcc côté hôte, la relation côté inspection doca-pcc-counters, la taxonomie d'erreur, la surface d'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
Pour les flux de travail étape par étape — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Les deux fichiers complémentaires se croisent mutuellement, doca-pcc pour le cycle de vie PCC côté hôte qui charge cet algorithme, doca-pcc-counters pour le côté inspection des compteurs en lecture seule pour valider que l'algorithme module le trafic, doca-dpa pour le modèle de programme deux-côtés côté DPA et la discipline du compilateur DPACC, doca-version pour les règles canoniques de gestion des versions DOCA (avec l'overlay DPACC hérité de doca-dpa et doca-pcc), et doca-public-knowledge-map chaque fois que la bonne réponse est « consultez le guide de programmation PCC public DOCA ou la disposition d'installation sur disque ».

Compétences connexes

doca-pcc — la bibliothèque de contrôle PCC côté hôte. Cet algorithme est chargé DANS un contexte doca_pcc que doca-pcc configure ; le cycle de vie côté hôte (créer / configurer / démarrer / arrêter / détruire doca_pcc, l'image d'algorithme doca_pcc_app, la sémantique attach-to-port) est possédé par doca-pcc. Cette compétence prescrit seulement l'intégration d'algorithme côté DPA au-dessus.
doca-pcc-counters — l'outil CLI de diagnostic en lecture seule pour les compteurs PCC au port. La vérification canonique « l'algorithme module-t-il vraiment le trafic » passe par l'outil de compteur ; cette compétence nomme les compteurs que l'algorithme émet (CNP / NACK / AI / HAI / décrémentation / compteurs de bande RTT selon le header public) et route le flux de travail d'inspection à la compétence d'outil.
doca-dpa — la bibliothèque de contrôle DPA côté hôte. L'algorithme s'exécute sur le DPA, compilé par DPACC ; la règle du modèle programme-deux-côtés et l'overlay d'une version DOCA-et-DPACC qui correspond, hérité d'ici, s'appliquent.
doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique (le guide de programmation PCC DOCA à https://docs.nvidia.com/doca/sdk/doca-pcc/index.html ; le guide d'application PCC DOCA ; la politique de compatibilité DOCA) et la disposition sur disque d'un package DOCA installé.
doca-setup — préparation de l'env, vérification d'installation, installation / vérification du compilateur DPACC, configuration du firmware BlueField (incluant l'activation du slot PCC personnalisé), et le chemin je n'ai pas d'installation encore avec le conteneur DOCA NGC public. Cette compétence suppose que ses préconditions sont satisfaites ET que DPACC est installé dans une version qui correspond à DOCA ET que le slot PCC personnalisé au niveau firmware est activé.
doca-version — règles de gestion des versions DOCA canoniques. Le ## Version compatibility de cette compétence relie croisement la règle de correspondance quatre-voies plus l'overlay DOCA-et-DPACC hérité de doca-pcc.
doca-structured-tools-contract — la règle de précédence 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 — modèles généraux de programmation DOCA. Cette compétence assemble des overlays spécifiques à l'algorithme au-dessus des patterns universels de compilation, modification d'un exemple livré, et cycle de vie Core.
doca-debug — échelle de débogage transversale. Le débogage spécifique à l'algorithme (l'algorithme est chargé mais les compteurs ne bougent pas ; l'algorithme ne parvient pas à s'initialiser ; l'algorithme module le trafic trop agressivement / trop doucement pour la charge de travail) assemble au-dessus de cette échelle.
doca-hardware-safety — méta-politique de sécurité matérielle transversale. Parce que l'algorithme module les flux RoCE-v2 de production sur un port BlueField, les règles d'inventaire avant vol, replica-first, et rollback de la méta-politique s'appliquent via l'overlay ## Safety policy de cette compétence.