/doca-flow-dpa-perf

license: Apache-2.0
name: doca-flow-dpa-perf
description: >
  Use this skill when the user is invoking doca_flow_dpa_perf on
  DPA-capable hardware (ConnectX-7 minimum supported,
  ConnectX-8 recommended, or BlueField-3) to measure rule
  update / disable rates on the DPA-offloaded DOCA Flow path —
  picking the active / passive device split, choosing workload-shape
  axes (burst, queue, completion threshold, workers, hash pipe algo,
  PSL tables), or reading Kops/sec iteration stats and the optional
  self-test. Trigger even when the user does not explicitly mention
  "doca_flow_dpa_perf" or "DPA Provider" — typical implicit phrasings
  include "how fast can the DPA program path-selector entries",
  "baseline rule-update rate on ConnectX-8", "tool reports zero ops
  on my BlueField", "self-test sentinel never shows on tcpdump", or
  "is my BlueField-2 DPA-capable". Refuse and route elsewhere for the
  host / DPU-CPU Flow path (doca-flow-perf), Flow pipeline tuning
  (doca-flow-tune), writing doca-flow / doca-dpa applications, or
  DOCA install — those belong to other skills.
metadata:
  kind: tool
compatibility: >
  Requires DOCA SDK installed at /opt/mellanox/doca on Linux (Ubuntu
  22.04/24.04 or RHEL/SLES) with a DPA-capable device attached —
  ConnectX-7 as the minimum supported ConnectX generation,
  ConnectX-8 recommended, or BlueField-3 (BlueField-2 and earlier
  ConnectX are unsupported). VNF Flow mode required; PF or VF only (SFs are not
  supported on the DPA path). Reads `pkg-config doca-flow` and the
  shipped `doca_flow_dpa_perf` binary plus its README on the user's
  install.

DOCA Flow DPA Perf (`doca_flow_dpa_perf`)

**Where to start:** This is a tool skill for invoking `doca_flow_dpa_perf`, the DPA-accelerated Flow performance tool. Open [`TASKS.md`](TASKS.md) and start at [`## configure`](TASKS.md#configure) to confirm DPA-capable hardware + VNF Flow mode + the active / passive device split, then [`## run`](TASKS.md#run) for the smoke-before-bulk flow with a small operation count before any sweep, then [`## test`](TASKS.md#test) for the eval-loop overlay that gates defensible Kops/sec numbers. Open [`CAPABILITIES.md`](CAPABILITIES.md) when the question is *what `doca_flow_dpa_perf` can measure*, *what the DPA preconditions are*, *which devices it runs on*, or *how to interpret update / disable / self-test output without fooling yourself*. If DOCA is not installed yet, route to [`doca-setup`](../../doca-setup/SKILL.md) first; if the device is not DPA-capable (no ConnectX-7+ or BlueField-3+) then this tool is the wrong surface and the right answer is [`doca-flow-perf`](../doca-flow-perf/SKILL.md).

Example questions this skill answers well

The CLASSES of `doca_flow_dpa_perf` questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

• **"Should I measure the DPA-offloaded Flow path or the

host / DPU-CPU Flow path for this question?"** — worked example: *"my workload programs path-selector entries via DOCA Flow; do I baseline with `doca_flow_dpa_perf` or with `doca_flow_perf`?"*. Answered by the *DPA-vs-host* boundary in [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes) and the device-preconditions table.

• **"What does the DPA-offload actually accelerate, and what

doesn't it change?"** — worked example: *"if I move my Flow rule update path to the DPA, what changes in the data plane for the packets themselves?"*. Answered by the DPA-Provider scope in [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes).

• **"What hardware do I need to use this tool at all?"** —

worked example: *"is my BlueField-2 DPA-capable?"*. Answered by the device-preconditions table in [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes) (BlueField-3 yes, BlueField-2 no; ConnectX-7 minimum supported, ConnectX-8 recommended, and later generations supported per the public guide and the shipped README on the user's install).

• **"How do I size my run — burst, queue, completion threshold,

number of operations, iterations — to get a defensible Kops/sec number?"** — worked example: *"I want the median iteration time and standard deviation, not a single noisy first-iteration spike"*. Answered by the eval-loop overlay in [`TASKS.md ## test`](TASKS.md#test) and the iteration-stats rule in [`CAPABILITIES.md ## Observability`](CAPABILITIES.md#observability).

• **"My tool reports zero ops / hangs / fails the self-test —

what does that mean?"** — worked example: *"the tool runs but the self-test step fails"*. Answered by the layered error taxonomy in [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)

• the debug ladder in

[`TASKS.md ## debug`](TASKS.md#debug).

• **"How do I quote a DPA-perf number alongside a host-side

Flow-perf number for the same workload, in a way the next engineer can actually compare?"** — worked example: *"two Kops/sec numbers for what is supposedly the same workload"*. Answered by the four-tuple capture rule in [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)

• the per-tool-name rule (the host tool and the DPA tool are

different surfaces; their numbers are not interchangeable without naming which tool produced which).

Audience

This skill serves **external operators, performance engineers, DOCA Flow application developers, and AI agents who need a defensible measurement of the DPA-offloaded Flow update path** on DPA-capable hardware. Concretely:

• A platform operator deciding whether to move a path-selector

workload onto the DPA versus keeping it on the host / DPU-CPU path, and wanting a number to compare.

• A performance engineer producing a *"DPA Kops/sec for update

operation, queue-size X, burst-size Y, N workers"* baseline on a specific device + DOCA versio