DOCA Bench Extension Builder
Build, load, smoke-test, and debug custom doca-bench plug-ins for workloads beyond built-in modes.
The documentation requires prerequisite checks, smoke-before-scale execution, log capture before retries, and disclosure of crash, hang, and dataplane risks from loading custom code into the parent process and device environment. It lacks execution isolation, fully explicit user-authorization boundaries, and a complete rollback/recovery procedure, so points are deducted from the midrange.
SKILL.md, CAPABILITIES.md, and TASKS.md provide a substantial configure/build/run/test/debug workflow and require intelligible, verbatim failure feedback. However, the key runtime discovery mechanism depends on external documentation and the local installation; nothing was executed, and static calibration caps the score at 10.
The intended audience, trigger phrases, non-fit cases, companion skills, and Linux/DOCA/hardware prerequisites are clearly described. The skill is aimed at advanced Meson, shared-library, CUDA, and GPUNetIO users, contains no Chinese-language guidance, and depends partly on docs.nvidia.com, which may be difficult to reach from mainland China, so points are deducted.
The material is layered across capabilities, tasks, error taxonomy, and safety policy, with examples, dependencies, and rebuild/version rules. Versioning, authorship, maintenance ownership, and change history are incomplete; BENCHMARK.md also records missing recommended Instructions/Examples and author metadata. License declarations are inconsistent with the prompt's NOASSERTION metadata and the SKILLCARD contents, so points are deducted.
The skill offers directly useful guidance for extension selection, reference adaptation, SONAME checking, smoke testing, and layered debugging. Its runtime discovery recipe is intentionally incomplete and requires local installation details plus external documentation, leaving substantial environment-specific validation to the user; the static score is therefore kept below the allowed maximum.
The files contain auditable workflow descriptions, symbol shapes, paths, and a claimed evaluation report. They do not include a committed test suite covering the key paths or independently reproducible third-party execution evidence, so the reported evaluation cannot fully substantiate the claims and verifiability remains limited.
- Custom extensions run inside the doca-bench address space, and GPU kernels may hang and require an OOB reset; confirm isolation, co-tenancy impact, recovery authority, and user consent before execution.
- Runtime discovery, exact API details, and some version behavior depend on the local DOCA installation and external NVIDIA documentation; they cannot be confirmed from this static skill alone.
- License and provenance metadata are inconsistent: the prompt states NOASSERTION, while different files declare Apache-2.0 or Apache-2.0 AND CC-BY-4.0.
- The skill is English-only, and reliance on external documentation may reduce reachability for mainland-China users.
What does this skill do, and when should you use it?
This skill serves platform and performance engineers whose workload is not covered by doca-bench's built-in modes. It guides the extension workflow from configuration through build, runtime loading, testing, and layered debugging. Extensions are versioned Linux shared libraries that expose DOCA_EXPERIMENTAL-marked C entry points and are invoked by the parent doca-bench tool. The shipped doca_bench_cuda implementation is the reference exemplar for GPU-side workloads, while DOCA GPUNetIO semantics and CUDA installation remain outside this skill's scope.
It helps the operator decide whether an extension is necessary, locate the reference tree at /opt/mellanox/doca/tools/bench_extension/doca_bench_cuda/, and follow its Meson build and API shape. It explains versioned shared-library packaging, workload settings structures, parent-tool invocation, and the cheapest smoke test before bulk benchmarking. It also separates build failures, loading failures, registration mismatches, and runtime call failures.
- A performance engineer needs to measure a workload class that no built-in doca-bench mode supports.
- A CUDA or GPUNetIO engineer wants to adapt the shipped doca_bench_cuda reference extension.
- A custom shared object builds successfully but doca-bench cannot find, load, or call it.
- An operator must diagnose a soversion or DOCA_EXPERIMENTAL compatibility problem after a DOCA upgrade.
- A team wants to verify extension discovery and returned data before running its production workload benchmark.
What are this skill's strengths and limitations?
- Covers the custom-plugin lifecycle from extension-vs-built-in decisions through debugging.
- Uses doca_bench_cuda as a concrete reference for API shape and build layout.
- Keeps built-in benchmarking, GPUNetIO semantics, and CUDA installation in their proper companion resources.
- Makes DOCA versioning, soversion matching, and experimental API stability explicit.
- It is not a replacement for the doca-bench built-in mode inventory and adds unnecessary cost when a built-in mode fits.
- It assumes a Linux native-build environment with the DOCA SDK and compatible hardware; the GPU exemplar adds CUDA requirements.
- The provided SKILL.md does not document every entry-point signature or the complete runtime discovery mechanism.
- DOCA_EXPERIMENTAL APIs and release-matched soversion can require rebuilding after DOCA upgrades.
How do you install this skill?
Install the skill from the NVIDIA/skills collection with: npx skills add nvidia/skills --skill doca-bench-extension --yes. The repository README states that the skills CLI runs through npx and makes the skill available the next time the agent loads relevant skills. Running the extension also requires the DOCA SDK at /opt/mellanox/doca on Linux, a BlueField DPU or ConnectX NIC, and pkg-config doca-common; the GPU reference additionally requires an NVIDIA GPU and matching CUDA toolkit.
How do you use this skill?
In an Agent Skills-compatible client, use a prompt such as: “No built-in doca-bench mode fits my workload. How do I build and load a custom extension?” The skill's workflow first checks that DOCA and doca-bench are available, then confirms that no built-in mode applies, and proceeds through configure → build → run → test → debug. The exact runtime discovery mechanism must be taken from the installed doca-bench binary, the shipped extension's meson.build, and NVIDIA's public documentation; this SKILL.md deliberately does not invent it.
How does this skill compare with similar options?
Compared with doca-bench's built-in modes, this skill addresses the external extension path for workload classes those modes do not cover; built-in-mode selection remains the responsibility of the doca-bench skill.