Gestion DOCA

Par où commencer : Cette compétence suppose que DOCA est déjà installé et que l'utilisateur fait un travail de gestion de plan de gestion sur un appareil BlueField / ConnectX — généralement un outil de gestion de flotte ou d'orchestration qui doit interroger ou modifier l'état au niveau de l'appareil par programmation. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (installer / configurer / construire / modifier / exécuter / tester / déboguer / utiliser) ; ouvrez CAPABILITIES.md quand la question porte sur ce que doca-mgmt peut exprimer sur cette version — le modèle de contexte de gestion, l'échelle de portée des commandes brutes, les surfaces de sous-domaine (caps-general, cc-global-status, diagnostics- data, icm-quota), la compatibilité des versions, et l'overlay de sécurité. Si l'utilisateur n'a pas encore installé DOCA, acheminez-le d'abord vers doca-setup.

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

Les CLASSES de questions du plan de gestion auxquelles cette compétence est construite pour répondre, chacune avec un exemple traité. L'agent doit traiter la classe comme la pièce portante — l'exemple traité est une seule instance.

« doca-mgmt est-il vraiment la bonne surface, ou veux-je telemetry / bench / caps ? » — exemple traité : « Je construis un outil d'inventaire de flotte — utilise-je doca-mgmt pour interroger chaque capacité data-direct du BlueField, ou doca-telemetry, ou doca_caps ? ». Répondu par la règle de sélection plan de gestion vs plan d'observabilité vs CLI en lecture seule dans CAPABILITIES.md ## Capabilities and modes tableau de sélection de surface.
« Comment configurer un contexte de gestion sur un appareil (et un representor) ? » — exemple traité : « Ouvrez un doca_mgmt_dev_ctx sur l'appareil, puis un doca_mgmt_dev_rep_ctx sur un representor VF spécifique pour la programmation caps-general ». Répondu par le cycle de vie du contexte de gestion dans CAPABILITIES.md ## Capabilities and modes
- la promenade de configuration dans TASKS.md ## configure.
« Comment interroger une capacité d'appareil — disons, s'il supporte data-direct ? » — exemple traité : « Créez un handle caps-general, appelez doca_mgmt_device_caps_general_get sur le contexte representor, lisez le flag data-direct ». Répondu par le modèle de requête de capacité dans CAPABILITIES.md ## Capabilities and modes
- l'étape de test dans TASKS.md ## test.
« Comment modifier en toute sécurité un flag de feature au niveau de l'appareil ? » — exemple traité : « Basculez data_direct sur un representor ; capturez l'état pré-, écrivez, vérifiez, préparez la restauration ». Répondu par le flux de travail apply-with-rollback dans TASKS.md ## modify en couches sur la métapolitique de sécurité matérielle au niveau du bundle référencée depuis CAPABILITIES.md ## Safety policy.
« Qu'est-ce que la portée doca_mgmt_raw_cmd et quelle portée dois-je utiliser ? » — exemple traité : « J'ai un opcode documenté par le vendeur pour une requête DEBUG_READ_ONLY — quelle portée cela nécessite-t-il et quel est le rayon d'explosion ? ». Répondu par l'échelle de portée de commande dans CAPABILITIES.md ## Capabilities and modes
- le verbe de commande brute dans TASKS.md ## use.
« Qu'est-ce que ce DOCA_ERROR_* d'un appel doca_mgmt_* signifie et quelle couche l'a causé ? » — exemple traité : « DOCA_ERROR_IO_FAILED de doca_mgmt_raw_cmd ». Répondu par l'overlay mgmt sur la taxonomie multibibliotheèque dans CAPABILITIES.md ## Error taxonomy
- l'échelle en couches dans TASKS.md ## debug qui remonte vers doca-debug et doca-hardware-safety quand la cause est un changement d'état de l'appareil.

Public

Cette compétence sert les développeurs externes qui construisent des outils de gestion de flotte, d'orchestration, ou d'administration d'appareil qui interrogent et modifient par programmation l'état au niveau de l'appareil BlueField / ConnectX — c'est-à-dire, des utilisateurs dont le code appelle doca_mgmt_* (directement en C/C++, ou via FFI/bindings depuis une autre langue) pour inspecter les capacités de l'appareil, basculer des flags de feature au niveau de l'appareil, interroger des compteurs de diagnostics, définir des quotas ICM, ou émettre des commandes de contrôle de firmware brutes. L'appelant canonique est un agent de gestion de flotte qui parcoure chaque BlueField dans un data center et applique un diff d'état désiré. Cette compétence n'est pas pour les développeurs NVIDIA contribuant à DOCA Management lui-même, et ce n'est pas la bonne surface pour les benchmarks de performance en direct ou l'observabilité basée sur les flux — ces surfaces appartiennent à doca-bench, doca-telemetry, et doca-telemetry-exporter.

Portée du langage

DOCA Management est livré comme une bibliothèque C avec le nom du module pkg-config de doca-mgmt. La surface de la bibliothèque est C ; les exemples livrés lors d'une installation réelle (s'ils sont présents) sont en C. Les consommateurs C et C++ sont le cas canonique et les flux de travail dans TASKS.md supposent ce chemin. Les consommateurs d'autres langues (Rust, Go, Python, …) consomment la même bibliothèque *.so via FFI ou des bindings spécifiques au langage ; la contribution de cette compétence dans ce cas est de maintenir le cycle de vie du contexte de gestion, l'échelle de portée de commande, le modèle de requête de capacité, la règle de gestion des versions, et l'overlay de sécurité indépendants du langage, et d'acheminer l'agent vers l'ABI C public comme la surface faisant autorité que tout wrapper appellera éventuellement. Cette compétence n'authore pas de wrappers dans aucune langue.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur fait du travail DOCA Management pratique sur un hôte avec un ou plusieurs appareils BlueField / ConnectX. Concrètement :

Configurer un doca_mgmt_dev_ctx sur un doca_dev pour inspecter ou modifier l'état au niveau de l'appareil.
Configurer un doca_mgmt_dev_rep_ctx sur un doca_dev_rep (ou via doca_mgmt_dev_rep_ctx_create_by_pci_addr quand le representor n'est pas disponible) pour inspecter ou modifier une configuration VF / function-level.
Interroger les capacités générales d'un appareil via doca_mgmt_device_caps_general_* (support data-direct et attributs similaires au niveau de l'appareil).
Programmer les capacités générales d'un representor via le même chemin set.
Interroger ou modifier le statut global du contrôle de congestion via doca_mgmt_cc_global_status_* (type de protocole RP / NP, priorité, activer / désactiver).
Modifier ou interroger les données de diagnostics multi-domaines via doca_mgmt_diagnostics_data_* sur un appareil spécifique.
Définir les limites de quota ICM par appareil ou par representor via doca_mgmt_icm_quota_* et lire l'allocation actuelle / max-reached.
Émettre une doca_mgmt_raw_cmd sur le point de terminaison de contrôle du firmware de l'appareil, en choisissant le bon enum doca_mgmt_cmd_scope pour le rayon d'explosion de l'opération.
Déboguer un DOCA_ERROR_* retourné par un appel doca_mgmt_* et décider si la cause est une erreur de configuration, un bug de commande du cycle de vie, une capacité manquante sur l'appareil, un échec d'ioctl fwctl, ou un rejet côté firmware.

Ne pas charger cette compétence pour l'orientation générale de DOCA, l'installation de DOCA lui-même, les benchmarks de performance en direct, ou la télémétrie basée sur les flux. Pour cela, utilisez doca-public-knowledge-map, doca-setup, doca-bench, et doca-telemetry respectivement.

Ce que cette compétence fournit

C'est un mince chargeur. Le corps maintient seulement l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel spécifique à la gestion substantiel vit dans deux fichiers de compagnon :

CAPABILITIES.md — ce que doca-mgmt peut exprimer sur cette version : le modèle d'objet du contexte de gestion (doca_mgmt_dev_ctx + doca_mgmt_dev_rep_ctx), l'échelle de portée des commandes brutes (DOCA_MGMT_CMD_SCOPE_CONFIGURATION, DOCA_MGMT_CMD_SCOPE_DEBUG_READ_ONLY, DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE, DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE_FULL), les surfaces de sous-domaine (caps-general, cc-global-status, diagnostics-data, icm-quota) avec leurs portes de requête de capacité, la politique de l'ensemble de symboles EXPERIMENTAL (chaque symbole public doca_mgmt_* est marqué EXPERIMENTAL), l'overlay mgmt sur la taxonomie multibibliotheèque de DOCA_ERROR_*, la surface d'observabilité (capture pré-état + re-requête post-écriture), et l'overlay de sécurité par artefact sur la métapolitique de sécurité matérielle au niveau du bundle.
TASKS.md — flux de travail étape par étape pour les huit verbes en scope : install, configure, build, modify, run, test, debug, use. Plus un bloc Deferred task verbs qui pointe les questions hors de portée vers la compétence suivante appropriée.

Cette compétence suppose un hôte ou un BlueField où DOCA est déjà installé au emplacement standard et l'utilisateur a les privilèges que son profil d'installation public attend (les opérations du plan de gestion nécessitent généralement root ou une capacité d'administration d'appareil équivalente). Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup.

Ce que cette compétence ne livre intentionnellement pas

Cette compétence est un guide d'agent, pas un bundle de samples ou de templates. Pour maintenir la limite claire, elle ne contient intentionnellement pas — et les pull requests ne doivent pas ajouter :

Code source d'application DOCA Management pré-écrit, dans aucune langue. Le code du plan de gestion touche l'état de l'appareil et une mauvaise écriture peut mettre l'appareil hors ligne ; l'authorer à partir de prose de documentation, en particulier sur un ensemble de symboles EXPERIMENTAL dont la forme peut changer entre les versions, est interdit par cette compétence. Le travail de l'agent est d'acheminer l'utilisateur vers du code de référence vérifié (les samples DOCA livrés sur l'ensemble de paquets installés sont les exemples traités canoniques) et de prescrire une modification de diff minimal via le flux de travail universel modify-a-sample dans doca-programming-guide.
Manifestes de construction autonomes garés à l'intérieur de la compétence. L'agent construit le manifeste de construction dans le répertoire du projet de l'utilisateur par rapport au DOCA installé de l'utilisateur, où pkg-config --modversion doca-mgmt est la source de la vérité.
Catalogues d'opcodes de commande brute. Les champs d'entrée et de sortie d'une doca_mgmt_raw_cmd sont spécifiques à l'appareil / firmware ; la compétence nomme la portée d'une classe de commande et la discipline que l'agent applique (capture pré-état, échelle de portée, chemin de restauration) mais elle ne liste PAS les opcodes — ceux-ci sont de la documentation du vendeur / appareil et sont consultés via doca-public-knowledge-map.
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artefact fictif ou incomplet dans l'arbre de cette compétence, même étiqueté « reference », est trompeur : les utilisateurs le liront comme buildable.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope.
Pour le modèle d'objet du contexte de gestion, l'échelle de portée de commande brute, les surfaces de sous-domaine, la compatibilité des versions, la taxonomie des erreurs, l'observabilité, et l'overlay de sécurité par artefact, 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 de compagnon font des renvois croisés l'un vers l'autre et vers doca-public-knowledge-map chaque fois que la bonne réponse est « consultez-la dans les docs publiques ou la disposition du paquet installé » plutôt que « guidance spécifique à mgmt ».

Compétences connexes

doca-hardware-safety — la métapolitique de sécurité matérielle au niveau du bundle. Parce que doca-mgmt est la surface à travers laquelle les agents modifient le plus couramment l'état de l'appareil par programmation, l'overlay de sécurité dans CAPABILITIES.md fait renvoi croisé à la métapolitique de manière portante et l'agent remonte l'échelle de sécurité matérielle chaque fois qu'une écriture est recommandée.
doca-telemetry et doca-telemetry-exporter — les surfaces d'observabilité pour la télémétrie en flux à partir de l'appareil. Utilisez celles-ci quand l'utilisateur veut des métriques en direct ; utilisez doca-mgmt quand l'utilisateur veut une interrogation ou modification programmatique à un moment donné.
doca-caps — l' outil CLI en lecture seule pour inspecter les capacités de l'appareil. Utilisez l'outil quand l'utilisateur veut un snapshot interactif ; utilisez doca-mgmt quand l'utilisateur veut les mêmes informations via l'API C dans un outil de flotte.
doca-bench — l'outil de benchmarking de performance en direct. Hors scope pour doca-mgmt ; la compétence nomme la limite.
doca-pcc et doca-pcc-counters — contrôle de congestion programmable. La surface doca_mgmt_cc_global_status_* de doca-mgmt est le contrôle du plan de contrôle activer/désactiver global + sélection de protocole qui se superpose à la surface de CC programmable plus profonde détenue par doca-pcc.
doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un paquet DOCA installé.
doca-setup — préparation de l'env, vérification de l'installation, et le chemin je n'ai pas d'installation encore avec le conteneur DOCA NGC public.
doca-programming-guide — motifs de programmation DOCA généraux partagés par chaque bibliothèque : le motif de construction canonique pkg-config + meson, le flux de travail universal modify-a-shipped-sample de première application, la taxonomie multibibliotheèque DOCA_ERROR_*. Cette compétence ajoute les spécificités du plan de gestion par-dessus.
doca-debug — l'échelle de debug transversale. Les overlays de debug spécifiques à la gestion par-dessus.
doca-version — la détection de version / règle de correspondance quadruple sur laquelle chaque ancre de ## Version compatibility par artefact est construite. Cette compétence cite seulement l'overlay spécifique à la gestion.
doca-structured-tools-contract — les contrats de schéma JSON pour les helpers structurés préférés par l'agent ; le ## Command appendix dans TASKS.md en dépend d'abord avant de retomber sur la chaîne manuelle.