DOCA Device Emulation Development
Guides developers in building custom PCIe devices on BlueField whose backend runs on the DPU and is visible to the host.
The documentation makes host/DPU data flows, firmware enablement, DPU privileges, and reverse-order teardown visible; however, it commonly requires sudo and lacks explicit stepwise user confirmation, least-privilege alternatives, a concrete rollback procedure, and detailed sensitive-data handling, so points are deducted.
Layered loading, capability checks, error taxonomy, and two-sided observability are useful; however, SKILL.md says it covers three libraries while CAPABILITIES.md introduces virtio-blk and NVMe, and sample coverage, pkg-config modules, and API details are inconsistent or delegated externally. No reproducible key-path tests are supplied, so the static score remains limited.
The audience, trigger phrases, exclusions, and library-versus-service routing are clearly described; however, Chinese-language support and mainland-China network reachability are not addressed, while core use depends on a local DOCA installation, hardware firmware, and other unavailable skills. Environment-fit evidence is therefore incomplete.
The loader, capability reference, task workflows, and details file provide useful progressive disclosure, dependency notes, maintenance contacts, and related-skill routing; however, version fields remain TBD, SKILLCARD repository/license/signature metadata conflicts with the supplied source, and there is no clear changelog or stable versioning policy, so points are deducted.
The material gives detailed configuration, build, run, test, and debug workflows with useful boundaries; however, it explicitly supplies no runnable code or standalone build manifest, exact module names and key API details require external lookup, and representative outputs are not verified. Substantial user completion work remains.
The files contain workflow checklists, an evaluation summary, and some audit-oriented metadata; however, the evaluation dataset is unavailable, the benchmark results are not independently reproducible, SKILLCARD signing and scan fields are TBD, and no committed CI/test suite covering the skill's key paths is provided. Evidence is therefore limited.
- The supported-library scope is internally inconsistent: SKILL.md primarily declares three classes, while CAPABILITIES.md mentions five; defer to installed headers, pkg-config, and runtime capability queries.
- Do not treat the BENCHMARK PASS or SKILLCARD signature fields as independently verified test evidence; the supplied files show incomplete evaluation, signing, and scan data.
- Execution involves PCIe-level emulation, sudo, and firmware configuration; obtain confirmation, verify the exact BlueField, firmware state, and host driver, and prepare reversible detach, stop, and destroy steps.
- No Chinese-language material or mainland-China reachability guarantee is provided, and key content depends on a local DOCA installation and routed companion skills.
What does this skill do, and when should you use it?
This skill is for external developers consuming the DOCA Device Emulation library from BlueField-side applications. It covers the PCI Generic, virtio-net, and virtio-fs sub-libraries and makes sub-library selection the first decision. It guides configure, build, modify, run, test, and debug workflows, including Core contexts, doorbells, DMA primitives, capability queries, and DOCA_ERROR_* diagnosis. It excludes DOCA installation, host kernel drivers, standard BlueField NIC behavior, and packaged SNAP or Virtio-net services.
Directs the agent to select PCI Generic, virtio-net, or virtio-fs; inspect libraries, headers, samples, and pkg-config modules under /opt/mellanox/doca; initialize the relevant DOCA Core context; configure doorbell and DMA primitives; query doca_devemu_*_cap_* capability families; and follow configure, build, modify, run, test, and debug workflows. It also routes DOCA setup, standard NIC, host-driver, and packaged-service questions to the named related skills.
- A DPU developer needs the host to enumerate a custom PCIe peripheral backed by DPU-side code.
- A developer is implementing an emulated virtio network or filesystem device for an existing host driver.
- A developer must choose between the PCI Generic, virtio-net, and virtio-fs Device Emulation sub-libraries.
- A developer is diagnosing missing lspci enumeration, driver binding failures, absent DPU responses to host queue kicks, or failed virtio feature negotiation.
- A developer is designing Rust, Go, or Python bindings over the DOCA Device Emulation C ABI.
What are this skill's strengths and limitations?
- Covers PCI Generic, virtio-net, and virtio-fs Device Emulation sub-libraries.
- Addresses capability discovery, doorbell/DMA primitives, permissions, and DOCA_ERROR_* categories.
- Clearly separates library development from packaged DOCA SNAP and Virtio-net Service solutions.
- Supports C and C++ directly and gives language-neutral guidance for other languages using FFI or bindings to the public C ABI.
- Requires the DOCA SDK on both host and DPU at /opt/mellanox/doca.
- Depends on firmware enablement, a matching host kernel driver, and appropriate DPU-side privileges.
- SKILL.md is a thin loader whose detailed guidance depends on companion files; their full contents are not included in the supplied material.
- Does not cover DOCA installation, firmware configuration, host-driver installation, backend-body design, or standard NIC behavior.
How do you install this skill?
Install the named skill with the skills CLI command documented in the repository README: npx skills add nvidia/skills --skill doca-devemu --yes. Add --agent codex to target Codex. The supplied source does not specify a manual-copy destination. The DOCA SDK must also already be installed at /opt/mellanox/doca on both the host and BlueField DPU.
How do you use this skill?
Give the agent a concrete DPU-side emulation request, for example: “Build a virtio-net emulated device on BlueField whose backend runs on the DPU, and first determine which DOCA Device Emulation sub-library applies.” For configure, build, modify, run, test, or debug work, the skill points to TASKS.md; for capability questions, it points to CAPABILITIES.md.
How does this skill compare with similar options?
The source explicitly distinguishes writing a backend with the doca-devemu library from adopting DOCA SNAP Service or DOCA Virtio-net Service, which are packaged services built on top of the library.