doca-bare-metal-deployment

Deploy and debug DOCA-linked binaries directly on BlueField hardware without containers.

3.2k|370|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/NVIDIA/skills --skill doca-bare-metal-deployment
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doca-bare-metal-deployment
Source: https://github.com/NVIDIA/skills/tree/main/skills/doca-bare-metal-deployment
Command: npx skills add https://github.com/NVIDIA/skills --skill doca-bare-metal-deployment

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Running a DOCA-linked application binary directly on hardware (host x86 with a BlueField NIC over PCIe, or on the BlueField Arm cores) involves many failure-prone decisions: launch mode selection, PCI/NUMA/CPU/IRQ binding, per-tenant isolation, and BlueField platform lifecycle operations like BFB install and RShim/TMFIFO recovery. This Skill guides an AI agent through those workflows using documented commands instead of invented PCI addresses, NUMA numbers, or systemd modes.

Core Features & Use Cases

  • Launch and supervision guidance: Choose between direct foreground, tmux/screen, or systemd-supervised launch modes with correct observability and restart semantics.
  • Hardware binding and isolation: Bind processes to the right PCIe function, NUMA node, CPU set, and IRQ affinity, and configure cgroup-v2, network namespaces, and numactl/taskset for multi-tenant deployments.
  • Seven-layer error taxonomy and BlueField lifecycle: Diagnose failures from won't-start through restart loops and co-tenant noise, plus a six-state classifier for BFB install, RShim/TMFIFO, and post-BFB recovery.
  • Use Case: Your DOCA-Flow binary exits with status 1 immediately after launch on a BlueField-3 host. The Skill walks the layered debug ladder—loader resolution, environment variables, device visibility—to pinpoint the failing layer without guessing.

Quick Start

Ask your agent to help launch your DOCA-linked binary directly on the host or BlueField Arm, for example: "My doca-flow binary exits right after launch on the BlueField—walk me through diagnosing and running it correctly on bare metal."

Frequently Asked Questions about doca-bare-metal-deployment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a DOCA application binary directly on bare metal?

Confirm DOCA is installed and healthy, identify the host mode (host x86 or BlueField Arm), then pick a launch mode: direct foreground for debugging, tmux/screen for long-running sessions, or a systemd unit for restart-after-reboot. Bind the process to the correct PCI BDF, NUMA node, and CPU set derived from live lspci and numactl output.

Should I run my DOCA binary in tmux or as a systemd service?

Use direct foreground for interactive debugging, tmux or screen for long-running processes you want to reattach to manually, and systemd when you need restart-after-reboot and journald-integrated logs. Only systemd provides supervised restart, and its Restart= modes must come from systemd.service(5) documentation.

Why does my DOCA binary exit immediately after launch?

Immediate exits usually come from missing environment variables, a missing config file, or unreserved hugepages (the DPDK 'EAL: Cannot get hugepage information' error). Read stdout/stderr from your launch mode, verify the documented env-var surface in the DOCA Programming Guide, and re-run hugepage reservation.

Can multiple DOCA processes share one BlueField safely?

Yes, co-tenant DOCA processes are supported using cgroup-v2 cpu/memory/io limits, per-tenant network namespaces, and numactl/taskset CPU pinning. Ensure each tenant's CPU set stays NUMA-local to its NIC and that memory.max accounts for hugepage usage, and verify isolation before starting workloads.

What should I do when bfb-install exits 0 but the BlueField is unreachable?

Treat it as a partial failure: check the RShim misc console for lines like 'NIC firmware update failed', classify the BlueField state with the six-state lifecycle classifier, and verify host PF rebinding and firmware version with flint. Never reflash or burn firmware without explicit confirmation through the hardware-safety policy.

When should I use container deployment instead of bare metal for DOCA?

Use the container path (doca-container-deployment) when running DOCA workloads under a kubelet-standalone setup on the BlueField Arm. Bare metal fits when you want the binary running directly on the host or Arm cores; the recognition step that picks between them lives in doca-setup.