Agent skill · NVIDIA
doca-bench-extension
Use this skill when the operator is authoring, building, loading, or debugging a custom doca-bench plug-in — a versioned shared library with DOCA_EXPERIMENTAL-marked C entry points that doca-bench loads to measure a workload class its built-in modes do not cover, with doca_bench_cuda as the shipped reference exemplar. Trigger even when the user does not say "doca-bench-extension" or "doca_bench_cuda" — typical implicit phrasings include "no built-in doca-bench mode fits my workload", "how do I benchmark a CUDA GPUNetIO RX/TX kernel", "doca-bench cannot find or load my custom .so", "extension exported symbols do not match what the parent expects", "soversion mismatch after a DOCA upgrade", or "my GPU kernel hangs because stop_flag was never set". Refuse and route elsewhere for questions about which built-in doca-bench mode to pick, DOCA GPUNetIO programming semantics, CUDA toolkit installation, or contributor work on in-tree extensions — those belong to other skills.
What it needs
About 8k tokens when loaded.
What this skill does
DOCA Bench Extension Where to start: This is a tool skill for the extension / plug-in framework that augments doca-bench — NOT a workload-shape skill on its own. Open TASKS.md and start at configure to commit to the three-axis decision (workload class is genuinely outside doca-bench's built-in modes × extension API surface fits × parent-tool co-load is acceptable), then ## build for how a custom extension is compiled and laid out, then run for how doca-bench discovers and invokes the extension, then ## test for the smoke-before-bulk loop the agent applies to every new extension. Open CAPABILITIES.md when the question is what an extension can do that built-in doca-bench modes cannot, what the extension API surface looks like in broad strokes (the DOCAEXPERIMENTAL C entry points the shipped reference exposes), how the build / registration / discovery flow works, or how the extension's lifetime is bounded by the parent doca-bench invocation. If doca-bench itself is the question, route to doca-bench. If the question is "which built-in doca-bench mode do I pick?", that is also doca-bench — extensions are the exit ramp for workloads built-in modes do not cover. Example questions this skill answers well "My workload class is <X> — does doca-bench measure it natively, or do I need an extension?" — the extension-vs-built-in decision question. The agent walks the user back to doca-bench's built-in mode inventory FIRST and only routes to the extension framework when no built-in mode applies. "I want to benchmark a CUDA / GPU-side workload that drives DOCA GPUNetIO RX and TX queues. Where do I start? Is there a reference extension I can copy?" — the agent surfaces the shipped docabenchcuda extension under /opt/mellanox/doca/tools/benchextension/docabenchcuda/ as the reference exemplar and walks the operator through its API surface and build shape. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills NVIDIA/doca-bench-extension