doca-bf3-deployment

Name: doca-bf3-deployment
Author: nvidia

github.com/nvidiaCloud & DevOps3.8k151 installsUpdated today

About doca-bf3-deployment

A procedural skill for DOCA operators bringing up BlueField-3 hardware through RShim and BFB. It covers readiness checks and recovery while routing hardware-changing operations and later workload deployment to separate guidance.

Key features

01Push BFB images through RShim
02Bring up the TMFIFO management channel
03Verify Arm OS and version alignment
04Classify bring-up failures by state

Use cases

01Flash BFB onto a BlueField-3
02Recover a DPU that fails to return after flashing
03Check RShim and TMFIFO connectivity

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/nvidia/skills --skill doca-bf3-deployment

After installing, type/doca-bf3-deploymentin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

BENCHMARK.md

CAPABILITIES.md

skill-card.md

skill.oms.sig

TASKS.md

evals/

evals.json

references/

details.md

Details

From the project README

DOCA BlueField-3 (BF3) deployment

Examples

"I have a BlueField-3 and a BFB — how do I push it?" — RShim plus bfb-install from the host. Exit 0 is not success until the DPU is ready.
"bfb-install exited 0 but the DPU never came back." — start at the six-state classifier, not a second burn.

Instructions

Follow Loading order below. Open the tasks companion for BFB push and recover. Open the capabilities companion for the RShim/BFB contract and safety overlay. Do not open every companion file.

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/SKILL.md (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 the tasks companion and start at ## configure. If the question is what shape does the BF3 platform-bring-up surface even have, start at the capabilities companion. Once the BF3 is healthy, this skill routes onward to the deployment skills — running a binary goes to doca-bare-metal-deployment/SKILL.md; deploying a service container goes to doca-container-deployment/SKILL.md.

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/SKILL.md, 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.

It is not for:

BlueField-4 bring-up (the BMC-Redfish provisioning path) — route to doca-bf4-deployment/SKILL.md, the BF4 equivalent of this skill,
kernel-driver or BlueField-OS developers contributing to mlx5_* or the BFB image itself (that is internal-tree work, not a field deployment),
operators who already have a healthy BF3 and just want to run a binary (route to doca-bare-metal-deployment/SKILL.md) or deploy a service container (route to doca-container-deployment/SKILL.md),
fresh-no-hardware users with no DOCA install — route to doca-setup ## no-install.

The skill teaches the agent the BF3 bring-up procedure and the rules for quoting documented commands from the public BlueField Platform Software Manual, the public DOCA Installation Guide, and the MFT manual via doca-public-knowledge-map/SKILL.md; it does not invent bfb-install flag sets, BFB image filenames, RShim character-device paths, bf.cfg schema keys, mlxconfig parameter names, or TMFIFO subnets from memory. Where a fact is already vetted in doca-bare-metal-deployment ## bluefield-lifecycle, this skill reuses that exact fact rather than restating a new one.

When to load this skill

Load this skill when the user is doing hands-on BlueField-3 platform bring-up over the RShim/BFB path, or asking a cross-cutting BF3 lifecycle question that is not specific to one library's API. Concretely:

Pushing a BFB image to a BF3 for the first time (or re-pushing after a failed install), from the host over the RShim interface with bfb-install.
Bringing up or recovering the host-to-DPU TMFIFO management channel (tmfifo_net0, the documented 192.168.100.x convention) and the RShim console.
Confirming RShim driver/daemon state on the host (the userspace rshim daemon and the /dev/rshim* tree) before any push or console capture.
Deciding (and routing) a DPU-mode change — DPU / embedded-function mode vs separated-host / NIC mode — knowing the actual mlxconfig set burn leaves this skill for doca-hardware-safety/SKILL.md.
Recovering a BF3 that did not come back after a BFB push: bfb-install exited 0 but the DPU never reached the documented DPU is ready marker; ping 192.168.100.2 works but SSH refuses; host PFs are present in lspci -d 15b3: but their netdevs are gone.
Verifying a BF3 install — cat /etc/mlnx-release on the Arm side, the four-way version match per doca-version/SKILL.md — and distinguishing the host-side DOCA install from the BlueField-Arm-side DOCA install.
Cross-cutting questions: "is DOCA on the host or on the Arm side, and which one do I install?", "my BF3 was fine last week and after a BFB push it never came back — where do I start?", "how do I tell which /dev/rshim<N> is which BlueField on a multi-DPU host?".

Do not load this skill for: BlueField-4 bring-up (route to doca-bf4-deployment/SKILL.md, the BF4 equivalent); running a DOCA-linked binary on a healthy BF3 (route to doca-bare-metal-deployment/SKILL.md); deploying a DOCA service container (route to doca-container-deployment/SKILL.md); env-preparation including hugepages, IOMMU, pkg-config, and devlink mode flips (use doca-setup/SKILL.md); the body of the version-match rule (use doca-version/SKILL.md); or any hardware-state-changing burn itself — the change-application discipline is meta-policy owned by doca-hardware-safety/SKILL.md, loaded ALONGSIDE this skill.

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

the capabilities companion — the BF3 platform-bring-up contract: the RShim/BFB transport surface (the userspace RShim daemon, the /dev/rshim* tree, console-over-rshim, the BFB image as the unit of input), the TMFIFO management-channel surface (tmfifo_net0 / tm-br, the documented 192.168.100.x convention, the ip route get-before-ping loopback gotcha), the DPU-mode surface (DPU / embedded-function vs separated-host / NIC mode, set via mlxconfig at BFB-install time — a MUTATING burn routed to doca-hardware-safety/SKILL.md), the host-side-vs-Arm-side DOCA install distinction, the BF3-version overlay on the four-way match owned by doca-version/SKILL.md, the cross-cutting error taxonomy, the observability surface, and the safety policy (overlay on doca-hardware-safety/SKILL.md).
the tasks companion — step-by-step workflows for the in-scope BF3 lifecycle verbs: configure, build (routing stub), modify, run (the BFB-install + RShim/TMFIFO bring-up sequence), test (the post-BFB readiness smoke), debug (the six-state bluefield-state-classifier), and the Deferred task verbs block routing app-launch / container / install / library-API / hardware-state-change / BF4 questions out to their owning skills.

The skill assumes a target where:

a BlueField-3 is physically present and powered, reachable from a host that has the RShim daemon and /dev/rshim* tree available,
the operator has a BFB image downloaded from the public DOCA Downloads page (route via doca-public-knowledge-map/SKILL.md), and
the operator has an out-of-band path (BMC console, serial-over-LAN, or physical UART) to reach the BF3 if a push breaks the Arm OS.

It does not cover installing DOCA on a host from scratch (that goes through doca-setup/SKILL.md), and it does not cover BlueField-4 (that goes through doca-bf4-deployment/SKILL.md).

Loading order

Read this skill first to confirm the user's question is in scope (BF3 platform bring-up over the RShim/BFB path; NOT BF4, NOT app-launch, NOT a library-API question).
For the bring-up contract (RShim/BFB transport, TMFIFO channel, DPU-mode surface, host-vs-Arm install distinction, BF3-version overlay, error taxonomy, observability surface, BF3 safety overlay), see the capabilities companion.
For step-by-step workflows — configure, build (routing stub), modify, run (BFB install + RShim/TMFIFO bring-up), test (post-BFB readiness smoke), debug (the six-state bluefield-state-classifier), plus the Deferred task verbs block — see the tasks companion.

Example questions this skill answers well

What this skill deliberately does not ship

Related skills

Comments

Markdown supported

Details

Author: nvidia
Repository: nvidia/skills
Category: Cloud & DevOps
Installs: 151
GitHub stars: 3,778

Report

More skills

All skills

lark-apps

open.feishu.cn

732.0k

Develop and host Miaoda (Spark/Miaoda) apps: app creation, local full-stack development, cloud generation and iteration, creative design (UI mockups / interactive prototypes / wireframes / landing pages / dashboards / slide decks / visual exploration), integration of AI-related capabilities, Feishu platform capabilities, or other external capabilities; log/Trace/monitoring metric/PV/UV queries; environment variable management; app collaborators and collaboration permissions; app roles and members; and automation triggers (scheduled / record changes / Webhook / Feishu approvals). Use when users want to develop or create a system, tool, platform, or app; develop locally or in the cloud, modify, deploy, publish, launch, or get a shareable link; create a page or website with HTML and deploy it to Miaoda; design, create a mockup, prototype, wireframe, PPT, deck, or visual exploration; or mention Miaoda/Spark/Miaoda apps (links like `/app/app_xxx` or `/page/<token>`, runtime domains like *.aiforce.cloud), app databases, app file storage, open API Keys, visibility, app collaborators/developer permissions, app roles/role members, production logs, API request volume, error volume, latency, traffic, environment variables, or setting up automation tasks, scheduled triggers, or approval-triggered automation for Miaoda apps. Not for regular cloud drive file uploads (lark-drive), Feishu document editing (lark-doc), or native slide creation (lark-slides).

azure-prepare

github.com/microsoft

571.7k

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

wizard

github.com/mattpocock

571.5k

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.

azure-ai

github.com/microsoft

571.2k

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.