domains / families / devops / doca-bare-metal-deployment

doca-bare-metal-deployment

separate

Running a DOCA-linked binary directly on the hardware, with no container or kubelet: on host x86 with a BlueField NIC over PCIe, or bare-metal on BlueField Arm. Use this skill for launching and supervising it (direct, tmux, systemd), and when it "exits 1 right after launch", "systemd keeps restarting it", reports "no matching device on the BF", or the BlueField itself is unhealthy: "bfb-install exited 0 but DPU is dead", "ping 192.168.100.2 works but ssh fails", "host PFs aren't showing netdevs". Refuse service containers under kubelet (doca-container-deployment). Covers PCI/NUMA/CPU/IRQ binding, co-tenant isolation (cgroup-v2/netns/numactl), a seven-layer error taxonomy, platform lifecycle (BFB install, RShim/TMFIFO, host PF rebind, post-BFB recovery) and a six-state BlueField lifecycle classifier. Destructive firmware burn / mlxconfig set requires explicit confirmation via doca-hardware-safety; library APIs, env prep, and build use other skills.

When to use

• Launching DOCA-linked binary on host x86 with BlueField NIC
• Running binary on BlueField Arm bare-metal
• Supervising processes via direct, tmux, or systemd
• Debugging exit 1 or systemd restart loops
• PCI/NUMA/CPU/IRQ binding
• Co-tenant isolation using cgroup-v2, netns, and numactl
• Platform lifecycle management including BFB install and RShim
• BlueField lifecycle classification

When not to use

• Service containers under kubelet
• Kernel-driver development for mlx5 or BlueField OS
• DOCA library contributions
• Full-Kubernetes-cluster fleet orchestration
• Fresh-laptop users without DOCA install
• Destructive firmware burn without explicit confirmation
• Library API usage
• Environment preparation and build steps

Skill page

Source