DOCA BlueField-3 Bring-Up
Guides operators through BF3 day-one bring-up, recovery, RShim/BFB provisioning, and installation validation.
The document explicitly routes hardware changes to a safety meta-policy, requires an out-of-band path, records version anchors, verifies the BFB hash, and forbids invented parameters. It does not fully present user confirmation, maintenance-window, or rollback execution details in this path, and it routes high-impact hardware actions, so 7 points are deducted.
The workflow order, six-state classifier, failure signals, and escalation paths are clear. However, it depends on external manuals and sibling skills, lacks statically reproducible key commands, timeout boundaries, and committed tests, and contains some inconsistent stop/report wording. 12 points are deducted; the static cap is 10.
The audience, BF3/RShim scope, exclusions for BF4 and application deployment, and trigger phrases are clearly defined. Chinese-language support and mainland-China reachability are not substantively addressed, and core public-document dependencies may be network-sensitive, so 3 points are deducted.
The information architecture, loading order, related-skill routing, frontmatter license, version checks, and maintenance note are useful. Missing author metadata, missing recommended Instructions/Examples sections, no changelog, benchmark schema findings, and inconsistent Apache-2.0 versus Apache 2.0 AND CC-BY-4.0 license wording justify a 6-point deduction.
The skill provides useful BF3 bring-up routing, sequencing, state classification, and safety boundaries, so the core value is clear. However, it is a thin loader dependent on sibling files and live NVIDIA manuals, without a directly executable complete runbook or verified outputs, requiring substantial manual completion. 9 points are deducted; the static cap is 7.
The files include a pinned revision context, public primary-source pointers, a skill version, and a static evaluation report. The evaluation dataset is unavailable, and there is no committed test suite or third-party execution evidence covering key paths, so 7 points are deducted; the static cap is 5.
- Before any BFB reflash, mlxconfig set, firmware burn, or kernel-parameter change, ensure the safety meta-policy is actually loaded and obtain explicit confirmation, a maintenance window, out-of-band access, and an executable rollback plan.
- This skill does not provide a complete copy-paste runbook. Check the live NVIDIA manuals and installed-tool --help for the target DOCA/BFB version; do not blindly reuse example symbols, addresses, or parameters.
- The frontmatter license and skill-card license wording are inconsistent and should be reconciled before publication.
- Chinese interaction and mainland-China network reachability are not verified; overseas public documentation dependencies may require mirrors, caching, or user-supplied references.
What does this skill do, and when should you use it?
This skill is for DOCA operators working with real, powered BlueField-3 hardware. It covers the classic host-to-DPU RShim/BFB path, including pushing a BFB with bfb-install, using the RShim console and TMFIFO management channel, and selecting DPU or separated-host/NIC mode. It also provides post-BFB recovery guidance, a six-state BlueField classifier, and version verification. It excludes BlueField-4 provisioning, application launch, container deployment, and fresh DOCA installation.
Guides checks and use of the host-side RShim daemon and /dev/rshim* device tree; pushes a BFB to BF3 with bfb-install; handles console-over-rshim, tmfifo_net0, tm-br, and the documented 192.168.100.x convention; routes mlxconfig mode changes and other mutating operations through the hardware-safety policy; classifies failures such as a missing DPU is ready marker, working ping with refused SSH, or missing host PF netdevices; and verifies the Arm-side installation with cat /etc/mlnx-release and the four-way version match.
- An operator performing first-time BFB provisioning on a powered BlueField-3.
- An operator recovering a DPU after bfb-install exited 0 but the DPU never returned.
- An operator who can ping 192.168.100.2 but cannot establish SSH.
- A user deciding whether DOCA belongs on the host, the BlueField Arm side, or both.
- An operator identifying the correct /dev/rshim<N> device on a multi-DPU host.
What are this skill's strengths and limitations?
- Covers BF3 day-one bring-up, recovery, RShim/TMFIFO management, and install validation in one lifecycle-focused skill.
- Distinguishes host-side DOCA from BlueField Arm-side DOCA.
- Provides a six-state BlueField-state classifier and explicit routing boundaries.
- Adds safety routing for BFB reflashes, mode changes, firmware burns, and other mutating operations.
- Requires physical BlueField-3 hardware, host RShim access, DOCA-Host, and a BFB image for operational use.
- Does not cover the BlueField-4 BMC-Redfish provisioning path.
- Does not cover fresh DOCA installation, application execution, service containers, or library APIs.
- SKILL.md is a thin loader; substantive procedures are referenced in CAPABILITIES.md and TASKS.md, whose full contents are not included here.
How do you install this skill?
Install the individual skill with the NVIDIA skills CLI:
npx skills add nvidia/skills --skill doca-bf3-deployment --yes
The README does not document a specific manual folder-copy procedure.
How do you use this skill?
After installation, describe the operational problem in natural language, for example: "Push a BFB to my BlueField-3", "bfb-install exited 0 but the DPU never came back", or "ping 192.168.100.2 works but ssh fails". The operational workflows require real BlueField-3 hardware, host-side RShim access, a matching DOCA-Host installation, a BFB image, and an out-of-band console or management path for recovery. BFB reflashing, mlxconfig set, firmware burns, and kernel boot-parameter changes require explicit target-bound confirmation and the doca-hardware-safety skill.
How does this skill compare with similar options?
The source explicitly routes BlueField-4 BMC-Redfish provisioning to doca-bf4-deployment, healthy-BF3 binary execution to doca-bare-metal-deployment, and service-container deployment to doca-container-deployment.