doca-bench-extension

Featured

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.

AI & Automation 3,042 stars 352 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 99/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# DOCA Bench Extension **Where to start:** This is a tool skill for the **extension / plug-in framework** that augments [`doca-bench`](../doca-bench/SKILL.md) — NOT a workload-shape skill on its own. Open [`TASKS.md`](TASKS.md) and start at [`## configure`](TASKS.md#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`](TASKS.md#build) for how a custom extension is compiled and laid out, then [`## run`](TASKS.md#run) for how `doca-bench` discovers and invokes the extension, then [`## test`](TASKS.md#test) for the smoke-before-bulk loop the agent applies to every new extension. Open [`CAPABILITIES.md`](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 `DOCA_EXPERIMENTAL` 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`](../doca-bench/SKILL.md). If the question is "which built-in `doca-bench` mode do I pick?", that is also [`doca-bench`](../doca-bench/SKILL.md) — 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 `...

Details

Author
NVIDIA
Repository
NVIDIA/skills
Created
5 months ago
Last Updated
today
Language
Python
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Featured

doca-bench

Run `doca_bench` (DOCA 2.7.0 or newer) to measure throughput, bulk latency, precision latency, or maximum bandwidth for RDMA, Compress, AES-GCM, SHA, DMA, EC, Ethernet, Comch, or GPUNetIO on a host or BlueField Arm. Use it to discover enabled benchmark libraries, capture a reproducible command/version/device/environment baseline, compare stable runs against a declared tolerance, or diagnose configuration, device-binding, workload-precondition, and measurement failures. Trigger for requests such as measuring BlueField compression speed, NIC RDMA throughput, crypto latency, or a pre-upgrade baseline. Do not use for application end-to-end timing, custom benchmark code, DOCA installation, or binary patches.

3,042 Updated today
NVIDIA
AI & Automation Featured

doca-common

Use this skill whenever the user is doing hands-on DOCA programming on a BlueField DPU or ConnectX NIC and needs the foundation primitives every per-library context rests on — walking the doca_ctx lifecycle, discovering doca_dev / doca_devinfo and gating on doca_*_cap_* before trusting a feature, wiring doca_mmap / doca_buf_inventory / doca_buf for zero-copy I/O across libraries, driving doca_pe for completions, or DOCA Log's two-tier (--sdk-log-level vs app-side) model. Trigger even when the user does not say "DOCA Common" — typical implicit phrasings include "my tasks submit but nothing completes", "DOCA_ERROR_BAD_STATE from doca_ctx_start", "--sdk-log-level does nothing for my DOCA_LOG_DBG lines", "share a buf between doca_dma and doca_rdma", or "crashes far from the offending line". Refuse and route elsewhere for per-library questions in isolation (load doca-flow / doca-rdma / doca-eth alongside), installing DOCA (doca-setup), or doc lookup (doca-public-knowledge-map).

3,042 Updated today
NVIDIA
AI & Automation Featured

doca-caps

Use this skill when the user wants to invoke the read-only doca_caps CLI to ask what DOCA sees on this host — listing DOCA devices and PCIe addresses, listing representor devices, asking which DOCA libraries are available on the current OS, checking per-device per-library capabilities, scoping output to a specific PCIe address, or capturing a side-effect-free capability snapshot for a debug session or install smoke-test. Trigger even when the user does not explicitly mention "doca_caps" or "capabilities print tool" — typical implicit phrasings include "what does DOCA actually see on this box", "is my BlueField PF visible to DOCA", "is Flow available on my RHEL host", "enumerate VF representors for pf0", "doca_caps: command not found", or "empty output for RDMA, is the tool broken". Refuse and route elsewhere for DOCA installation, library-internal capability matrices (Flow pipe creation, RDMA verbs features), streaming telemetry / DTS, or modifying the shipped binary — those belong to other skills.

3,042 Updated today
NVIDIA