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.