What does this skill do, and when should you use it?
This skill is for DOCA developers and operators who already have a DOCA-linked binary and want to run it directly on host x86 hardware or BlueField Arm cores. It covers direct, tmux/screen, and systemd-supervised launch modes, along with PCI, NUMA, CPU, IRQ, and tenant-isolation concerns. It also provides a seven-layer error taxonomy and a six-state BlueField lifecycle classifier covering BFB installation, RShim/TMFIFO, and post-install recovery. It excludes DOCA installation, application builds, containers, full Kubernetes fleets, library APIs, and unconfirmed hardware-state changes.
The skill routes the agent through the bare-metal path and points to TASKS.md and CAPABILITIES.md for configure, run, test, debug, and BlueField lifecycle workflows. It addresses PF, VF, and representor enumeration; NUMA and CPU binding; IRQ affinity; cgroup-v2, network namespaces, numactl, and taskset isolation; and systemd restart and logging behavior. It requires commands to be quoted from public DOCA and BlueField documentation rather than inventing PCI BDFs, NUMA numbers, representor names, devlink paths, or systemd modes. mlxconfig writes and BFB reflashes must be routed through the hardware-safety policy with explicit confirmation.
- A DOCA developer has built a binary and needs to launch it directly on a BlueField NIC connected to a host over PCIe.
- A BlueField operator needs to choose between foreground execution, tmux/screen, and systemd supervision on Arm bare metal.
- A binary exits immediately, cannot find its device, is OOM-killed or signal-killed, or enters a systemd restart loop.
- Several DOCA processes share one BlueField and require CPU, memory, I/O, network-namespace, or NUMA isolation.
- A BFB installation reports success but the DPU is unhealthy, or RShim/TMFIFO, host PFs, and post-install recovery need diagnosis.
How do you install this skill?
- This is guidance for privileged hardware and host operations; require explicit confirmation of targets, permissions, maintenance window, and out-of-band recovery before systemd, cgroup, netns, device-binding, or production-traffic actions.
- SKILL.md presents the BFB lifecycle as covered, while CAPABILITIES.md places parts of BFB/BSP tooling outside the bundle. For bfb-install, RShim, TMFIFO, or firmware changes, verify the boundary and route to the hardware-safety or dedicated documentation path.
- License information conflicts between Apache-2.0 and Apache 2.0 AND CC-BY-4.0; confirm the applicable terms before publication or redistribution.
- Critical commands, versions, hardware identifiers, and library-level validation depend on companion skills or NVIDIA public documentation, so the supplied material alone cannot support complete offline reproduction.
- Shell / CLI
- Local filesystem
DOCA installation at /opt/mellanox/docaDOCA-linked application binaryBlueField NIC and compatible host or BlueField Arm hardware
Install the skill from the NVIDIA/skills catalog with the skills CLI:
npx skills add nvidia/skills --skill doca-bare-metal-deployment --yes
To target a specific agent:
npx skills add nvidia/skills --skill doca-bare-metal-deployment --agent codex --yes
The source does not document another installation method for this individual skill.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-bare-metal-deployment" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- My DOCA binary exits immediately after launch; how should I debug it on the BlueField host path?
- Should I run this DOCA binary in tmux or as a systemd unit?
Ask an installed agent a concrete bare-metal question, such as: “My DOCA binary exits immediately after launch; how should I debug it on the BlueField host path?” or “Should I run this DOCA binary in tmux or as a systemd unit?” The environment should already have a healthy DOCA installation, a built DOCA-linked binary, BlueField hardware, and the required host permissions. First confirm the host x86 or BlueField Arm bare-metal shape, then follow CAPABILITIES.md and TASKS.md; route firmware burns, mlxconfig writes, and BFB reflashes to doca-hardware-safety.
What are this skill's strengths and limitations?
- Covers the bare-metal workflow from launch and resource binding through isolation, debugging, and lifecycle recovery.
- Clearly distinguishes host x86 and BlueField Arm execution modes.
- Emphasizes documented commands and avoids invented hardware identifiers and system parameters.
- Includes tenant isolation, restart policy, and observability guidance.
- Requires BlueField hardware, a healthy DOCA installation, and an already-built application binary.
- Does not cover DOCA installation, application builds, containers, full Kubernetes operations, or library APIs.
- Hardware-state-changing actions require a separate safety policy and explicit confirmation.
- Detailed procedures depend on companion CAPABILITIES.md, TASKS.md, and public documentation; the supplied SKILL.md does not include every command.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| DOCA BlueField Bare-Metal Deployment this page ✓ NVIDIA · Official | 53 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA Structured Tools Contract ✓ NVIDIA · Official | 55 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA Container Deployment ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA Capabilities Inspector ✓ NVIDIA · Official | 56 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA PCC Diagnostic Counters ✓ NVIDIA · Official | 56 · Use with care | ★ 3.8k | today | Apache-2.0 |
The skill explicitly positions itself as the non-container counterpart to doca-container-deployment; container-path questions should use that skill instead.
How did FollowSkills review this skill?
The material separates read-only diagnosis, runtime operations, and hardware-state changes; requires state capture, rollback planning, and avoidance of invented addresses or parameters; and routes firmware or mlxconfig changes to a hardware-safety skill. No credential theft or covert exfiltration is evident. However, device access, namespaces, cgroups, systemd, and host networking can have substantial external effects, while uniform user-confirmation gates, least-privilege implementation, and complete recovery procedures are not fully specified, so points are deducted.
SKILL.md, CAPABILITIES.md, and TASKS.md provide a coherent configure-run-test-debug sequence with layered failure classification and diagnostic feedback. However, many critical commands, parameters, library-specific liveness signals, and hardware semantics are delegated to other skills or live public documentation, and no committed test suite or CI evidence covers the key paths. Under static calibration, the score remains below the 10-point execution ceiling.
The audience, supported host-x86 and BlueField-Arm scenarios, container-versus-bare-metal boundary, trigger phrases, and non-fit cases are described well, supporting reasonably precise semantic invocation. Inputs and outputs still depend on the user's environment and companion skills; Chinese-language support is absent; and practical use depends on reachability of NVIDIA documentation, so points are deducted.
The documentation is well layered across a loader, capability contract, task workflows, reference details, and evaluation files, with dependencies, limitations, related skills, and refresh guidance described. However, SKILL.md declares Apache-2.0 while skill-card.md declares Apache 2.0 AND CC-BY-4.0, and repository license metadata is NOASSERTION. Author attribution, formal changelog/versioning, and clear maintenance ownership are also incomplete, so points are deducted.
The skill offers useful guidance for scope recognition, launch-mode selection, hardware binding, isolation, smoke testing, and layered debugging, and the benchmark report records positive results. However, it intentionally omits complete copy-ready launch commands and unit examples, while key content depends on companion skills and live documentation. Static evidence therefore does not establish directly usable end-to-end completion, so the score stays below the static ceiling.
The files contain concrete workflows, cross-references, evaluation metrics, and some benchmark results, providing limited auditability. The evaluation dataset is unavailable, no real CI and committed key-path test suite are supplied, public-document evidence is not individually reproduced in the provided material, and execution was not performed. The score therefore remains below the static ceiling of 5.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →