DOCA UROM Host-Side Offload Development
Guides HPC, UCX, and MPI developers in offloading remote memory operations to a BlueField DPU.
The documentation clearly separates the host library from the DPU service and requires checking service state, device, versions, plugins, and memory objects. No credential theft, covert exfiltration, or destructive default was found. Points are deducted because it guides hardware, network, and remote-service actions without explicit rollback, least-privilege controls, or external-effect safeguards; license metadata is also inconsistent across the supplied files.
Loading order, prerequisites, lifecycle, error taxonomy, and layered debugging are reasonably consistent, and abnormal cases generally require investigation rather than blind retries. Points are deducted because key paths were not executed in this static review and no committed comprehensive test suite is supplied; several API, plugin, and service behaviors depend on the local installation.
The audience, host-side scope, trigger phrases, non-fit cases, and routing boundaries are unusually explicit, including C/C++ and FFI users. Points are deducted because the skill strictly depends on Linux, an installed DOCA SDK, BlueField hardware, a running DPU service, and a healthy RDMA fabric; Chinese-language interaction and mainland-China reachability are not addressed, and the skill is unusable without the required environment.
The package uses progressive disclosure through SKILL.md, CAPABILITIES.md, and TASKS.md, with workflows, example questions, error tables, and related-skill routing. Points are deducted for incomplete versioning, changelog, authorship, and maintenance details; the benchmark reports missing recommended sections and unavailable evaluation data, while SKILLCARD metadata conflicts with the supplied path, license, and provenance.
The material can help an agent decide when to load the skill and guide host-side UROM configuration, plugin discovery, build, run, test, and debugging. Points are deducted because it intentionally ships no runnable code or templates, depends on local samples, headers, the DPU service, and RDMA infrastructure, and contains no independently confirmable representative output in the static evidence.
The files contain many auditable cross-references, command and API names, error mappings, and an evaluation summary. Points are deducted because the evaluation dataset is unavailable, no independently reproducible test suite or third-party execution evidence is supplied, and important claims depend on external documentation and the user's local DOCA installation.
- This is a low-confidence static review; no commands, tests, or UROM operations were executed.
- Before use, reconcile the path, license, source, and version inconsistencies across SKILL.md, SKILLCARD.yaml, and BENCHMARK.md.
- Do not apply the host-library guidance to DPU-side UROM Service deployment, and do not perform remote operations before confirming service health, version compatibility, plugin discovery, and RDMA health.
- Core API and plugin capabilities depend on the local DOCA headers, samples, and actual service version; the document's summaries do not replace environment validation.
What does this skill do, and when should you use it?
This NVIDIA Agent Skill is for hands-on host-side development with the DOCA UROM library. It covers Service and Worker context lifecycles, remote-operation enqueueing, plugin capability discovery, completion progress, and DOCA_ERROR_* troubleshooting. It requires compatible DOCA installations on the host and BlueField, with the DPU-side UROM Service already running. It does not install DOCA, deploy the DPU service, bring up RDMA, or design MPI/UCX collective algorithms.
It directs the agent to inspect the local library with pkg-config doca-urom and examine libraries, headers, samples, and applications under /opt/mellanox/doca. It guides creation of doca_urom_service_* and doca_urom_worker_* contexts, enqueueing puts, gets, atomics, active messages, and collective primitives, progressing completion events, and calling doca_urom_service_get_plugins_list to discover available plugins. It also structures DOCA_ERROR_* diagnosis across installation, versioning, service reachability, RDMA transport, device capability, and application layers.
- An HPC developer wants to offload MPI or UCX remote-memory communication from host CPU cycles to a BlueField DPU.
- A C or C++ application using doca_urom_* needs to create Service and Worker contexts and verify connectivity to the DPU service.
- A developer needs to determine which UROM plugins, atomics, or collectives are supported by the current device, installation, and service version.
- A UCX or MPI integration already wired to UROM returns DOCA_ERROR_NOT_PERMITTED on its first enqueue.
- A Rust, Go, or Python wrapper around the UROM C ABI must preserve lifecycle, capability-discovery, and error-taxonomy rules.
What are this skill's strengths and limitations?
- Clearly separates the host library from the DPU-side UROM Service, addressing common pairing and version problems.
- Covers a host-side workflow from configuration and build through run, test, and debug.
- Uses plugin discovery as the capability surface for the current device, installation, and service version.
- Applies to C/C++, UCX/MPI integrations, and other languages using the C ABI through FFI.
- Provides no ready-to-compile application source, bindings, build manifests, or samples subtree.
- Depends on an installed and compatible DOCA SDK, BlueField DPU, DPU service, and healthy RDMA transport.
- Excludes DPU-side service operations, DOCA installation, RDMA bring-up, and MPI/UCX collective algorithm design.
- The source provides no independent test results or platform-coverage data for this skill.
How do you install this skill?
Install the skill from the NVIDIA/skills catalog with: npx skills add nvidia/skills --skill doca-urom --yes. The source does not document additional installation procedures; DOCA, the BlueField, the DPU-side UROM Service, and the RDMA environment must be prepared separately.
How do you use this skill?
With the environment prerequisites satisfied, prompt the agent with a host-side task such as: “Help me offload MPI remote-memory operations to BlueField and debug DOCA_ERROR_NOT_PERMITTED from the first doca_urom_* call.” Read SKILL.md first; read CAPABILITIES.md for the capability matrix and TASKS.md for configure, build, modify, run, test, or debug workflows. Do not use this skill for DPU-side UROM Service deployment or MPI/UCX algorithm design.
How does this skill compare with similar options?
For simple point-to-point RDMA where host CPU usage is not the bottleneck, the source recommends using doca-rdma directly. UROM builds a DPU-offload and service-pairing contract on top of the RDMA transport substrate.