Generated banner for Doca Ngauge
Generated logo for Doca Ngauge

Doca Ngauge

NVIDIAOfficialCreated by NVIDIA

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk

From the author

Use this skill when the operator is driving the DOCA ngauge tool to analyze, visualize, and debug network performance on a single node by probing NIC hardware counters and storing collected data in HDF5 format. Trigger even when the user does not say "DOCA ngauge" — implicit phrasings include "probe NIC hardware counters", "collect HDF5 performance data", "plot ngauge output", "sample counters on BlueField/ConnectX", "measure network performance on a single node", "debug network performance with hardware counters", "run ngauge YAML config", "parse ngauge HDF5 output". Refuse and route elsewhere: DOCA install/bring-up to doca-setup, version questions to doca-version, hardware/firmware state changes to doca-hardware-safety, raw packet I/O to doca-eth, and host-DPU messaging to doca-comch.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The doca-ngauge skill provides guidance for using the DOCA ngauge tool to probe NIC hardware counters on supported NVIDIA devices, including BlueField-3 and ConnectX-7. It enables users to collect performance data in HDF5 format, visualize metrics, and debug network performance on a single node. The skill covers YAML-based configuration, execution workflows, and the interpretation of counter data, while maintaining strict boundaries against hardware state changes or raw packet I/O operations.

What it does

  • Probes NIC hardware counters for network performance analysis.
  • Stores collected performance telemetry in HDF5 format.
  • Supports YAML-based configuration for sampling parameters and counter selection.
  • Provides methods for visualizing and parsing collected HDF5 data.
  • Interprets CLI progress indicators and counter summary statistics.
  • Diagnoses common runtime issues such as fwctl driver conflicts.

When to use it

  • When you need to measure network performance on a single node using hardware counters.
  • When configuring sampling periods and counter IDs via YAML files.
  • When you need to plot or analyze previously collected ngauge HDF5 output.
  • When troubleshooting performance issues that require deep NIC hardware telemetry.
  • When resolving conflicts involving the fwctl driver.

Advantages

  • Enables granular network performance monitoring via hardware-level probes.
  • Standardizes data collection using the HDF5 format for consistent analysis.
  • Provides a structured approach to debugging performance bottlenecks.
  • Integrates with existing DOCA toolsets for streamlined operations.

Usage examples

“Probe NIC hardware counters on a BlueField-3 and save HDF5 data.”
The agent will guide you through creating a YAML configuration file with the appropriate device address and counter IDs, then show you how to execute the ngauge command.
“Plot the collected counter data from an ngauge output file.”
The agent will direct you to use the sample plugins provided in the ngauge installation to parse and visualize your HDF5 data.
“ngauge cannot start because fwctl is in use.”
The agent will help identify conflicting services using the fwctl driver and advise on how to resolve the dependency.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/doca-ngauge/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip doca-ngauge.zip -d .agents/skills

Documentation by NVIDIA

DOCA ngauge

Scope boundaries

These requests are out of scope: say so, name the skill that owns the request, and stop.

  • raw Ethernet packet send/receive at line rate: doca-eth/SKILL.md.

  • host-DPU control-plane messaging (Comch): doca-comch/SKILL.md.

  • DOCA install and bring-up: doca-setup/SKILL.md.

  • which DOCA version is installed, version compatibility: doca-version/SKILL.md.

  • NIC or BlueField mode and firmware changes: doca-hardware-safety/SKILL.md.

  • general DOCA orientation and documentation lookup: doca-public-knowledge-map/SKILL.md.

Examples

  • "Probe NIC hardware counters on a BlueField-3 and save HDF5 data." — this is in scope. Configure the YAML file and run ngauge; do not attempt to change hardware or firmware state here.

  • "Plot the collected counter data from an ngauge output file." — use the sample plugins under /usr/share/doc/ngauge/examples/plugins; dependencies may need separate installation.

  • "ngauge cannot start because fwctl is in use." — check for other tools or services that also use fwctl; route install and driver conflict resolution to doca-setup.

Quick facts

The authoritative source for the binary name, flags, paths, and configuration schema is the public DOCA ngauge guide at https://docs.nvidia.com/doca/archive/3-5-0/doca-ngauge/index.html. Confirm details with the installed tool's --help and the sample configuration files before quoting them.

  • ngauge analyzes, visualizes, and debugs network performance on a single node by probing NIC hardware counters and storing collected data in HDF5 format with relevant metadata.

  • Supported hardware: NVIDIA BlueField-3, NVIDIA ConnectX-7, and above; firmware version xx.43.1000 or higher.

  • ngauge relies on the fwctl driver and cannot run simultaneously with other tools or services that also use fwctl.

  • All configurations are defined in an input YAML file. Sample configuration files are under /usr/share/doc/ngauge/examples/settings.

  • The device is specified by its PCIe address, for example device: "0000:03:00.0".

  • Output path and file prefix are mandatory. The output file is saved as /path/to/output/directory/<prefix>_<DATE>_<TIME>.h5; the exact file name is printed after each run.

  • The silent option suppresses CLI progress indications when set to true (default false).

  • Runtime parameters include mode (repetitive or single) and period_us (sampling period in microseconds; decimal or scientific notation accepted, e.g. 1e2 = 100 μs).

  • Counter definitions require id (data ID); optional fields are desc, unit, accumulating, normalizer (time, a non-zero number, or a configured data ID with an id/ prefix), cutoff_min, and cutoff_max.

  • All supported performance counters are listed in the public guide's "Supported Data IDs" section.

  • Run ngauge with:

    ngauge <configuration YAML file>
  • To end a run early, use Ctrl+C (SIGINT). This is a normal and supported way to stop; all results collected up to that point are saved as usual.

  • During a run, progress bars for each counter are displayed. Color coding: blue for low values, red for high values, gradient for intermediate values, solid gray for no changes. Data is updated once per second, showing mean, standard deviation (σ), minimum, and maximum observed during the last second.

  • To reference the most recent results when the output directory is /tmp (the default), use:

    $(ls -1 /tmp/ngauge_data_*.h5 | tail -n1)

Instructions

Follow Loading order below. Open the tasks companion for configure / run / parse / debug. Open the capabilities companion for what ngauge measures and reports. Do not open every companion file.

Where to start: This is a tool skill for invoking DOCA ngauge — the single-node network performance analysis, visualization, and debugging tool that probes NIC hardware counters and stores HDF5 data. Open the tasks companion and start at ## configure for the YAML configuration decision, then ## run for the execution flow. Open the capabilities companion when the question is what counters can be measured, what metadata is stored, and what the progress display implies. If the user has not installed ngauge or fwctl, route to doca-setup/SKILL.md first. If the user is asking about hardware/firmware state changes, route to doca-hardware-safety/SKILL.md. If the user is asking about version compatibility, route to doca-version/SKILL.md.

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.

Example questions this skill answers well

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

  • "How do I configure ngauge to sample specific NIC hardware counters?" — worked example: "I need to measure RX bytes port 0 and TX bytes port 0 on a BlueField-3 at a 100 μs period, save to /tmp with prefix ngauge_data_." Answered by the YAML configuration model in the capabilities companion + the tasks companion step 2.

  • "How do I run ngauge and stop it early without losing data?" — worked example: "I started ngauge with a YAML config, want to stop after 10 seconds and still get HDF5 output." Answered by the execution flow and Ctrl+C behavior in the tasks companion.

  • "How do I plot the collected HDF5 data?" — worked example: "I have /tmp/ngauge_data_2026-09-01_12-00-00.h5 and want to plot counter 0x1020000100000000." Answered by the parse/plot workflow in the tasks companion using simple_plot.py or simple_text_plot.py.

  • "What do the progress bar colors mean?" — worked example: "During a run, some bars are red, some blue, some gray; what does that indicate?" Answered by the progress display semantics in the capabilities companion.

  • "Why can't ngauge run alongside another tool?" — worked example: "ngauge fails to start because fwctl is in use by another service." Answered by the fwctl dependency and conflict section in the capabilities companion + route to doca-setup.

  • "What hardware and firmware are required?" — worked example: "Will ngauge work on ConnectX-6 or BlueField-2?" Answered by the prerequisites in the capabilities companion.

When to load this skill

Load this skill when the user is — or the agent needs to — drive DOCA ngauge on a real host or BlueField Arm with ngauge installed. Concretely:

  • Probing NIC hardware counters on BlueField-3 or ConnectX-7 and above.

  • Configuring the ngauge YAML file (device, output, params, counters).

  • Running ngauge and interpreting the CLI progress bars and summary.

  • Parsing or plotting the HDF5 output with the sample plugins.

  • Diagnosing fwctl driver conflicts or missing prerequisites.

  • Cross-checking counter data against expected network performance.

Do not load this skill for general DOCA orientation, raw packet I/O, the comch control plane, DOCA install, version questions, or hardware/firmware state changes. For those, route to doca-public-knowledge-map/SKILL.md, doca-eth/SKILL.md, doca-comch/SKILL.md, doca-setup/SKILL.md, doca-version/SKILL.md, or doca-hardware-safety/SKILL.md.

What this skill provides

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

  • the capabilities companion — what ngauge measures and reports: supported hardware and firmware, the fwctl dependency and conflict, the YAML configuration model (device, output, params, counters), counter field semantics (id, desc, unit, accumulating, normalizer, cutoff_min, cutoff_max), HDF5 output format, progress display semantics, sample plugins, and the safety posture that ngauge itself is read-only probing while any step that changes hardware or firmware state routes to doca-hardware-safety.

  • the tasks companion — step-by-step workflows for the in-scope task verbs: configure (YAML setup), run (execution and Ctrl+C), parse / plot (simple_plot.py and simple_text_plot.py), debug (fwctl conflict, missing dependencies), plus a Command appendix that honors the bundle's doca-structured-tools-contract/SKILL.md preamble.

The skill assumes a host or BlueField where ngauge and fwctl are already installed and the operator has whatever privileges the public DOCA ngauge guide requires for the chosen device.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or scripts bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

  • Verbatim counter ID inventories, flag lists, or output column names. The public DOCA ngauge guide on docs.nvidia.com and the installed --help on the user's version are the joint source of truth; copying them here pins the skill to one release and silently rots when ngauge evolves. The skill routes the agent at those sources instead.

  • Pre-baked example output. Output is install-, version-, and device-specific. A captured example will mislead an operator on a different platform or state.

  • Wrappers, parsers, or scripts in any language that consume ngauge output. The output format is documented; users who want to script against it should read the live guide and write the parser against their installed version.

  • A samples/ or reference/ subtree. This is a thin loader for a documented DOCA artifact; substantive material lives on the public page and in --help.

Loading order

  1. Read this skill first to confirm the user's question is in scope (the user wants to probe NIC hardware counters, collect HDF5 data, or plot ngauge output, not learn the eth / comch / RDMA APIs).

  2. For what ngauge measures, the YAML configuration model, the read-only vs state-changing split, version availability, the fwctl conflict surface, observability, and safety posture, see the capabilities companion.

  3. For the documented invocations and the configure → run → parse/plot workflow — configure, run, parse, debug, plus the Command appendix — see the tasks companion.

  • doca-setup/SKILL.md — env preparation, install verification, fwctl driver installation and conflict resolution, and the I have no install yet path. This skill assumes its preconditions are satisfied.

  • doca-version/SKILL.md — canonical DOCA version-handling rules. The ## Version compatibility section in the capabilities companion is a concise overlay that redirects here for the body.

  • doca-hardware-safety/SKILL.md — any step that changes hardware or firmware state routes here. ngauge itself is read-only probing, but if a workflow includes firmware updates or device state changes, use this skill.

  • doca-public-knowledge-map/SKILL.md — routing to the public DOCA ngauge guide and the rest of the public DOCA documentation set. The canonical URL is reached via doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools).

  • doca-structured-tools-contract/SKILL.md — the bundle's detect → prefer → fall back → report contract for structured helper tools. The Command appendix in the tasks companion honors this contract.

  • doca-debug/SKILL.md — the cross-cutting debug ladder. ngauge slots in at the runtime layer as a single-node telemetry tool whose fwctl conflict surface escalates to the cross-cutting ladder when the cause is below DOCA.

  • doca-eth/SKILL.md — the line-rate raw packet I/O surface. ngauge is for hardware counter telemetry, not packet I/O; use doca-eth when the application needs to operate on packets directly.

  • doca-comch/SKILL.md — the host ↔ DPU control-plane primitive. ngauge is single-node performance telemetry, not a control-plane channel; pair them only when coordinating a measurement across host and DPU.

Files

TASKS.md

DOCA ngauge — Tasks

Where to start: The verbs that carry real workflow content are ## configure, ## run, ## test, and ## debug. The other two substantive verbs (build, modify) carry routing stubs because ngauge is a shipped package / pre-installed binary, not a source artifact the external operator compiles or patches — the thing the agent modifies is the input YAML configuration and the invocation, not the tool itself. The ## test verb is an iterative loop (configure → run → verify HDF5 → plot → admit), not a one-shot pass — see the eval-loop overlay in ## test below.

This file is loaded by SKILL.md after CAPABILITIES.md. It walks the agent through the six task verbs every artifact in this bundle exposes (configure / build / modify / run / test / debug), then explicitly defers task verbs that do not belong here, and ends with the Command appendix honoring the bundle's doca-structured-tools-contract/SKILL.md preamble.

For ngauge, the verbs that carry real workflow content are configure, run, test, and debug. The other two verbs exist as anchors because the agent's task-verb contract is uniform across libraries, services, and tools — and each one carries a meaningful routing stub that names where the user's question really belongs.

configure

The ngauge configuration is the four-axis decision documented in CAPABILITIES.md ## Capabilities and modes — device PCIe address × output path and prefix × runtime parameters × counter list — layered on top of the precondition that ngauge and the fwctl driver are installed on the side the operator is about to invoke the tool from. ngauge does not carry a separate config file or daemon contract of its own beyond the input YAML file; the sample configuration files under /usr/share/doc/ngauge/examples/settings are the starting point.

Steps the agent should walk the user through, in order:

  1. Confirm the prerequisites. The target device must be a BlueField-3 or ConnectX-7 or above with firmware version xx.43.1000 or higher. The fwctl driver must be installed on the host; on Linux kernel 6.15 and above it is available by default unless explicitly disabled during kernel configuration. If fwctl is missing or ngauge is not installed, route to doca-setup ## install (doca-setup/TASKS.md#configure) before continuing.

  2. Copy a sample configuration file. Sample files are under /usr/share/doc/ngauge/examples/settings. Use the one that best fits the scenario (single/dual port, etc.). The agent should not invent a YAML file from scratch when a sample exists.

  3. Specify the device. Set the PCIe address of the device to run on, for example device: "0000:03:00.0". The address must be the operator's actual device, not a placeholder.

  4. Configure the output path and file prefix. Both are mandatory. The output file is saved in the format /path/to/output/directory/<prefix>_<DATE>_<TIME>.h5; the exact file name is printed after each run. The silent option suppresses CLI progress indications when set to true (default false).

  5. Configure runtime parameters. Set mode to repetitive or single, and set period_us to the sampling period in microseconds. Decimal or scientific notation is accepted; for example, 1e2 means 100 μs.

  6. Define the counters to measure. Each counter entry requires an id (data ID). Optional fields are desc, unit, accumulating, normalizer, cutoff_min, and cutoff_max. The normalizer, if present, must be either time, a non-zero number, or one of the configured Data IDs with an id/ prefix. All supported performance counters are listed in the public guide's "Supported Data IDs" section; the agent must confirm the chosen IDs against that list before committing.

  7. Validate the YAML against the sample and the public guide. The agent should not quote counter IDs, flags, or paths from memory; confirm them with the installed tool's help and the sample configuration files before the run.

build

No build workflow. ngauge is installed as a package (sudo apt-get install ngauge or sudo dnf install ngauge on x86 or Arm 64 hosts; pre-installed on the DPU). The public guide does not document building ngauge from source. If the user asks to build ngauge from source, route to doca-setup/SKILL.md for install verification and to the public guide for any source-build instructions that may exist there; do not invent build steps.

modify

No modify workflow for the tool binary. The thing the agent modifies is the input YAML configuration file and the invocation, not the installed ngauge binary. If the user asks to patch, recompile, or otherwise modify ngauge itself, route to doca-setup/SKILL.md and the public guide; do not recommend editing the installed package.

run

The run verb is the execution flow: invoke ngauge with a prepared YAML configuration, observe the progress display, stop when appropriate, and then parse or plot the resulting HDF5 output.

  1. Run ngauge. Execute:

    ngauge <configuration YAML file>

    The output is saved as an HDF5 file (.h5) in the path specified in the configuration YAML. The exact file name is printed after each run.

  2. Observe the progress display. During the run, progress bars for each counter are displayed. Color coding indicates value levels relative to other values of the same counter: blue for low values, red for high values, intermediate gradient colors for values between low and high, and solid gray bars for counters whose values did not change during the run. Data is updated once per second, showing the mean, standard deviation (σ), minimum, and maximum values observed during the last second.

  3. End the run. To end a run before the full dataset is collected, use Ctrl+C (SIGINT). This is a normal and supported way to end the run, and all results collected up to that point are saved as usual. The agent must not treat an early stop as a failure.

  4. Parse or plot the output. A sample plugin named simple-plot is installed under /usr/share/doc/ngauge/examples/plugins. To plot the data from an ngauge output file, use:

    /usr/share/doc/ngauge/examples/plugins/simple_plot.py <ngauge output .h5 file> <counter ID> [<counter ID> ...]

    Use the -h flag to view additional options, including plotting on a logarithmic scale and in the frequency domain. An alternative plugin, simple_text_plot.py, generates text-based plots directly in the terminal; its resolution is significantly lower, but it supports zooming into specific regions and is useful when graphical output is unavailable or network connectivity to the server is limited. The usage syntax is similar:

    /usr/share/doc/ngauge/examples/plugins/simple_text_plot.py <ngauge output .h5 file> <counter ID> [<counter ID> ...]

    Use the -h flag to view additional options, such as plotting in the frequency domain, specifying the start, end, or duration of the plotted interval, and more. The sample plugins are provided as examples and are not integral parts of the ngauge tool. Dependencies such as NumPy, H5py, Matplotlib, plotext, and others may need to be installed separately to run these plugins.

  5. Reference the most recent results. If the output directory is /tmp (the default), the most recent results can be referenced without manually copying the file name by using the expression shown below:

    $(ls -1 /tmp/ngauge_data_*.h5 | tail -n1)

test

The test verb is an iterative loop, not a one-shot pass. The agent should walk the user through a minimal smoke test before admitting a full measurement run:

  1. Configure a minimal YAML. Use one counter, a short period_us, and a known output path and prefix. Confirm the device PCIe address and prerequisites.

  2. Run ngauge. Execute the command from ## run and let it run briefly, then stop with Ctrl+C (SIGINT). Confirm that the exact output file name is printed and that the .h5 file exists in the configured output path.

  3. Verify the output. Plot the collected data with simple_text_plot.py (or simple_plot.py if graphical output is available) using the counter ID from the YAML. Confirm the plot renders and the counter values are visible.

  4. Admit the full run. Only after the smoke test passes should the agent admit the full measurement configuration. If any step fails, route to ## debug before retrying.

Because ngauge is read-only probing, the test loop does not change hardware or firmware state. Any step that would change hardware or firmware state routes through doca-hardware-safety/SKILL.md before execution.

debug

Map the symptom to the right layer before any state-changing intervention. The error taxonomy in CAPABILITIES.md ## Error taxonomy is the starting point.

  1. fwctl conflict. If ngauge cannot start because fwctl is in use, check for other tools or services that also use fwctl. ngauge cannot run simultaneously with other fwctl users. Route driver conflict resolution to doca-setup/SKILL.md.

  2. Missing fwctl driver. If fwctl is missing, install it via the OS package manager. On hosts running Linux kernel 6.15 and above, fwctl is available by default unless explicitly disabled during kernel configuration. Route install steps to doca-setup/SKILL.md.

  3. Unsupported hardware or firmware. Confirm the device is a BlueField-3 or ConnectX-7 or above and the firmware version is xx.43.1000 or higher. If not, route version and hardware questions to doca-version/SKILL.md.

  4. Configuration errors. Both output path and file prefix are mandatory. Counter id is mandatory. The normalizer, if present, must be time, a non-zero number, or a configured Data ID with an id/ prefix. Validate the YAML against the sample files under /usr/share/doc/ngauge/examples/settings.

  5. Plugin failures. If a sample plugin fails to plot, dependencies such as NumPy, H5py, Matplotlib, plotext, and others may need to be installed separately. The sample plugins are examples and are not integral parts of ngauge.

  6. Early stop. Ending a run with Ctrl+C (SIGINT) is normal and supported; all results collected up to that point are saved as usual. Do not treat an early stop as a failure.

Deferred task verbs

The following task verbs are deferred to other skills and must not be answered from this skill:

  • install — ngauge and fwctl installation, package manager commands, and driver conflict resolution route to doca-setup/SKILL.md.

  • version — DOCA version compatibility, firmware version checks, and version-specific behavior route to doca-version/SKILL.md.

  • hardware/firmware state changes — any step that changes hardware or firmware state routes to doca-hardware-safety/SKILL.md.

  • packet I/O — raw packet processing, line-rate I/O, and the eth API route to doca-eth/SKILL.md.

  • control plane — host ↔ DPU control-plane primitives route to doca-comch/SKILL.md.

  • general DOCA orientation — routing to the public documentation set and the knowledge map routes to doca-public-knowledge-map/SKILL.md.

  • cross-cutting debug — when the cause is below DOCA or spans multiple components, route to doca-debug/SKILL.md.

Command appendix

This appendix honors the bundle's doca-structured-tools-contract/SKILL.md preamble: detect the installed tool with its help before quoting flags, prefer the installed version's help over this appendix, fall back to the public guide, and report any discrepancy.

Detect the installed tool

ngauge --help

Install fwctl (Deb-based)

apt-cache search fwctl
sudo apt install <package-name>

Install fwctl (RPM-based)

dnf search fwctl
sudo dnf install <package-name>

Install ngauge

sudo apt-get install ngauge

or

sudo dnf install ngauge

Run ngauge

ngauge <configuration YAML file>

Plot output (graphical)

/usr/share/doc/ngauge/examples/plugins/simple_plot.py <ngauge output .h5 file> <counter ID> [<counter ID> ...]

Plot output (text)

/usr/share/doc/ngauge/examples/plugins/simple_text_plot.py <ngauge output .h5 file> <counter ID> [<counter ID> ...]

Reference the most recent results in /tmp

$(ls -1 /tmp/ngauge_data_*.h5 | tail -n1)

Cross-cutting

  • Safety gate. ngauge is read-only probing. Any step that changes hardware or firmware state routes through doca-hardware-safety/SKILL.md before execution.

  • Version gate. Version questions, firmware version checks, and version-specific behavior route to doca-version/SKILL.md. The ## Version compatibility section in CAPABILITIES.md is a concise overlay that redirects there for the body.

  • Install gate. ngauge and fwctl installation, package manager commands, and driver conflict resolution route to doca-setup/SKILL.md. This skill assumes the preconditions are satisfied.

  • Debug ladder. ngauge slots in at the runtime layer as a single-node telemetry tool. When the cause is below DOCA or spans multiple components, escalate to doca-debug/SKILL.md.

  • Public-source pointer. The authoritative source for binary names, flags, paths, and the configuration schema is the public DOCA ngauge guide at https://docs.nvidia.com/doca/archive/3-5-0/doca-ngauge/index.html. Confirm details with the installed tool's help and the sample configuration files before quoting them.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

The author says: Requires a host with ngauge installed (sudo apt-get install ngauge or sudo dnf install ngauge on x86 or Arm 64 hosts; pre-installed on the DPU) and a BlueField-3 or ConnectX-7 or above device with firmware version xx.43.1000 or higher. The fwctl driver must be installed on the host; on Linux kernel 6.15 and above it is available by default unless explicitly disabled during kernel configuration. ngauge cannot run simultaneously with other tools or services that also use fwctl.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/doca-ngauge · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download doca-ngauge.zip