---

license: Apache-2.0 name: doca-urom-svc description: > Operate the DOCA UROM Service container on BlueField Arm for remote memory operations (puts, gets, atomics, collectives) enqueued by a paired host using doca-urom: pull the NGC image, choose the UCX component, size queues, configure Comch pairing, and align host and service versions. SECURITY: the service has no standalone access control; Comch pairing and RDMA permissions are the boundary. Pair only intended hosts, expose least-privilege memory regions, and verify both views before start. Trigger for slow UCX collectives, unexpected NOT_PERMITTED, or missing completions. Do not use for host application code, MPI/UCX integration design, or DOCA install. metadata: kind: service compatibility: > BlueField-Arm-only DOCA service container; pulled from NVIDIA NGC and started under the BlueField OS container runtime. Host-side install is irrelevant — the host's relationship to this service is via the paired doca-urom library over a doca-rdma substrate.

DOCA UROM Service

Where to start: This skill is for operating the DOCA UROM Service container on the BlueField Arm side. It is not for linking against a library, and it is not the host-side enqueue surface. If the user wants to deploy or run the service container, open TASKS.md and start at ## configure. If the question is what shape of service is DOCA UROM Service, what does it execute, and how does it pair with the host-side library, start at CAPABILITIES.md. If DOCA is not installed on the BlueField yet, route to doca-setup first. If the user's real question is about writing host-side code that enqueues remote memory operations through the paired API, the right skill is doca-urom — the host-side library; this service is the DPU-side executor that library offloads to.

Example questions this skill answers well

The CLASSES of DOCA UROM Service 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.

• "Is DOCA UROM Service the right thing to deploy on my BlueField, or do I just need the host library?" — worked example: "my MPI cluster's host nodes link against doca-urom; what runs on the BlueField side and why must it also be there?". Answered by the publisher / executor paired-contract model in CAPABILITIES.md ## Capabilities and modes
  • the deploy-this-when path-selection rule in CAPABILITIES.md ## Safety policy
  • the env-prep checklist in TASKS.md ## configure.
• "Which library / service version pair am I supposed to run together?" — worked example: "the host fleet upgraded to a newer doca-urom; do I have to upgrade the service containers on every BlueField, or is the pairing flexible?". Answered by the version-contract overlay in CAPABILITIES.md ## Version compatibility
  • the paired-version step in TASKS.md ## configure + doca-version as the canonical body.
• "What does the service configure — UCX components, collectives, queue depths, how the host pairs over Comch?" — worked example: "my upstream stack wants to offload all-reduce collectives; how do I tell the service to expose that collective family and how does the host pair to it over DOCA Comch?". Answered by the configuration-axes table in CAPABILITIES.md ## Capabilities and modes
  • the config-authoring step in TASKS.md ## configure.
• "Host's doca-urom calls fail with NOT_PERMITTED even though doca_dev access is fine — is this the service?" — worked example: "first enqueue from host returns DOCA_ERROR_NOT_PERMITTED after a clean doca_ctx_start()". Answered by the Comch-pairing / RDMA-permissions layer in CAPABILITIES.md ## Error taxonomy
  • the layered ladder in TASKS.md ## debug, which surfaces "is the DOCA Comch endpoint pair correctly established and is the underlying RDMA permission stack happy" BEFORE blaming a service-side authz layer (no such layer exists in the shipped binary — NOT_PERMITTED here is a Comch / RDMA signal, not a UROM-service authz signal).
• "Operations enqueue but never complete — service or substrate?" — worked example: "host enqueue succeeds, the progress engine never sees the completion, what layer is hung". Answered by the service-vs-substrate split in CAPABILITIES.md ## Error taxonomy
  • the layered ladder in TASKS.md ## debug, which separates service queue full / handler stuck from underlying RDMA transport down before recommending a fix on either side.
• "Performance with offload is worse than the host-CPU baseline — is the service the bottleneck?" — worked example: "we deployed the service, the workload runs, but collectives are slower than when the host CPU posted them itself". Answered by the offload-isn't-free rule in CAPABILITIES.md ## Safety policy
  • the smoke-before-scale step in TASKS.md ## test, which surfaces the workload's pattern may not actually benefit from DPU offload as a legitimate diagnosis, not a service bug.

Audience

This skill serves external operators and platform teams who deploy and operate the DOCA UROM Service container on BlueField to receive and execute the remote memory operations HPC / UCX / MPI workloads on the host enqueue through doca-urom. Concretely: people running the service container on BlueField Arm, choosing which UCX components and collectives it exposes, sizing the enqueue queue depth, wiring the DOCA Comch endpoint pairing between host doca-urom and the service container (the shipped binary has NO standalone service-side "host-endpoint authorization list" — access is governed by Comch pairing + the underlying RDMA permissions), and validating the host-library + DPU-service paired contract end-to-end before scaling a real HPC workload on top.

It is not for NVIDIA developers contributing to the DOCA UROM Service itself, and it is not a programming guide for building applications on top of DOCA libraries (that is doca-programming-guide plus the matching libs/<library> skill). DOCA UROM Service is a service, not a library: the operator deploys a container on the BlueField and configures it via the documented config surface; they do not link lib<uromservice>.so to write their own program. The paired host-side library doca-urom is a separate skill with its own scope and its own audience (HPC application developers, not service operators); the agent must refuse to collapse the library and the service into one another.

Path selection up front. Deploy this service when the HPC cluster's host nodes use the doca-urom library and want host CPU freed for compute by offloading collective communication to the BlueField, when the team is building a custom HPC stack on top of doca-urom, or when an upstream MPI / UCX stack has been wired to use UROM as a transport. Do not deploy this service when the hosts are not using doca-urom, when the HPC stack is neither MPI nor UCX (this service won't help — it executes UROM-shaped offloads, not arbitrary networking), or when the BlueField hardware is too constrained for the intended offload (a cap-query at deploy time surfaces this upfront, not after the service is running). Deploying the service speculatively into an environment whose host workloads will not actually offload through doca-urom adds operational complexity without any agent-visible benefit.

When to load this skill

Load this skill when the user is doing hands-on DOCA UROM Service deployment work on a BlueField where DOCA is already installed. Concretely:

• Deciding whether DOCA UROM Service is the right answer for the user's HPC environment (vs. keeping the host CPU on the communication path with raw doca-rdma or with no DPU offload at all).
• Deploying the service container on BlueField Arm — pulling the image per the public DOCA UROM Service Guide, setting the daemon's CLI flags / env (SERVICE_ARGS, UROM_PLUGIN_PATH) and mounting the plugins/ directory, starting / stopping the container under the BlueField container runtime per the public Container Deployment Guide.
• Choosing the service's configuration axes — which UCX components / collectives the service exposes (cap-bound to what the BlueField generation supports), enqueue queue depths for the offload path, and how the host's doca-urom library pairs to the service over DOCA Comch (access is governed by that Comch pairing + the underlying RDMA permissions — there is no service-side authorization list). Pair only explicitly intended hosts and keep RDMA exports and permissions to the minimum the workload requires; pre-start verification through the documented Comch and RDMA read-only surfaces is mandatory.
• Confirming the host-library + DPU-service version pair is one the DOCA Compatibility Policy supports — a mismatch is the canonical subtle-failure mode for the paired contract.
• Reading the service container's logs, the service's observability surface, and the underlying RDMA substrate counters to confirm the service is actually executing the operations the host enqueued.
• Debugging a deployment where the container is healthy but the host's doca-urom enqueues fail or never complete, or where the offload's performance is worse than the host-CPU baseline.

Do not load this skill for general DOCA orientation, install of DOCA itself, host-side doca-urom library API questions, or non-UROM HPC stack topics. For those, route via doca-public-knowledge-map, doca-setup, or the matching host-side library skill doca-urom.

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

• CAPABILITIES.md — the service's architecture (long-running container on BlueField Arm that executes UROM offloads from paired hosts), the publisher / executor paired-contract model and its load-bearing version-coupling rule, the configuration axes (UCX-component / collective surface, enqueue queue sizing, DOCA Comch endpoint pairing), the deployment shape (container on BlueField Arm per the public Container Deployment Guide), the pairing surface (host doca-urom library + underlying doca-rdma transport substrate), the observability surface (container state + service logs + RDMA counters), the error taxonomy (container-runtime vs service-side-resource vs transport-substrate vs paired-version-mismatch), and the safety policy (path-selection rule, version-contract rule, smoke-before-scale).
• TASKS.md — step-by-step workflows for the in-scope service verbs: configure, build, modify, run, test, debug, plus a Deferred task verbs block routing out-of-scope questions and a Command appendix of recurring commands.

The skill assumes a BlueField where DOCA is already installed and the operator has the privileges the public DOCA UROM Service Guide expects to pull, run, and configure containers on BlueField Arm. It does not cover installing DOCA — that path goes through doca-setup. It does not cover the host-si