Déploiement bare-metal DOCA

Par où commencer : Cette skill est le cœur du bundle pour exploiter une application binaire liée à DOCA directement sur le matériel — pas de conteneur, pas de kubelet, pas de manifeste de pod statique. C'est l'équivalent de doca-container-deployment pour le chemin sans conteneur. Si l'utilisateur possède un binaire lié à DOCA qu'il a construit (selon le workflow canonique dans doca-programming-guide) et qu'il souhaite savoir comment l'exécuter correctement sur l'hôte ou sur les cœurs Arm BlueField, ouvrez TASKS.md et commencez par ## configure. Si la question porte sur la forme du runtime bare-metal et quel est le contrat de déploiement, commencez par CAPABILITIES.md. Si l'utilisateur n'est pas encore sûr que la topologie de son système cible corresponde au chemin conteneur ou bare-metal, acheminez l'étape de reconnaissance vers doca-setup d'abord ; revenez ici uniquement une fois que le chemin bare-metal est confirmé.

Public

Cette skill s'adresse aux développeurs et opérateurs DOCA externes qui disposent d'un binaire d'application lié à DOCA qu'ils ont construit et souhaitent l'exécuter directement sur le matériel — c'est-à-dire les personnes qui possèdent déjà :

• un binaire d'application lié à DOCA qu'ils ont construit selon doca-programming-guide ## build,
• une vraie NIC BlueField et un hôte qui communique avec elle (le chemin host x86 — l'installation DOCA sur l'hôte communique avec la NIC BlueField via PCIe), OU une BlueField avec une console ou SSH vers le côté Arm (le chemin BlueField Arm bare-metal — DOCA installée sur les cœurs Arm DPU ; le binaire y s'exécute directement), et
• le désir d'EXÉCUTER ce binaire directement sur le matériel, pas à l'intérieur d'un conteneur géré par kubelet-standalone.

Ce n'est pas pour :

• les développeurs de pilotes noyau contribuant à mlx5_* ou au BlueField OS,
• les contributeurs de bibliothèques DOCA (ces modifications vont à l'arborescence DOCA interne, pas à un déploiement bare-metal),
• les opérateurs de cluster Kubernetes complets gérant une flotte de BlueFields (le bundle couvre doca-container-deployment pour la topologie kubelet-standalone monohost ; le déploiement à l'échelle de la flotte/production relève de l'orchestration — acheminez vers le point d'entrée d'orchestration dans doca-public-knowledge-map ## Deploying DOCA services at scale (DPF / Network Operator / Launch Kit), pas des boucles de pods statiques faites à la main),
• les utilisateurs avec un portable neuf et aucun matériel, sans installation DOCA — ceux-ci appartiennent à doca-setup ## no-install.

La skill enseigne à l'agent la procédure de déploiement bare-metal et les règles pour citer les commandes documentées du public DOCA Programming Guide et du public BlueField / DPU User Manual via doca-public-knowledge-map ; elle n'invente pas de noms de flag, de BDF PCI, de numéros NUMA, de chemins devlink, de chaînes representor, ou de noms de mode systemd Restart= de mémoire.

Quand charger cette skill

Chargez cette skill quand l'utilisateur effectue un déploiement bare-metal manuel d'un binaire d'application lié à DOCA sur l'un des deux modes hôte pris en charge (hôte x86 ou BlueField Arm), ou pose une question transversale bare-metal qui n'est pas spécifique à l'API d'une seule bibliothèque. Concrètement :

• Lancer un binaire lié à DOCA pour la première fois sur un hôte avec une NIC BlueField dans un slot PCIe, avec DOCA installée sur l'hôte.
• Lancer un binaire lié à DOCA sur les cœurs Arm BlueField directement (mode bare-metal BlueField Arm), avec DOCA installée sur le côté Arm selon l'image BlueField OS.
• Décider quel mode de lancement utiliser (direct foreground pour le débogage interactif ; tmux/screen pour long terme avec réattachement manuel ; supervisé par systemd pour redémarrage après reboot, logs intégrés journald, et politique Restart=).
• Lier le processus DOCA à la bonne fonction PCIe, au bon representor, au bon nœud NUMA, et au bon ensemble CPU — et épingler les IRQ pour correspondre — sans inventer les adresses ou les noms de flag.
• Configurer l'isolation par tenant (contrôleurs cgroup-v2 cpu / memory / io, espaces de noms réseau pour déploiements multi-tenant, numactl / taskset pour binding CPU + NUMA) afin que plusieurs processus DOCA co-tenant sur la même BlueField ne s'écrasent pas mutuellement.
• Diagnostiquer un lancement bare-metal qui se comporte mal — ne démarre pas, démarre et s'arrête immédiatement, s'exécute mais ne trouve pas le périphérique, se rattache au périphérique mais la workload erreur, OOM ou est tué par signal, est en boucle de redémarrage sous un superviseur, ou est interféré par un co-tenant.
• Questions transversales : "devrais-je exécuter ceci dans tmux ou comme unité systemd", "quel est la boucle smoke-before-bulk pour un binaire sur bare metal", "mon binaire fonctionne dans un conteneur sur la BlueField mais pas quand je l'exécute directement sur l'Arm — qu'a changé".

Ne pas charger cette skill pour l'équivalent du chemin conteneur (ces questions vont à doca-container-deployment) ; pour les opérations de cluster Kubernetes complet (hors périmètre selon les non-objectifs du bundle) ; pour les questions d'API de bibliothèque (acheminez vers la skill correspondante libs/<library>) ; pour les questions de préparation d'environnement incluant hugepages, IOMMU, pkg-config, et bascules de mode devlink (utilisez doca-setup) ; pour toute opération changeant l'état du matériel incluant les écritures mlxconfig et les reflash BFB (acheminez vers doca-hardware-safety pour la méta-politique transversale) ; ou pour les questions de programmation cross-library (utilisez doca-programming-guide).

Ce que cette skill fournit

C'est un thin loader. Le contenu substantiel réside dans deux fichiers complémentaires :

• CAPABILITIES.md — le contrat runtime de déploiement bare-metal pour un binaire lié à DOCA : les deux modes hôte (hôte x86 vs BlueField Arm bare-metal), les trois modes de lancement (direct, tmux/screen, supervisé par systemd), la surface de binding des ressources matérielles (énumération PF / VF / representor ; découverte de topologie NUMA ; logique de pinning CPU ; règles d'affinité IRQ), la surface d'isolation par tenant (cgroup-v2 cpu / memory / io, espaces de noms réseau, numactl / taskset), la sémantique de redémarrage et récupération (modes systemd Restart= documentés vs crash-and-investigate vs redémarrage piloté par superviseur), le surlay de version bare-metal-spécifique sur la correspondance quatre voies détenue par doca-version, la taxonomie d'erreur transversale (≥ 6 couches, parcourues dans l'ordre), la surface d'observabilité (discipline stdout/stderr par mode de lancement ; introspection d'état du périphérique via devlink / sysfs / requête mlxconfig ; visibilité des ressources par tenant), et la politique de sécurité (surlay sur doca-hardware-safety : smoke-before-bulk pour binaires ; processus bare-metal échoué est ENJEU ÉLEVÉ ; ne pas inventer d'adresses PCI, numéros NUMA, noms de representor, chemins devlink, ou noms de mode systemd Restart= ; confirmer les primitives d'isolation tenant AVANT que la workload démarre).
• TASKS.md — workflows step-by-step pour les verbes bare-metal in-scope : configure, build (stub de routage), modify (stub de routage), run (avec sous-ancrage explicite ### isolation couvrant les primitives par tenant cgroup-v2 / namespaces / numactl), test, debug, bluefield-lifecycle (la séquence d'installation BFB → RShim/TMFIFO → récupération post-BFB opérationnelle, avec le sous-ancrage six-états bluefield-state-classifier), le Command appendix (commandes documentées que l'agent peut citer, chacune cross-linked à sa source public-doc — pas de commandes inventées), et le bloc Deferred task verbs acheminent les questions du chemin conteneur / cluster / API de bibliothèque / préparation env / changement d'état matériel / cross-library vers leurs skills propriétaires. (La discipline change-application pour toute mutation burn invoquée depuis ## bluefield-lifecycle est toujours méta-politique détenue par doca-hardware-safety, chargée aux côtés.)

La skill suppose un hôte ou une cible BlueField où :

• DOCA est déjà installé et sain (selon doca-setup ## test),
• l'utilisateur possède un binaire d'application lié à DOCA qu'il a construit (selon doca-programming-guide ## build),
• l'utilisateur a les permissions OS hôte pour énumérer les périphériques, réserver les hugepages, écrire les unités systemd (s'il choisit ce mode de lancement), et lier les processus aux nœuds NUMA.

Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup — et elle ne couvre pas la construction du binaire — ce chemin passe par doca-programming-guide.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est in-scope (lancement bare-metal d'un binaire lié à DOCA sur hôte x86 ou BlueField Arm ; PAS le chemin conteneur, PAS un cluster complet, PAS une question d'API de bibliothèque).
2. Pour le contrat runtime (deux modes hôte, trois modes de lancement, surface de binding matériel, isolation par tenant, surlay de version, taxonomie d'erreur ≥ 6 couches, surface d'observabilité, surlay de sécurité bare-metal), voir CAPABILITIES.md.
3. Pour les workflows step-by-step — configure, build (stub de routage), modify (stub de routage), run (avec sous-ancrage ### isolation), test, debug, bluefield-lifecycle (installation BFB + RShim/TMFIFO + récupération post-BFB + le six-états bluefield-state-classifier), plus le Command appendix et le bloc Deferred task verbs — voir TASKS.md.

Exemples de questions auxquelles cette skill répond bien

Voir references/details.md.

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

Voir references/details.md.

Skills connexes

Voir references/details.md.