What does this skill do, and when should you use it?
This skill targets Linux developers who already have the DOCA SDK installed and need to program packet steering on supported NVIDIA NICs or DPUs. It covers port and representor initialization, match/action pipes, forwarding targets, pre-programming validation, counter readback, and Flow API error diagnosis. It treats installed headers and shipped samples as the authority for API names and behavior, and requires applications to link libdoca_flow. It is guidance rather than a code bundle, so users must adapt a local DOCA Flow sample and build their own application.
Reads local pkg-config settings, DOCA headers, libraries, samples, and applications; guides verification of doca_flow_* and DOCA_* symbols; structures configure, build, modify, run, test, and debug workflows around samples under /opt/mellanox/doca/samples/doca_flow/; requires the Flow initialization, port start, pipe programming, entry commit, and counter-readback lifecycle; directs users to verify linkage with ldd; and refuses unsuitable code when a request exceeds one pipe stage, exceeds hardware capability, depends on an unverified API name, or accepts a kernel-only substitute.
- A network software developer needs to bring up a DOCA Flow port or representor on a supported NVIDIA NIC/DPU.
- A C/C++ developer needs to define match conditions, actions, pipes, forwarding targets, and hardware entries.
- A developer needs to validate a pipe specification before programming hardware or investigate commit failures and DOCA_ERROR_* results.
- An operations or performance engineer needs to read per-entry or per-pipe hardware counters under traffic.
- A binding author needs to expose the DOCA Flow C ABI through Rust, Go, Python, or another FFI language.
- A developer needs to add stateful five-tuple connection tracking to an existing DOCA Flow port.
How do you install this skill?
- Before execution, confirm the DOCA SDK, supported NIC/DPU, device placement, and capability set; the files do not provide a statically reproducible environment.
- Obtain explicit confirmation and prepare out-of-band recovery before touching live management ports or performing mlxconfig, sudo, or hardware-forwarding operations.
- Reconcile the inconsistent source, path, license, version, and benchmark metadata across SKILL.md, SKILLCARD.yaml, and BENCHMARK.md before publication.
- Do not treat the BENCHMARK.md PASS as independent validation; the report states that its evaluation dataset was unavailable.
- Shell / CLI
- Local filesystem
LinuxDOCA SDK installed at /opt/mellanox/docaSupported NVIDIA NIC or DPUpkg-configC or C++ toolchain
Install the individual skill with the Skills CLI command documented in the repository README:
npx skills add nvidia/skills --skill doca-flow --yes
The CLI prompts for the installation destination. The source does not document a fixed client-specific folder and says users do not need to clone the repository or copy skill directories manually. Run npx skills update to refresh installed skills.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-flow" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- How do I bring up a DOCA Flow port on a representor?
- How do I add hardware-accelerated stateful five-tuple connection tracking to my existing DOCA Flow setup?
In a Linux environment with the DOCA SDK, a supported NVIDIA NIC/DPU, and the SDK available at /opt/mellanox/doca, ask the agent questions such as “How do I bring up a DOCA Flow port on a representor?” or “How do I add hardware-accelerated stateful five-tuple connection tracking to my existing DOCA Flow setup?” Before writing or running port code, the agent should read the configure section of TASKS.md. Detailed workflows depend on TASKS.md and CAPABILITIES.md, whose complete contents are not included in the source material.
What are this skill's strengths and limitations?
- Enforces libdoca_flow and the complete DOCA Flow lifecycle instead of accepting tc, iptables/nftables, eBPF/XDP, OVS, or bare rte_flow as substitutes.
- Uses the installed headers, DOCA version, and shipped samples as the basis for API and build decisions.
- Covers port bring-up, pipe design, hardware validation, counter observability, and error diagnosis.
- Defines explicit refusal behavior for requests that exceed a pipe stage or hardware capability.
- Requires a Linux system with the DOCA SDK installed and a supported NVIDIA NIC or DPU attached.
- Does not include prewritten Flow application source, standalone build manifests, bindings, or a sample subtree.
- Important implementation details depend on TASKS.md and CAPABILITIES.md, which are not included in the supplied source.
- The source provides no test results, supported-device inventory, or cross-version validation evidence.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| NVIDIA DOCA Flow Development Skill this page ✓ NVIDIA · Official | 49 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Flow Tune ✓ NVIDIA · Official | 54 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA DPDK Bridge ✓ NVIDIA · Official | 49 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Compress Hardware Offload ✓ NVIDIA · Official | 58 · Recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA SHA Acceleration ✓ NVIDIA · Official | 56 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
Compared with kernel tc/flower, iptables/nftables, eBPF/XDP, OVS, and bare DPDK rte_flow without DOCA, this skill requires the deliverable to use DOCA Flow's pipe/entry lifecycle, capability discovery, and hardware counters. A kernel rule that merely reaches the NIC is not considered a successful DOCA Flow task.
How did FollowSkills review this skill?
The skill clearly scopes itself to DOCA Flow, requires installed-header verification, capability discovery, non-zero failure propagation, hardware-safety overlays, and rollback guidance, while refusing unsafe bypasses. However, confirmation gates are not consistently explicit, and the workflow still involves sudo, live traffic, and hardware-mode changes; permission isolation, data-flow disclosure, and recovery details remain incomplete, so points are deducted.
Configuration, build, test, debug, and abnormal-routing procedures are detailed and include failure signatures, feedback, and lifecycle constraints. However, key samples, headers, and companion skills must exist in the user's environment; no executable reproduction is included, and SKILL.md, SKILLCARD.yaml, and BENCHMARK.md contain source, path, and version inconsistencies, limiting static confidence.
The audience, trigger phrases, use cases, and out-of-scope boundaries are clearly stated, including C/C++ and FFI consumers. Chinese-language support, environment boundaries, and mainland-China reachability are not addressed, and the requirement for a local DOCA installation and supported hardware narrows applicability.
The material is layered into a loader, capability reference, and task workflows, with dependencies, sample pointers, limitations, error taxonomy, safety guidance, and related-skill routing. Author information, changelog, and stable version policy are incomplete; TBD signatures/versions and inconsistent source and license statements in SKILLCARD.yaml reduce maintainability confidence.
The skill covers core port bring-up, pipe design, capability checks, counters, and debugging, and directs users to derive work from installed samples. It ships no application source, build manifest, or bindings, so results require local adaptation and review; under static calibration the score cannot exceed 7, and 6 is warranted conservatively.
The skill specifies header checks, installed samples, pkg-config, ldd, counters, and error validation, and includes limited benchmark evidence. The underlying evaluation dataset is unavailable, and no committed test suite or CI evidence covers the key paths, so static verifiability remains below the ceiling.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →