doca-dms

Files (8)

• BENCHMARK.md
• CAPABILITIES.md
• SKILL.md
• SKILLCARD.yaml
• TASKS.md
• evals.json · evals/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# DOCA Management Service (DMS)

## Examples

- **"Read or change a BlueField setting locally."** — use
  `dms-cli` (DOCA 3.5+); explore the path with `--tree` first.
- **"Manage a remote BlueField over gRPC."** — this is in
  scope. Use `dmsd` + `dmspe` with the chosen auth; do not
  drop to ad-hoc SSH for the management plane.
- **"gNOI reboot from orchestrator."** — treat reboot / OS
  install / factory-reset as destructive: require target-bound
  explicit confirmation first.

## Instructions

Follow Loading order below. Open the tasks companion for configure /
gNMI / debug. Open the capabilities companion for auth and gNOI
scope. Do not open every companion file.

> **⚠️ Destructive operations.** The gNOI `reboot`, `OS install`,
> `factory-reset`, and managed-file deletion operations are
> **irreversible** and **service-impacting**
> — they can take a production BlueField or ConnectX offline or wipe its
> configuration. Before issuing any of them the agent MUST: (1) verify the
> target device identity, and (2) obtain explicit confirmation bound to
> that target and action. In an interactive session this is an explicit
> user reply naming/accepting both; in unattended execution it must be an
> approved-system authorization artifact bound to both. Otherwise stop
> with `confirmation_required`. Never invoke them speculatively or as
> a side effect of another task. See the public DMS guide's safety
> guidance for these operations.

**Where to start:** This skill is for *operating* DMS, not for
*linking against* a library. If the user wants to *deploy* or *run*
the daemon, open the tasks companion and start at
`## configure`. If the question is *what shape
of service is DMS and what protocols does it speak*, start at
the capabilities companion. If DOCA is not installed on the
management endpoint yet, route to
`doca-setup/SKILL.md` first.

**How to use this skill.** Read this file, then search the companion file
for the `## <name>` heading the question needs and read that whole section.
Answer completely from it, quoting only its symbols and commands. Do not
browse docs; use the entry points in `doca-public-knowledge-map`. Give
environment checks as commands for the user's DOCA host. For out-of-scope
requests, name the skill that owns them and stop.

**DOCA 3.5 and later: start with `dms-cli`.** The DMS guide now centres on
`/opt/mellanox/doca/services/dms/dms-cli`, run directly on the host or
BlueField Arm with no server or daemon. One syntax per YANG path:
`dms-cli -t pci/<BDF> /nvidia/mode/operating-mode` reads a value, the same
path plus a value sets it, and action paths run operations. Explore before
writing: `--tree /nvidia`, `--describe <path>` and `list-xpaths <path>`;
script with `--json`; validate with `--dry-run`. VFs and SFs take
`-t pci/<BDF>,pf<N>vf<M>` or `pf<N>sf<M>`. Observed on DOCA 3.5: as a normal
user it fails with `backend fork/exec .../dmspe: permission denied` — run it
with `sudo` or add the user to `dmsgroup`; some example paths do not exist on
every device (for example congestion-control slots are under
`/nvidia/cc/algo/slot` there), so confirm every path with `--tree` /
`list-xpaths` before using it. Firmware or BFB installs
(`/nvidia/provisioning/install`), resets and mode changes are
hardware-state changes: follow `doca-hardware-safety`. The `dmsd` + `dmspe`
gRPC (gNMI / gNOI) service below remains for remote and fleet management.

## Example questions this skill answers well

> **Never invent the image tag.** It comes from the NGC catalog's DOCA
> org or the DMS page on `docs.nvidia.com`, not from memory — a
> plausible tag reads as authoritative and mismatches the installed
> DOCA. Cite where it came from, or send the user to look it up.

The CLASSES of DMS 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.

- **"Where should DMS run for my target topology?"** — worked example:
  *"I have a host without a DPU; can I still manage a remote
  ConnectX?"*. Answered by the deployment-shape decision in
  the capabilities companion
  + the tasks companion.
- **"Which authentication mode should I pick for my security
  posture?"** — worked example: *"a multi-tenant production env vs a
  single-tenant lab"*. Answered by the auth-mode trade-off table in
  the capabilities companion
  + the auth-wiring step in
  the tasks companion.
- **"How do I issue a gNMI `Get` / `Set` against a modeled path?"** —
  worked example: *"set `/interfaces/interface/config/mtu` on a remote
  interface"*. Answered by the gNMI/gNOI surface in
  the capabilities companion
  + the request-shape workflow in
  the tasks companion.
- **"How do I run a gNOI operation (reboot, OS install, file
  transfer)?"** — worked example: *"trigger a clean reboot of the
  target via gNOI"*. Answered by the gNOI catalog in
  the capabilities companion
  + the run workflow in the tasks companion.
- **"My DMS request returned an error — was it the frontend or the
  backend?"** — worked example: *"`mlxconfig` failed under DMS but
  works on the shell"*. Answered by the frontend-vs-backend split in
  the capabilities companion
  + the layered ladder in
  the tasks companion.
- **"Where do I read DMS logs and how do I rotate them?"** — worked
  example: *"persistent log directory + journald + log-rotation
  policy"*. Answered by the logging surface in
  the capabilities companion
  + the log-rotation step in
  the tasks companion.

## Audience

This skill serves **external operators and platform teams who deploy and
operate DMS** to manage NVIDIA® BlueField® networking platforms or
NVIDIA® ConnectX® SmartNICs from a centralized control plane. Concretely:
people running `dmsd`, integrating gNMI/gNOI clients against it, choosing
an authentication mode, or wiring DMS into a Kubernetes deployment.

From NVIDIA/skills, Apache-2.0.

More from NVIDIA/skills