Doca Rmax

DOCA Rivermax

Where to start: This skill assumes DOCA is already installed,

AND that the NVIDIA Rivermax SDK is separately installed with a

valid Rivermax license present on the host. The agent's FIRST

action on any Rivermax question is to confirm both — without

Rivermax SDK + license, doca-rmax cannot function regardless

of how clean the DOCA-side code is, and this is the #1 first-app

confusion (DOCA does *not* bundle Rivermax; it wraps it). Open

TASKS.md if the user wants to *do* something

(configure / build / modify / run / test / debug); open

CAPABILITIES.md when the question is *what

can DOCA Rivermax express* on this version + this Rivermax

install. If the user has not installed DOCA yet, route to

doca-setup first; for the Rivermax

SDK + license install itself, route to the public DOCA Rivermax

guide (slug DOCA-Rivermax) via

doca-public-knowledge-map.

If the user is asking *"how do I get packets to land on my

Rivermax input stream at all"*, the answer is layered:

doca-rmax is the *Rivermax integration* surface,

doca-eth is the *queue* surface that

carries the packets, and doca-flow

is the *steering* surface that directs them.

Example questions this skill answers well

The CLASSES of DOCA Rivermax questions this skill is built to

answer, each with one worked example. The agent should treat the

*class* as the load-bearing piece — the worked example is a

single instance.

• "Can I even use doca-rmax on this host?" — worked

example: *"the public docs mention doca-rmax; is it

usable without doing anything else?"*. Answered by the

Rivermax-SDK + license precondition rule in

CAPABILITIES.md ## Safety policy

+ the env-prep checklist in

TASKS.md ## configure step 1, which

routes the install-side question to the public Rivermax guide

via

doca-public-knowledge-map

and refuses to recommend a fallback to doca-eth alone that

would silently lose the timing properties.

• "How do I set up a SMPTE ST 2110 video receive stream?" —

worked example: *"line up an inbound Rivermax stream on a

representor of a BlueField port for first-run testing"*.

Answered by the per-stream object lifecycle in

TASKS.md ## configure +

CAPABILITIES.md ## Capabilities and modes

input stream capability table.

• **"Which doca_rmax_get_*_supported query do I have to call before

picking a PTP clock or hardware packet-placement order?"** — worked

example: *"can this device + this Rivermax install use

ST 2110-20 sequence-number placement?"*. Answered by the

capability-query rule in

CAPABILITIES.md ## Capabilities and modes

+ step 3 in

TASKS.md ## configure.

• "My stream is set up but no packets arrive — why?" —

worked example: *"the Rivermax stream object started cleanly

but no recv events fire"*. Answered by the precondition matrix

in

CAPABILITIES.md ## Safety policy

+ the env-prep checklist in

TASKS.md ## configure step 1, which

routes the steering side to

doca-flow, the queue side to

doca-eth, and the license side

back to the Rivermax-side precondition.

• **"Is this Rivermax integration capability available on my

device + my installed DOCA + my Rivermax SDK?"** — worked

example: *"does this device + this Rivermax version advertise

the PTP clock or placement mode I need"*. Answered by the capability-query

rule in

CAPABILITIES.md ## Capabilities and modes

+ the version-and-device overlay in

CAPABILITIES.md ## Version compatibility,

which adds the *Rivermax-side version is a second axis* rule

on top of the canonical DOCA version-handling chain in

doca-version.

• **"What does this DOCA_ERROR_* from a Rivermax call mean and

which layer caused it?"** — worked example:

*"DOCA_ERROR_NOT_SUPPORTED from doca_rmax_init()"*.

Answered by the Rivermax overlay on the

cross-library taxonomy in

CAPABILITIES.md ## Error taxonomy

+ the layered ladder in

TASKS.md ## debug that escalates to

doca-debug, and which preserves

the installed header's call-specific mapping: init-time

_NOT_SUPPORTED routes first to Rivermax SDK / license checks;

later errors are interpreted from the exact failing call rather

than generalized into a license diagnosis.

Audience

This skill serves **external developers building applications

that consume the DOCA Rivermax integration** — i.e., users whose

code calls doca_rmax_* (directly in C/C++, or through

FFI/bindings from another language) to drive timing-precise

media-over-IP streams (SMPTE ST 2110, real-time market data,

high-throughput scientific instrument streams) on top of a

separately-installed NVIDIA Rivermax SDK on a BlueField or

ConnectX host. It is *not* for NVIDIA developers contributing to

DOCA Rivermax itself, and it is *not* for users who want

best-effort packet I/O — for that, route to

doca-eth directly.

Language scope. DOCA Rivermax ships as a C library with

pkg-config module name doca-rmax. The shipped samples

live under /opt/mellanox/doca/samples/doca_rmax/ and are

written in C. C and C++ consumers are the canonical case; the

worked examples in TASKS.md assume that path. Other-language

consumers (Rust, Go, Python, …) consume the same *.so through

FFI or language-specific bindings; the skill's contribution in

that case is to keep the precondition rule (Rivermax SDK +

license), per-stream lifecycle, capability-discovery,

permission, scheduling-discipline, and error-taxonomy guidance

language-neutral, and to route the agent to the public C ABI as

the authoritative surface that any wrapper will eventually call.

When to load this skill

Load this skill when the user is doing hands-on DOCA Rivermax

work, in any language. Concretely:

• Confirming that the NVIDIA Rivermax SDK and a valid Rivermax

license are present on the host before any DOCA-side code is

written — this is a mandatory precondition, not an error

path; without it the answer is *"doca-rmax cannot be

used; pick a different library"*, not *"let's try and see what

fails"*.

• Initializing the global DOCA Rivermax engine with

doca_rmax_init() / doca_rmax_release(), then creating a

doca_rmax_in_stream (receive) context with

doca_rmax_in_stream_create() on a doca_dev opened against a

physical port, a representor, or an SF, and converting it via

doca_rmax_in_stream_as_ctx() before doca_ctx_start(). The

public DOCA Rivermax API is receive-only — there is no

transmit/output stream object.

• Configuring a Rivermax input stream for SMPTE ST 2110 audio +

video over IP, real-time market data feeds, or a scientific

instrument stream — with awareness that PTP-clock and

hardware packet-placement-order support are device- and

Rivermax-conditional and gate on the matching

doca_rmax_get_*_supported query.

• Reading or setting Rivermax stream properties via

doca_rmax_in_stream_set_* and querying device + Rivermax

capability via the doca_rmax_get_*_supported family before

assuming PTP-clock or hardware packet-placement-order support.

• Pairing the Rivermax stream with the doca-eth queue surface

that carries the packets and the doca-flow rules that

steer them — Rivermax does not program steering itself.

• Designing the real-time scheduling discipline for the

streaming threads (the underlying Rivermax stack expects

real-time priority for sub-microsecond jitter; the canonical

scheduling guidance lives in the Rivermax SDK docs reachable

through

doca-public-knowledge-map).

• Debugging a DOCA_ERROR_* returned from a Rivermax call

(lifecycle vs. license / permission vs. capability vs.

driver-below) where the cause may live in the DOCA-side

wrapper, the underlying Rivermax stack, or the licensing

layer.

• Designing or extending non-C bindings (Rust, Go, Python, …)

that wrap the DOCA Rivermax C ABI — for the precondition

rule, lifecycle, capability, permission, and scheduling rules

the wrapper must honor.

Do not load this skill for general DOCA orientation, for

installing DOCA itself, for installing the Rivermax SDK or

managing the Rivermax license file (those live in the public

Rivermax SDK guide reachable through

doca-public-knowledge-map),

for best-effort packet I/O without timing requirements (use

doca-eth directly), or for pure

host-side data processing without networking. For DOCA

documentation orientation, use

doca-public-knowledge-map.

What this skill provides

This is a thin loader. The body keeps only the orientation

needed to pick the right next file. The substantive

Rivermax-specific material lives in two companion files:

• CAPABILITIES.md — what DOCA Rivermax can express on this

version *and this Rivermax SDK install*: the

Rivermax-as-hard-dependency rule, the receive-only

doca_rmax_in_stream object model, the capability-query surface

(doca_rmax_get_*_supported), the Rivermax error taxonomy

(mapped onto the cross-library DOCA_ERROR_* set, with

Rivermax-specific causes called out per row), the

observability surface (per-stream progress engine events,

capability snapshots, Rivermax-side license + driver state),

and the safety policy that gates the Rivermax-SDK-present /

license-present / device-access / scheduling-discipline

preconditions.

• TASKS.md — step-by-step workflows for the six in-scope

Rivermax verbs: configure, build, modify, run,

test, debug. Plus a Deferred task verbs block that

points out-of-scope questions (installing Rivermax,

managing the license, programming steering, programming the

underlying queue) at the right next skill, and a `Command

appendix` of the recurring commands the agent reaches for.

The skill assumes a host or BlueField where DOCA is already

installed at the standard location, the NVIDIA Rivermax SDK is

installed at its expected location with a valid license, and

the user has the privileges their public install profile

expects (typically sudo or mlnx-group membership to open a

doca_dev against a port). It does not cover installing DOCA —

that path goes through

doca-setup. It does not cover

installing Rivermax or its license — that path goes through the

public Rivermax SDK guide reachable through

doca-public-knowledge-map.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or templates

bundle. To keep the boundary clean, it deliberately does not

contain — and pull requests should not add:

• **Pre-written DOCA Rivermax application source code, in any

language.** The verified Rivermax source code is the shipped

C samples at /opt/mellanox/doca/samples/doca_rmax/<name>/.

The agent's job is to route the user to those files and

prescribe a minimum-diff modification on them via the

universal modify-a-sample workflow in

doca-programming-guide,

layered with the Rivermax-specific overrides in

TASKS.md ## modify.

• Standalone build manifests (meson.build,

CMakeLists.txt, Cargo.toml, …) parked inside the skill.

The agent constructs the build manifest *in the user's

project directory* against the user's installed DOCA, where

pkg-config --modversion doca-rmax is the source of

truth.

• **Quoted Rivermax symbol names beyond the public family

pattern (doca_rmax_get_*_supported for capability discovery,

receive-only doca_rmax_in_stream session objects driven by the

standard DOCA Core context lifecycle).** Exact Rivermax

symbol names are install-bound and Rivermax-SDK-version-

bound; the agent should read them from the installed headers

at $(pkg-config --variable=includedir doca-common) and from the

public DOCA Rivermax guide rather than rely on agent memory.

• A samples/, bindings/, or reference/ subtree of

any kind. A mock or incomplete artifact in this skill's

tree, even one labeled *"reference"*, is misleading: users

will read it as buildable.

Loading order

• Read this SKILL.md first to confirm the user's question is

in scope and that the Rivermax-SDK + license

precondition has been considered.

• **For the Rivermax capability matrix, the receive-only input

stream model, capability-query rules, error taxonomy,

observability, and safety policy, see

CAPABILITIES.md.**

• **For step-by-step workflows — configure, build, modify,

run, test, debug — see TASKS.md.**

Both companion files cross-link to each other,

doca-version for the canonical

DOCA version-handling rules (Rivermax adds a Rivermax-SDK-

version axis on top),

doca-eth for the queue surface

that carries the packets,

doca-flow for the steering side

that decides which packets land on which queue, and

doca-public-knowledge-map

whenever the right answer is *"look it up in the public

Rivermax SDK guide or the installed package layout"* rather

than *"Rivermax-integration-specific guidance"*.

Related skills

• doca-public-knowledge-map —

the routing table for every public DOCA documentation source

and the on-disk layout of an installed DOCA package. The

Rivermax URL slug is DOCA-Rivermax; the public Rivermax SDK

guide (separate product) is reachable from the same routing

table when the user asks how to install Rivermax or its

license.

• doca-setup — env preparation,

install verification, port-state checks (devlink dev show,

ip link), permission and group-membership requirements for

opening a doca_dev. This skill assumes its preconditions

are satisfied; the Rivermax-SDK + license preconditions are

layered on top.

• doca-version — canonical

DOCA version-handling rules. This skill's `## Version

compatibility` cross-links the four-way match rule and adds

the Rivermax-specific overlay (Rivermax SDK version is a

second axis; the capability set on this host is the

intersection of DOCA-side cap-query results and

Rivermax-side capabilities).

• doca-structured-tools-contract —

the bundle's structured-tools precedence rule (detect /

prefer / fall back / report). The Command appendix in

TASKS.md honors this contract.

• doca-programming-guide —

general DOCA programming patterns shared by every library:

the canonical pkg-config + meson build pattern, the

universal modify-a-shipped-sample first-app workflow, the

universal lifecycle, the cross-library DOCA_ERROR_*

taxonomy, and the program-side debug order. This skill

layers Rivermax specifics on top.

• doca-eth — the queue surface

that carries the packets a Rivermax stream produces or

consumes. DOCA Rivermax does *not* program the underlying

queue itself; it integrates with the queue programmed via

doca-eth. The two skills' lifecycles are independent.

• doca-flow — the steering

surface that decides which packets land on which queue.

DOCA Rivermax does *not* program steering itself; an empty

Rivermax input stream almost always means a missing or wrong

Flow rule (or a missing Rivermax license), not a Rivermax

bug.

• doca-debug — the

cross-cutting debug ladder (install / version / build /

link / runtime / program / driver). Rivermax-specific debug

(license precondition gaps, stream-type / packet-rate

capability mismatches, scheduling-discipline jitter

symptoms) overlays on top of that ladder.