Agent skill · NVIDIA
doca-bf3-deployment
Use this skill for BlueField-3 (BF3) day-1 platform bring-up via the classic RShim/BFB path: pushing a BlueField bundle (BFB) to the DPU over RShim with bfb-install from the host, the host-to-DPU TMFIFO management channel (tmfifo_net0, the 192.168.100.x convention), RShim daemon state and console-over-rshim, DPU mode selection (DPU/embedded-function vs separated-host/NIC mode) via mlxconfig, post-BFB recovery, a six-state BlueField-state classifier, and verifying the install (cat /etc/mlnx-release plus version checks). Trigger even when the user does not say "BF3" — typical phrasings include {push a BFB to my BlueField-3}, {bfb-install exited 0 but the DPU never came back}, {ping 192.168.100.2 works but ssh fails}, or {is DOCA on the host or the Arm side?}. BFB reflash, mlxconfig set, mode changes, and firmware burns are destructive: require explicit target-bound confirmation and load doca-hardware-safety. App launch, container deploy, env install, and the BF4 BMC-Redfish path route elsewhere.
What it needs
About 6k tokens when loaded.
What this skill does
DOCA BlueField-3 (BF3) deployment Where to start: This skill is the bundle's home for BlueField-3 day-1 platform bring-up — taking a BF3 from "powered card in the slot" (or a card that just came back broken from a BFB push) to "Arm OS healthy, TMFIFO up, host PFs bound, four-way version match closed, ready to run a workload". It owns the classic RShim/BFB path that BF3 uses today; the newer BMC-Redfish provisioning path is the sibling skill doca-bf4-deployment (the BF4 equivalent). If the user has a BF3 and needs to push a BFB, recover a DPU that did not come back, or verify the install, open TASKS.md and start at configure. If the question is what shape does the BF3 platform-bring-up surface even have, start at CAPABILITIES.md. Once the BF3 is healthy, this skill routes onward to the deployment skills — running a binary goes to doca-bare-metal-deployment; deploying a service container goes to doca-container-deployment. Every mutating burn invoked from a bring-up step — the BFB reflash itself, any mlxconfig set (including a DPU/separated-host mode flip), a firmware burn, or a kernel-boot-parameter change — is governed by the change-application meta-policy in doca-hardware-safety, which the agent loads ALONGSIDE this skill. This skill adds only the BF3-specific operational sequencing on top; it does NOT redefine the preflight / OOB-console / maintenance-window / rollback discipline that meta-policy owns. Audience This skill serves external DOCA operators bringing up a real BlueField-3 — i.e. people who already have: a physical BlueField-3 in a host (or a standalone BF3 they can reach over its console / management network), host-side RShim access to the DPU (the RShim userspace daemon and the /dev/rshim character-device tree present over the PCIe or USB RShim interface), and a matching DOCA-Host install on the host plus a BlueField bundle (BFB) image downloaded from the public DOCA Downloads page. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills NVIDIA/doca-bf3-deployment