DOCA Rivermax Receive Development
Guides developers through building, validating, and debugging DOCA Rivermax receive applications for real-time network streams.
The documentation explicitly gates work on the Rivermax SDK, license, device access, port state, queue, and steering, and routes installation and steering elsewhere. No malware, credential theft, covert exfiltration, or destructive default is evident. However, it involves sudo, real-time scheduling, hardware, and external SDK state without a consistently explicit user-confirmation model, rollback plan, data-flow disclosure, or detailed least-privilege guidance; license error attribution also conflicts across sections, so points are deducted.
The configure, build, run, test, and debug paths are detailed and include preconditions, capability checks, and failure-layer routing. Static review provides no reproducible execution, and the treatment of `DOCA_ERROR_NOT_PERMITTED` versus license failures is inconsistent across files. Several exact API and environment assumptions depend on external documentation, so the score remains below the static ceiling and is further reduced.
Audience, trigger phrases, use cases, and non-fit boundaries are clearly stated, including C/C++ and FFI consumers. However, there is no Chinese-language workflow or localized example; the target environment is narrow and requires BlueField/ConnectX, Linux, DOCA, Rivermax SDK, and a license. Reachability of external NVIDIA documentation or licensing services from mainland China is not evidenced, so points are deducted.
The skill uses layered SKILL.md, CAPABILITIES.md, and TASKS.md files with loading order, related skills, dependencies, examples, and limitations. Author metadata is missing; the SKILL.md license conflicts with the SKILLCARD license; versioning remains TBD; no clear changelog is provided; and the benchmark reports path/repository metadata inconsistencies. These governance and maintenance gaps reduce the score.
The workflows offer directly useful guidance for Rivermax receive streams, capability discovery, queue and steering coordination, and error isolation. However, the skill ships no runnable examples, relies on the local installation and external Rivermax documentation for critical details, and provides no static end-to-end verification of usable output. The score is therefore capped and conservatively reduced.
The files provide API families, commands, evaluation metrics, and some benchmark claims, giving partial auditability. The benchmark dataset is unavailable, results cannot be independently reproduced from the supplied material, and key claims depend on missing official documentation, installed headers, and hardware. Fact-versus-inference separation is incomplete, so only limited credit is justified.
- License error attribution is inconsistent: CAPABILITIES.md separates initialization-time `DOCA_ERROR_NOT_SUPPORTED` from creation-time `DOCA_ERROR_NOT_PERMITTED`, while the safety policy also presents the latter as a typical missing-license symptom. Verify against the installed headers and official documentation before use.
- The benchmark reports a pass, but the evaluation dataset is unavailable, and its paths/repository metadata do not match the assessed path consistently; it cannot substitute for independent reproduction.
- The skill depends on a local NVIDIA SDK, a valid license, specialized hardware, and external documentation. Mainland-China reachability of those dependencies is not established, and no Chinese-language operating guidance is provided.
What does this skill do, and when should you use it?
This skill targets developers using DOCA Rivermax on a BlueField DPU or ConnectX host. It covers configure, build, modify, run, test, and debug workflows for Rivermax input streams, with emphasis on device and SDK capability discovery. DOCA SDK, the separately installed NVIDIA Rivermax SDK, and a valid Rivermax license are required beforehand. Installation of Rivermax, programming the underlying queue, and configuring traffic steering are outside its scope.
It directs the agent to verify the DOCA installation, Rivermax SDK, and license first, and to inspect the local installation through pkg-config doca-rmax. It guides use of doca_rmax_init(), creation of doca_rmax_in_stream, conversion to a context, and the standard DOCA lifecycle; it also covers doca_rmax_get_*_supported capability queries, stream properties, integration with doca-eth queues and doca-flow steering, and layered analysis of DOCA_ERROR_* across lifecycle, license, permission, capability, and driver causes. It routes users to installed headers, DOCA samples, and public documentation rather than shipping application source code.
- A developer checks whether a BlueField or ConnectX host satisfies the DOCA Rivermax receive prerequisites.
- A media engineer designs a doca_rmax_in_stream lifecycle for SMPTE ST 2110 video or audio reception.
- A real-time market-data or scientific-instrument application checks device- and Rivermax-dependent capabilities.
- An engineer investigates a stream that starts successfully but produces no receive events or packets.
- A developer diagnoses DOCA_ERROR_* returned by doca_rmax_init() or another Rivermax call.
- A Rust, Go, or Python developer designs an FFI wrapper that preserves the C ABI lifecycle, capability, and error rules.
What are this skill's strengths and limitations?
- Clearly separates Rivermax integration from queue and traffic-steering responsibilities.
- Treats the Rivermax SDK and license as mandatory prerequisites, improving diagnosis quality.
- Covers receive-stream lifecycle, capability discovery, real-time scheduling, and layered error analysis.
- Provides language-neutral guidance for C ABI consumers, including FFI-based wrappers.
- Covers receive-only doca_rmax_in_stream usage and does not provide transmit or output-stream guidance.
- Ships no ready-to-build application source, standalone build manifests, bindings, or reference subtree.
- Does not replace the Rivermax SDK or license installation guide and does not configure doca-eth queues or doca-flow rules.
- Requires specific NVIDIA hardware, Linux, an installed DOCA SDK, and a separately licensed Rivermax SDK.
How do you install this skill?
Use the skills CLI flow documented in the repository README: npx skills add nvidia/skills --skill doca-rmax --yes. The CLI prompts for an installation destination; client-specific targets can be selected with options such as --agent codex or --agent claude-code. The skill becomes available when the agent encounters a relevant task. The source does not document a skill-specific manual-copy procedure or runtime installer. Separately, the host must already provide the DOCA SDK under /opt/mellanox/doca, the NVIDIA Rivermax SDK, and a valid Rivermax license readable by the user.
How do you use this skill?
After installation, trigger it with a request such as “configure an SMPTE ST 2110 Rivermax receive stream on BlueField” or “diagnose DOCA_ERROR_NOT_SUPPORTED from doca_rmax_init().” For hands-on work, the agent follows the configure, build, modify, run, test, or debug workflow: it verifies DOCA, Rivermax SDK, and licensing first, then consults installed headers, pkg-config data, and the relevant samples. Rivermax or license installation, doca-eth queue programming, and doca-flow steering should be routed to the appropriate skill or public Rivermax documentation.
How does this skill compare with similar options?
Compared with doca-eth, this skill handles Rivermax integration and receive streams, while doca-eth handles the queue surface carrying packets. Compared with doca-flow, it does not program traffic steering rules; real reception commonly requires all three surfaces. Rivermax SDK and license installation belongs to the public Rivermax guide.