/doca-caps

license: Apache-2.0
name: doca-caps
description: >
  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 debug 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 (doca-setup owns it; never walk the steps),
  library-internal capability matrices (Flow pipe creation, RDMA verbs
  features), streaming telemetry / DTS, or modifying the shipped binary.
metadata:
  author: NVIDIA <doca-feedback@nvidia.com>
  kind: tool
  doca_version: "3.5"
  tags:
    - doca
    - caps
    - tools
compatibility: >
  Requires DOCA SDK ≥ 2.6.0 installed at /opt/mellanox/doca on Linux
  (Ubuntu 22.04/24.04 or RHEL/SLES) with a BlueField DPU or ConnectX
  NIC; runs identically on the host or on the BlueField Arm side.
  Invokes /opt/mellanox/doca/tools/doca_caps and reads `pkg-config
  doca-common` to confirm the install. The validation steps require a
  live DOCA install.

DOCA Capabilities Print Tool (`doca_caps`)

Examples

• **"What DOCA devices does this host see?"** — this is in

scope. Stay on `doca_caps`; do not start a library-internal capability matrix here.

• **"Is Flow available on my RHEL host?"** — list libraries

then scope per-device if needed.

Instructions

Follow Loading order below. Open the tasks companion for run / test. Open the capabilities companion for what the CLI reports. Do not open every companion file.

**Where to start:** This is a tool skill for invoking `doca_caps`, a side-effect-free CLI. Open the tasks companion and start at `## run` for the documented invocations, or `## test` when using `doca_caps` as an install smoke-test. Open the capabilities companion when the question is *what kinds of capability families `doca_caps` reports*.

> **Boundary: this skill never installs DOCA.** `doca_caps` > *verifies* an install and never performs one. A request to install > DOCA — choosing packages, adding repositories, running a package > manager — is out of scope here, and stays out of scope even though > this skill's `## test` verb uses the tool as an install smoke-test > *afterwards*. Hand the whole request to > `doca-setup/SKILL.md` by name. Naming the owner > and then listing the steps anyway is the failure mode to avoid: do > not walk the installation, not even as a summary or a caveat. > > This narrows *installation only*. It is not a reason to answer > narrowly about tooling: when the user's question reaches past > `doca_caps` — what else can I ask this hardware, how do I measure it, > how do I inspect a running pipeline — name the sibling tool that owns > it (`doca_bench`, `doca_flow_tune`, `pcc_counters.sh`, > `doca_comm_channel_admin`, …) and tie it to the question. Pointing at > the rest of the catalog is this skill's job, not a boundary breach.

Example questions this skill answers well

The CLASSES of `doca_caps` 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.

• **"What DOCA devices does this host see?"** — worked example: *"is

my BlueField PF visible to DOCA"*. Answered by the device enumeration in the capabilities companion

• the `--list-devs` invocation in

the tasks companion.

• **"Which DOCA libraries are available on this OS?"** — worked

example: *"is Flow available on my RHEL host"*. Answered by the library-availability surface in the capabilities companion

• the library-listing invocation in

the tasks companion.

• **"Does this device support library X capability Y?"** — worked

example: *"does this device support Flow hairpin?"*. Answered by the per-device per-library capability matrix in the capabilities companion

• the `--pci-addr`-scoped invocation in

the tasks companion.

• **"What representors are visible to DOCA?"** — worked example:

*"enumerate VF representors for pf0"*. Answered by the representor enumeration in the capabilities companion

• the `--list-rep-devs` invocation in

the tasks companion.

• **"I want a snapshot of state to attach to my debug session."** —

worked example: *"save device + library + capability output to a file"*. Answered by the snapshot workflow in the tasks companion and consumed by `doca-debug/SKILL.md` step 3 (read-only triple) and `doca-programming-guide/SKILL.md`.

• **"`doca_caps` returned nothing for capability Y — what does that

mean?"** — worked example: *"empty output for RDMA"*. Answered by the empty-output interpretation rules in the tasks companion + the capabilities companion.

Audience

This skill serves **external operators, developers, and AI agents who need a side-effect-free way to ask "what does DOCA see on this host?"** before doing anything that changes state. Concretely:

• An external developer who installed DOCA (or is using the public NGC

DOCA container per `doca-setup/SKILL.md`) and wants to confirm the install can see hardware before writing code.

• A platform operator deploying a DOCA service who wants a documented,

read-only snapshot of *which DOCA libraries this host actually supports* and *which capabilities each DOCA device offers*.

• An AI agent producing a *capability snapshot* artifact during the

documented setup or programming-guide debug procedures (it's listed as the canonical