Déploiement DOCA BlueField-3 (BF3)

Par où commencer : Cette skill est le hub du bundle pour la mise en service de plateforme BlueField-3 de jour 1 — faire passer un BF3 de « carte alimentée dans le slot » (ou une carte qui vient de revenir cassée d'un push BFB) à « Arm OS sain, TMFIFO opérationnel, host PFs liés, correspondance de version à quatre voies fermée, prêt à exécuter une workload ». Elle maîtrise le chemin RShim/BFB classique que BF3 utilise aujourd'hui ; le chemin de provisioning BMC-Redfish plus récent est la skill compagnon doca-bf4-deployment (l'équivalent BF4). Si l'utilisateur dispose d'un BF3 et doit pousser un BFB, récupérer un DPU qui n'est pas revenu, ou vérifier l'installation, ouvrez TASKS.md et commencez à ## configure. Si la question porte sur la forme que la mise en service de plateforme BF3 offre même, commencez à CAPABILITIES.md. Une fois le BF3 sain, cette skill route en avant vers les skills de déploiement — l'exécution d'un binaire va à doca-bare-metal-deployment ; le déploiement d'un conteneur de service va à doca-container-deployment.

Chaque burn mutant invoqué à partir d'une étape de mise en service — le reflash BFB lui-même, tout mlxconfig set (y compris un flip de mode DPU/host séparé), un burn de firmware, ou un changement de paramètre de boot du kernel — est régi par la méta-politique d'application de changement dans doca-hardware-safety, que l'agent charge PARALLÈLEMENT à cette skill. Cette skill ajoute uniquement le séquençage opérationnel spécifique à BF3 au-dessus ; elle ne REDÉFINIT PAS la discipline de vérification préalable / console OOB / fenêtre de maintenance / rollback que cette méta-politique maîtrise.

Audience

Cette skill sert les opérateurs DOCA externes mettant en service un BlueField-3 réel — c'est-à-dire les personnes qui ont déjà :

• un BlueField-3 physique dans un host (ou un BF3 autonome auquel elles peuvent accéder via sa console / réseau de gestion),
• accès RShim côté host au DPU (le daemon userspace RShim et l'arborescence des périphériques caractères /dev/rshim* présents sur l'interface RShim PCIe ou USB), et
• une installation DOCA-Host correspondante sur le host plus une image BlueField bundle (BFB) téléchargée à partir de la page publique DOCA Downloads.

Elle ne convient pas pour :

• la mise en service BlueField-4 (le chemin de provisioning BMC-Redfish) — route vers doca-bf4-deployment, l'équivalent BF4 de cette skill,
• les développeurs de driver noyau ou de BlueField-OS contribuant à mlx5_* ou à l'image BFB elle-même (c'est un travail interne, pas un déploiement sur le terrain),
• les opérateurs qui disposent déjà d'un BF3 sain et veulent simplement exécuter un binaire (route vers doca-bare-metal-deployment) ou déployer un conteneur de service (route vers doca-container-deployment),
• les utilisateurs frais sans matériel et sans installation DOCA — route vers doca-setup ## no-install.

La skill enseigne à l'agent la procédure de mise en service BF3 et les règles pour citer des commandes documentées à partir du manuel public BlueField Platform Software, du guide public d'installation DOCA, et du manuel MFT via doca-public-knowledge-map ; elle ne fabrique pas à partir de la mémoire les ensembles de drapeaux bfb-install, les noms de fichiers d'images BFB, les chemins de périphériques caractères RShim, les clés du schéma bf.cfg, les noms de paramètres mlxconfig, ou les subnets TMFIFO. Quand un fait est déjà vérifié dans doca-bare-metal-deployment ## bluefield-lifecycle, cette skill réutilise ce fait exact plutôt que d'en énoncer un nouveau.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait une mise en service de plateforme BlueField-3 pratique sur le chemin RShim/BFB, ou pose une question de cycle de vie BF3 transversale qui n'est pas spécifique à l'API d'une bibliothèque. Concrètement :

• Pousser une image BFB sur un BF3 pour la première fois (ou re-pousser après un échec d'installation), depuis le host sur l'interface RShim avec bfb-install.
• Mettre en service ou récupérer le canal de gestion TMFIFO de host à DPU (tmfifo_net0, la convention documentée 192.168.100.x) et la console RShim.
• Confirmer l'état du driver/daemon RShim sur le host (le daemon userspace rshim et l'arborescence /dev/rshim*) avant tout push ou capture de console.
• Décider (et router) un changement de mode DPU — mode DPU / fonction embarquée vs mode host séparé / NIC — en sachant que le burn mlxconfig set réel quitte cette skill pour doca-hardware-safety.
• Récupérer un BF3 qui n'est pas revenu après un push BFB : bfb-install s'est fermé 0 mais le DPU n'a jamais atteint le marqueur documenté DPU is ready ; ping 192.168.100.2 fonctionne mais SSH refuse ; les host PFs sont présents dans lspci -d 15b3: mais leurs netdevs ont disparu.
• Vérifier une installation BF3 — cat /etc/mlnx-release côté Arm, la correspondance de version à quatre voies par doca-version — et distinguer l'installation DOCA côté host de l'installation DOCA côté Arm-BlueField.
• Questions transversales : « DOCA est sur le host ou du côté Arm, et lequel dois-je installer ? », « mon BF3 allait bien la semaine dernière et après un push BFB il n'est jamais revenu — par où commencer ? », « comment je dis quel /dev/rshim<N> est quel BlueField sur un host multi-DPU ? ».

Ne chargez pas cette skill pour : la mise en service BlueField-4 (route vers doca-bf4-deployment, l'équivalent BF4) ; l'exécution d'un binaire lié à DOCA sur un BF3 sain (route vers doca-bare-metal-deployment) ; le déploiement d'un conteneur de service DOCA (route vers doca-container-deployment) ; la préparation d'environnement incluant hugepages, IOMMU, pkg-config, et les flips de mode devlink (utilisez doca-setup) ; le corps de la règle de correspondance de version (utilisez doca-version) ; ou tout burn lui-même changeant l'état matériel — la discipline d'application de changement est une méta-politique maîtrisée par doca-hardware-safety, chargée PARALLÈLEMENT à cette skill.

Ce que cette skill fournit

C'est un chargeur minimaliste. Les matériaux substantiels vivent dans deux fichiers compagnons :

• CAPABILITIES.md — le contrat de mise en service de plateforme BF3 : la surface de transport RShim/BFB (le daemon RShim userspace, l'arborescence /dev/rshim*, console-sur-rshim, l'image BFB comme unité d'entrée), la surface du canal de gestion TMFIFO (tmfifo_net0 / tm-br, la convention documentée 192.168.100.x, la gotcha ip route get-avant-ping loopback), la surface de mode DPU (mode DPU / fonction embarquée vs mode host séparé / NIC, défini via mlxconfig à l'heure de l'installation BFB — un burn MUTANT routé vers doca-hardware-safety), la distinction de l'installation DOCA côté host vs côté Arm, le surcouch BF3-version sur la correspondance à quatre voies maîtrisée par doca-version, la taxonomie d'erreur transversale, la surface d'observabilité, et la politique de sécurité (surcouch sur doca-hardware-safety).
• TASKS.md — workflows étape par étape pour les verbes de cycle de vie BF3 en scope : configure, build (stub de routing), modify, run (la séquence BFB-install + RShim/TMFIFO bring-up), test (le smoke de préparation post-BFB), debug (le bluefield-state-classifier à six états), et le bloc Deferred task verbs routant les questions de lancement d'app / conteneur / installation / API de bibliothèque / changement d'état matériel / BF4 vers leurs skills propriétaires.

La skill suppose une cible où :

• un BlueField-3 est physiquement présent et alimenté, accessible depuis un host qui a le daemon RShim et l'arborescence /dev/rshim* disponible,
• l'opérateur a une image BFB téléchargée à partir de la page publique DOCA Downloads (route via doca-public-knowledge-map), et
• l'opérateur a un chemin hors bande (console BMC, série-sur-LAN, ou UART physique) pour accéder au BF3 si un push casse le Arm OS.

Elle ne couvre pas l'installation de DOCA sur un host à partir de zéro (cela passe par doca-setup), et elle ne couvre pas BlueField-4 (cela passe par doca-bf4-deployment).

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope (mise en service de plateforme BF3 sur le chemin RShim/BFB ; PAS BF4, PAS lancement d'app, PAS une question d'API de bibliothèque).
2. Pour le contrat de mise en service (transport RShim/BFB, canal TMFIFO, surface de mode DPU, distinction d'installation host vs Arm, surcouch BF3-version, taxonomie d'erreur, surface d'observabilité, surcouch de sécurité BF3), voir CAPABILITIES.md.
3. Pour les workflows étape par étape — configure, build (stub de routing), modify, run (BFB install + RShim/TMFIFO bring-up), test (smoke de préparation post-BFB), debug (le bluefield-state-classifier à six états), plus le bloc Deferred task verbs — voir TASKS.md.

Questions d'exemple auxquelles cette skill répond bien

Voir references/details.md.

Ce que cette skill ne livre intentionnellement pas

Voir references/details.md.

Skills connexes

Voir references/details.md.