doca-pcc-counters · git:20260727.a5736e4 · 2026-07-27 · sha256 3f7bed79c883d8c1
doca-pcc-counters git:20260727.a5736e4A
Immutable. This exact content is served forever at /api/v1/blob/3f7bed79c883d8c1.
--- license: Apache-2.0 name: doca-pcc-counters description: > Use this skill when the user is invoking the DOCA PCC Counters tool — the `pcc_counters.sh` bash script under the DOCA tools directory — to arm and read the fixed firmware/hardware PCC (Programmable Congestion Control) diagnostic counters (CNP, RTT, WRED-drop, etc.) on a ConnectX / BlueField device via mst + the mlx5 debugfs `diag_cnt` interface. The script takes two positional args — `set | query` and an mst device path — with no `--help` or subcommands. Trigger even without "pcc_counters.sh" or "PCC counters": "how do I read the CNP / RTT / WRED-drop counters", "PCC counter stuck at zero", "the script says Bad Device", or "is congestion control dropping packets on this port?". Route elsewhere for writing a custom PCC algorithm (doca-pcc), factory firmware PCC config, DOCA install, or fleet-wide CC tuning. metadata: kind: tool compatibility: > Requires DOCA/MFT on Linux with a ConnectX-6 or newer or BlueField device, mst tools, mounted debugfs, and root access to the mlx5 diag_cnt interface. The script reads fixed firmware and hardware diagnostics independently of custom PCC code. Its set operation changes which counters are collected, not congestion-control or forwarding behavior; treat later fleet tuning as a separate high-stakes action. --- # DOCA PCC Counters (`pcc_counters.sh`) **Where to start:** This is a tool skill for invoking `pcc_counters.sh` — a small bash script that arms and reads the device's fixed set of firmware / hardware **PCC diagnostic counters** (CNP count, RTT-perf, WRED-drop, RTT-gen, handled events) through the mlx5 debugfs `diag_cnt` interface. Open [`TASKS.md`](TASKS.md) and start at [`## run`](TASKS.md#run) for the canonical `set`-then-`query` sequence, or [`## debug`](TASKS.md#debug) when the user reports *"`ERROR: Bad Device`"*, *"counter stuck at zero"*, or *"the dump is empty"*. Open [`CAPABILITIES.md`](CAPABILITIES.md) when the question is *which counters the script reports and how it reaches them*. If the user has not installed DOCA / MFT yet, route to [`doca-setup`](../../doca-setup/SKILL.md) first. This skill is the **firmware / HW PCC counter readout** surface. It is NOT the host-side control library that loads custom congestion-control kernels onto the DPA (that is [`doca-pcc`](../../libs/doca-pcc/SKILL.md)) and it is NOT the firmware PCC *algorithm* configuration (that path is firmware configuration, routed via [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)). The counters this script reads are device / firmware diagnostic counters that exist **regardless of whether a custom `doca-pcc` DPA kernel is running** — do not condition them on a custom kernel being loaded. ## Example questions this skill answers well The CLASSES of `pcc_counters.sh` 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. - **"How do I read the PCC diagnostic counters on this device?"** — worked example: *"arm and dump the CNP / RTT / WRED-drop counters for `/dev/mst/mt41692_pciconf0`"*. Answered by the fixed counter set in [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes) + the `set`-then-`query` invocation in [`TASKS.md ## run`](TASKS.md#run). - **"What is the smallest legal invocation?"** — worked example: *"what exactly do I type?"*. Answered by the two-positional-argument contract (`set | query` + an mst device path) in [`TASKS.md ## run`](TASKS.md#run). - **"The script printed `ERROR: Bad Device` — what's wrong?"** — worked example: *"my device path is not matching"*. Answered by the device-resolution layer in [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy) + [`TASKS.md ## debug`](TASKS.md#debug). - **"A counter is stuck at zero — is the device idle, the counters not armed, or genuinely no events?"** — worked example: *"`PCC_CNP_COUNT` reads 0 after `query`"*. Answered by the arm-before-read rule and the layered diagnosis in [`TASKS.md ## debug`](TASKS.md#debug) + [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy). - **"Is this script on my install, and where?"** — worked example: *"is `pcc_counters.sh` present and where does the install put it"*. Answered by the install overlay in [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility), which redirects to the canonical [`doca-version`](../../doca-version/SKILL.md) rules. ## Audience This skill serves **operators, developers, and AI agents who need to read a ConnectX / BlueField device's firmware PCC diagnostic counters** to reason about congestion-control behaviour (CNP generation, RTT requests/responses, WRED drops) on a port. Concretely: - A network operator confirming whether congestion-control events (CNPs, RTT, WRED drops) are occurring on a device. - A developer correlating a custom `doca-pcc` algorithm's effect with the device-level PCC diagnostic counters (the script reads the firmware counters; the custom algorithm itself is a separate surface owned by [`doca-pcc`](../../libs/doca-pcc/SKILL.md)). - An AI agent producing a *PCC counter snapshot* as evidence for a congestion-control investigation. It is **not** for users debugging the script's bash itself, **not** the place to learn how to write a custom PCC algorithm — that audience belongs in [`doca-pcc`](../../libs/doca-pcc/SKILL.md) — and **not** the place for users who want to configure the factory firmware PCC algorithm (route via [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)). `pcc_counters.sh` is shipped as a **plain bash script** installed under the DOCA tools directory (per `install_data` in `tools/pcc_counters/meson.build`), not a compiled binary and not a library you link against. The skill uses the bundle's `kind: tool` three-file shape (`SKILL.md` + `CAPABILITIES.md` + `TASKS.md`) so the agent's task-verb contract (`configure / build / modify / run / test / debug`) is uniform across the bundle. ## When to load this skill Load this skill when the user is — or the agent needs to — arm and read the device PCC diagnostic counters on a host or BlueField Arm with the mst tools available and debugfs mounted. Concretely: - Arming the diagnostic counters with `set` on a target mst device. - Reading the armed counters with `query` and quoting the named counter lines verbatim. - Capturing a counter readout as evidence for a congestion-control investigation. Do **not** load this skill for general DOCA orientation, custom-PCC algorithm design, the host-side `doca-pcc` library API, the factory firmware PCC algorithm, or DOCA / MFT install. For those, route to [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md), [`doca-pcc`](../../libs/doca-pcc/SKILL.md), or [`doca-setup`](../../doca-setup/SKILL.md). ## What this skill provides This is a **thin loader**. Substantive material lives in two companion files: - `CAPABILITIES.md` — what `pcc_counters.sh` does: the exact two-operation surface (`set` arms the device's diagnostic counters by writing counter IDs + params to debugfs; `query` reads the `diag_cnt/dump` and prints the named counters), the FIXED firmware / HW counter set it knows (`PCC_CNP_COUNT`, the `MAD_RTT_PERF_CONT_*`, the `*_EVENT_WRED_DROP` family, `HANDLED_*_EVENTS`, the `DROP_RTT_PORT*`/`RTT_GEN_PORT*` families), how it resolves an mst device to a PCI address (`mst status -v` + `lspci`) and reaches `/sys/kernel/debug/mlx5/<pci>/diag_cnt/`, the install-availability overlay that redirects to [`doca-version`](../../doca-version/SKILL.md), the layered error taxonomy (script-not-present / bad-device / not-armed-before-query / debugfs-or-permission / counter-stuck-at-zero / cross-cutting), and the safety policy that flags `set` as a privileged debugfs write and any CC tuning decision derived from a reading as high-stakes. - `TASKS.md` — step-by-step workflows for the in-scope task verbs: `configure` (route to install + confirm mst / debugfs / sudo), `build` (route to install; nothing to compile — it is a script), `modify` (refuse — do not patch the shipped script), `run` (the `set`-then-`query` sequence), `test` (confirm the dump contains the named counters with finite values), `debug` (the layered diagnosis ladder), plus a `Deferred task verbs` block and a `Command appendix`. The skill assumes a host or BlueField where DOCA / MFT is already installed (mst tools present, debugfs mounted, sudo available) and the target device is visible to `mst status -v`. ## What this skill deliberately does not ship This skill is **agent guidance**, not a samples or scripts bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add: - **Invented flags or subcommands.** `pcc_counters.sh` has exactly two operations (`set`, `query`), takes exactly two positional arguments, and has NO `--help`, `--version`, `list`, `snapshot`, `watch`, or `diff`. Do not invent any. - **Pre-baked example counter values.** Counter values are device-, firmware-, and traffic-state-specific; a captured value will mislead an operator on a different device. - **Wrappers, parsers, or rewritten copies of the script.** The script is the contract; modifying or re-implementing it is out of scope. - **A specific congestion-control tuning recommendation derived from a counter reading.** That is a high-stakes domain question — the skill prescribes how to *capture* the counters; it refuses to translate a delta into a CC parameter change without the user's own domain analysis. - **A `samples/` or `reference/` subtree.** This is a thin loader for a documented script; substantive material lives in the script and the public PCC documentation. ## Loading order 1. Read this `SKILL.md` first to confirm the user's question is in scope (reading the device's firmware PCC diagnostic counters; not designing or loading a custom algorithm). 2. **For what the script does, the fixed counter set, the debugfs mechanism, the install-availability overlay, the layered error surface, and the safety posture, see [CAPABILITIES.md](CAPABILITIES.md).** 3. **For the documented invocations — `configure`, `build`, `modify`, `run`, `test`, `debug`, plus the `Command appendix` — see [TASKS.md](TASKS.md).** ## Related skills - [`doca-pcc`](../../libs/doca-pcc/SKILL.md) — the host-side library for writing and loading custom congestion-control kernels onto the DPA. It is a SEPARATE surface: the firmware PCC diagnostic counters `pcc_counters.sh` reads exist independently of any custom `doca-pcc` kernel, but an operator tuning a custom algorithm may read these counters to observe device-level CC behaviour. Conflating the script (firmware counter readout) with the library (custom algorithm load/control) is the most common PCC first-touch error. - [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md) — routing to the public DOCA / PCC documentation set, including the firmware PCC algorithm configuration. - [`doca-version`](../../doca-version/SKILL.md) — canonical DOCA version-handling rules. The `## Version compatibility` section in [`CAPABILITIES.md`](CAPABILITIES.md) is a concise overlay that redirects here. - [`doca-setup`](../../doca-setup/SKILL.md) — env preparation, install verification, mst tools, debugfs, and the *I have no install yet* path with the public NGC DOCA container. This skill assumes its preconditions are satisfied. - [`doca-debug`](../../doca-debug/SKILL.md) — the cross-cutting debug ladder. The PCC counter readout slots in as a read-only device-state evidence source before any congestion-control tuning recommendation is made. - [`doca-programming-guide`](../../doca-programming-guide/SKILL.md) — general DOCA programming patterns shared across the bundle.