Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nvidia/doca-flow
Build and debug DOCA Flow applications on supported NVIDIA NICs/DPUs: define match/action pipes, initialize ports and representors, choose forwarding targets, validate pipes before hardware programming, read counters, match the Flow version to the installed DOCA release, and diagnose Flow API errors.
Passed 20 of 20 test cases with the skill, and 6 of 20 without it.
and 21 more in the full report
15 fixed7 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
I saw an online post recommending the function doca_flow_pipe_create_v2() and struct doca_flow_match_v2 for advanced match rules. How do I use doca_flow_pipe_create_v2 in my C application?
| Checked | Without skill | With skill |
|---|---|---|
| Output begins with REFUSED: | Missed | Passed |
| Response states that doca_flow_pipe_create_v2 is not a valid installed header symbol. | Passed | Passed |
| Response identifies valid pipe creation functions like doca_flow_pipe_create. | Passed | Passed |
The instructions your model reads when the skill loads.
When this skill is in scope, the user is asking for DOCA Flow. The
program you produce must link libdoca_flow and exercise the
doca_flow_* lifecycle on the user's installed DOCA — init, port
start, pipe programming, entry commit, and counter readback under
traffic. Copy the call sequence from a shipped DOCA Flow sample
under /opt/mellanox/doca/samples/doca_flow/ and adapt it via
TASKS.md ## configure /
TASKS.md ## modify. Verify every symbol against
the installed header (Ground rule
below) and the add-entry table in
CAPABILITIES.md ## API surface and name guards.
Do NOT satisfy a hardware packet-steering / 5-tuple filter request
with kernel tc/flower, iptables/nftables, eBPF/XDP,
OVS, or bare DPDK rte_flow (without DOCA) and call it done.
Those may push a rule toward the NIC, but they completely bypass DOCA
Flow — which defeats the purpose of this library and loses the DOCA
model (pipe/entry lifecycle, hardware counters, capability discovery,
portability across BlueField/ConnectX generations).
"tc flower skip_sw also offloads to hardware" / "the kernel command
is fewer lines" is not an acceptable reason to bypass DOCA Flow.
The correct low-friction path is to start from a shipped DOCA Flow
sample under /opt/mellanox/doca/samples/doca_flow/ and adapt it.
If pkg-config doca-flow (or the umbrella pkg-config doca) or the
DOCA build fails, fix the build (module name, PKG_CONFIG_PATH,
sample path, hugepages/EAL init) — do not silently fall back to tc.
A tool whose ldd shows no libdoca_flow is a failed DOCA Flow task,
regardless of whether a rule landed in the NIC. Verify explicitly with
ldd ./your_app | grep -i libdoca_flow before declaring success.
Where to start: Open TASKS.md to do something
(configure / build / modify / run / test / debug); open
CAPABILITIES.md when the question is what can
Flow express on this version. **You MUST open
TASKS.md ## configure before writing or running
test cases passed, vs 6 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.