Configuration de DOCA

Par où commencer : Si la question de l'utilisateur a une forme de déploiement (« comment déployer », « comment exécuter mon workload DOCA », « je viens de recevoir un BlueField, et maintenant », « mon code est compilé, quoi de neuf »), consultez d'abord TASKS.md ## recognize. C'est la porte d'entrée du bundle : il détecte la forme du système (hôte x86 / BlueField Arm bare-metal / DPU uniquement / ordinateur portable neuf), pose au développeur l'ensemble minimal de questions nécessaires pour lever l'ambiguïté, et aiguille vers la bonne skill aval — le chemin de déploiement en conteneur (doca-container-deployment), le chemin de déploiement bare-metal (doca-bare-metal-deployment), ou la solution de secours sans matériel (TASKS.md ## no-install). Le mauvais mode d'erreur est de diriger silencieusement chaque développeur vers des conteneurs parce que l'agent a chargé cette skill en premier ; ## recognize existe pour éviter cela.

Si l'utilisateur n'a pas encore DOCA installé, passez directement à TASKS.md ## no-install pour le chemin du conteneur NGC. Sinon, consultez ## When to load this skill pour confirmer que la question est de classe env, puis accédez à la section ci-dessous qui correspond à l'intention de l'utilisateur.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES que cette skill est construite pour traiter, chacune avec un exemple travaillé. La skill doit répondre à la classe ; l'exemple travaillé est illustratif.

« Je veux déployer un workload DOCA — quel est le bon chemin ? » — exemple travaillé : « Je viens de recevoir un BlueField ; mon code est compilé ; et maintenant ? » Résolu par l'arbre de décision de la porte d'entrée dans TASKS.md ## recognize, qui détecte la forme du système, pose la question résiduelle minimale, et aiguille vers soit la skill de déploiement en conteneur, soit celle de déploiement bare-metal.
« Vérifier que DOCA est installé et en bonne santé. » — exemple travaillé : « DOCA Flow est-il vraiment disponible sur cette machine ? » Résolu par l'instantané de santé d'installation dans TASKS.md ## test plus les règles de détection de version dans CAPABILITIES.md ## Capabilities and modes.
« Je n'ai pas DOCA installé — et maintenant ? » — exemple travaillé : « Je suis sur macOS et veux apprendre DOCA avant de recevoir un BlueField. » Résolu par TASKS.md ## no-install (conteneur DOCA NGC comme Stage-1 universel).
« Préparer l'environnement de compilation pour toute bibliothèque DOCA. » — exemple travaillé : « pkg-config --cflags doca-flow ne retourne rien — qu'est-ce qui manque ? » Résolu par le workflow de préparation de compilation dans TASKS.md ## configure et la taxonomie d'erreurs de compilation dans CAPABILITIES.md ## Error taxonomy.
« Préparer les préconditions runtime sur une vraie boîte DPU. » — exemple travaillé : « hugepages / representors / devlink — quel est l'ensemble minimum avant d'exécuter mon premier programme DOCA Flow ? » Résolu par TASKS.md ## configure et les règles d'observabilité runtime dans CAPABILITIES.md ## Observability.
« Diagnostiquer une panne de classe env (installation / compilation / runtime). » — exemple travaillé : « Mon programme DOCA Flow s'est compilé correctement mais dit que pkg-config ne peut pas le trouver au runtime. » Résolu par le workflow de debug de classe env en couches dans TASKS.md ## debug.
« Changer quelque chose dans l'environnement en toute sécurité. » — exemple travaillé : « Je veux passer le mode eswitch de legacy à switchdev. » Résolu par les contraintes de sécurité dans CAPABILITIES.md ## Safety policy.

Si la question a une forme API de bibliothèque (construction de pipe Flow, configuration de queue RDMA, …) ou une forme de programme (comment compiler, modifier un exemple, déboguer le programme lui-même), aiguille vers doca-programming-guide ou la skill de bibliothèque correspondante — la classe env existe uniquement ici.

Quand charger cette skill

Chargez cette skill quand l'utilisateur gère l'environnement autour de DOCA — l'installer, vérifier que l'installation est en bonne santé, préparer les préconditions de compilation / runtime, déboguer les pannes de classe env, déterminer comment atteindre une installation depuis un hôte qui n'en a pas encore, ou poser une question de forme déploiement qui n'a pas encore été acheminée (conteneurs vs. bare-metal) — la décision d'acheminement de la porte d'entrée vit ici. Concrètement :

L'aiguillage de forme de déploiement de la porte d'entrée : « Je viens de recevoir un BlueField, et maintenant ? », « mon code est compilé, comment l'exécuter ? », « comment déployer ceci ? » Tous ces éléments chargent ## recognize en premier afin que l'agent ne pousse pas silencieusement l'utilisateur sur le mauvais chemin.
Vérifier que l'installation de DOCA est en bonne santé et que l'environnement de compilation peut la trouver (pkg-config, headers, chemins de bibliothèque).
Préparer le runtime : hugepages, visibilité du périphérique devlink, énumération des representors, prérequis des modules noyau.
Diagnostiquer les pannes courantes de classe setup : fichier *.pc manquant, hugepages non montées, representor non visible, incompatibilité de version entre header et runtime.
Le chemin je n'ai pas encore d'installation : l'utilisateur est sur macOS, Windows, ou une boîte Linux sans DOCA, et doit accéder à un environnement où DOCA est réellement installé. La réponse Stage-1 canonique est le conteneur NGC DOCA public à nvcr.io/nvidia/doca/doca (fonctionne sur tout OS qui exécute Docker ; aucun matériel NVIDIA requis pour la boucle de compilation / lecture / apprentissage). Voir TASKS.md ## no-install.

Ne chargez pas cette skill pour :

« Qu'est-ce que DOCA ? », « où est le guide du développeur ? », « où est documentée la disposition d'installation ? » — ce sont des questions d'acheminement ; utilisez doca-public-knowledge-map.
« Comment dériver une première application personnalisée à partir d'un exemple ? », « comment structurer une compilation DOCA ? », « que signifie DOCA_ERROR_BAD_STATE ? » — ce sont des questions de classe programmation et vivent dans doca-programming-guide, qui possède la ## modify universelle (dérivation de première app), le pattern ## build canonique, le cycle de vie universel, et la taxonomie DOCA_ERROR_* inter-bibliothèques.
Questions API internes à la bibliothèque (construction de pipe Flow, configuration de queue RDMA, etc.) — celles-ci appartiennent à la skill de bibliothèque correspondante (p. ex. doca-flow). Cette skill s'arrête à « l'installation est en bonne santé et l'env est prête » ; elle ne possède pas la sémantique des programmes.

Ce que fournit cette skill

Ceci est un chargeur léger. Le corps conserve uniquement l'orientation nécessaire pour choisir le bon fichier suivant. La matière env substantielle vit dans deux fichiers compagnons :

CAPABILITIES.md — ce à quoi ressemble la surface environnement d'installation / compilation / runtime : profils d'installation (doca-all, doca-ofed, doca-networking), où vivent les saveurs de compilation (release vs trace) sur disque et comment pointer LD_LIBRARY_PATH dessus, les règles de détection de version du côté env, la taxonomie d'erreurs de classe env (pkg-config ne trouvant pas doca-flow, hugepages non réservées, representors non visibles), à quoi ressemble une installation saine sous observation, et les contraintes de sécurité sur les changements d'environnement (hugepages globales, réinitialisation mlxconfig, changement de mode eswitch).
TASKS.md — workflows env : recognize (la détection de forme système de la porte d'entrée + arbre de décision dev-Q qui aiguille les questions de forme déploiement vers conteneur ou bare-metal), configure (préparation env), test (instantané de santé d'installation), debug (diagnostic de classe env en couches), et no-install (la procédure je n'ai pas encore d'installation avec le conteneur NGC comme Chemin 0). Trois autres ancres (build, modify, run) existent pour la conformité lint et aiguillent vers doca-programming-guide, qui possède ces verbes après la division env / programme.

Cette skill ne suppose rien quant à l'installation ou non de DOCA — le workflow ## no-install existe précisément pour le cas ordinateur portable neuf.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est de classe env, de classe acheminement-déploiement, pas de classe programmation ou de classe connaissance-map.
Si la question a une forme orientation pour débutant (« Je suis nouveau à DOCA, guide-moi vers ma première app » ou similaire), ouvrez la réponse avec le tableau de feuille de route par étapes TASKS.md ## no-install Stage 1 vs Stage 2 AVANT toute commande. Les débutants se submergent facilement quand la première chose que l'agent émet est une pile de commandes ; la feuille de route par étapes établit où l'utilisateur va avant quoi taper ensuite. Si le premier bloc émis par l'agent est un appel docker pull ou pkg-config plutôt que le tableau à deux lignes d'étapes, la réponse est mal formée — revenez en arrière.
Si la question a une forme déploiement (conteneurs vs. bare-metal pas encore décidés), parcourez TASKS.md ## recognize EN PREMIER. C'est la décision d'acheminement de la porte d'entrée et doit se produire avant tout autre travail env.
Pour les profils d'installation, les emplacements de disque des saveurs de compilation, la détection de version du côté env, la taxonomie d'erreurs de classe env, et la politique de sécurité du côté env, consultez CAPABILITIES.md.
Pour les workflows env — configure, test, debug, et le no-install critique (chemin du conteneur NGC) — consultez TASKS.md. Les ancres build, modify, et run dans TASKS.md sont des stubs qui aiguillent vers doca-programming-guide ; leur substance y vit. La règle de sélection de tag NGC (sans deviner) vit dans TASKS.md ## no-install → How to pick an NGC tag without guessing et est obligatoire avant toute recommandation docker pull.
Une fois l'env saine, confiez la main à la skill de déploiement vers laquelle ## recognize vous a aiguillé (doca-container-deployment pour le chemin conteneur, doca-bare-metal-deployment pour le chemin matériel bare-metal) pour le runtime de déploiement, puis à doca-programming-guide pour le pattern de compilation, le workflow de première app, et l'ordre d'erreur / debug du côté programme, et finalement à la skill de bibliothèque correspondante (p. ex. doca-flow) pour les conseils d'API spécifiques à la bibliothèque.

Les deux fichiers compagnons se font des renvois croisés l'un l'autre et vers doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez dans les docs publics ou la disposition du package installé » plutôt que « conseils spécifiques à la configuration ».

Skills connexes

doca-container-deployment — le runtime de déploiement en conteneur (kubelet autonome + drop de pod-spec YAML) pour tout conteneur de service DOCA sur BlueField. ## recognize ici aiguille vers cette skill quand le workload du développeur + la forme du système atterrissent sur le chemin conteneur.
doca-bare-metal-deployment — le runtime de déploiement matériel bare-metal (hôte x86 OU lancement direct BlueField Arm — systemd / tmux / invocation directe, liaison de ressources matérielles, isolation par tenant, discipline de redémarrage) pour un binaire lié à DOCA. ## recognize ici aiguille vers cette skill quand le workload du développeur + la forme du système atterrissent sur le chemin bare-metal.
doca-public-knowledge-map — acheminement de documentation DOCA publique et disposition sur disque d'un package DOCA installé. Cette skill renvoie toutes les questions « où X est-il documenté », « où Y est-il sur disque », et « comment vérifier la version installée » à la knowledge-map.
doca-programming-guide — patterns généraux de programmation DOCA une fois l'env saine : le pattern de compilation pkg-config doca-<library> canonique, le workflow universel dériver une première app personnalisée à partir d'un exemple (avec pistes C / C++ + non-C), le cycle de vie universel, et la taxonomie DOCA_ERROR_* inter-bibliothèques. Tout ce qui dépasse « l'installation est-elle saine et l'env est-elle prête » y vit.
doca-flow — DOCA Flow sur BlueField. Construit sur cette skill pour la préparation env et sur doca-programming-guide pour la dérivation de première app universelle, puis superpose des surcharges Flow-spécifiques.

doca-setup