doca-flow-dpa-provider

Export DOCA Flow pipes and external resources into BlueField DPA address space for inline kernel access.

3.2k|370|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/NVIDIA/skills --skill doca-flow-dpa-provider
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doca-flow-dpa-provider
Source: https://github.com/NVIDIA/skills/tree/main/skills/doca-flow-dpa-provider
Command: npx skills add https://github.com/NVIDIA/skills --skill doca-flow-dpa-provider

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Developers bridging DOCA Flow and BlueField DPA often hit silent failures: exported pipes with no visible entries, BAD_STATE errors from misordered export calls, or DPA-side reads that never return values. This Skill teaches agents the correct three-program model, queue allocation, and order-sensitive export handshake so DPA kernels can read counters and mutate Flow entries inline without host round-trips.

Core Features & Use Cases

  • Export lifecycle guidance: Walks the exact ordering of doca_flow_dpa_pipe_export_prepare, entry adds, export, and device-address retrieval, plus the parallel external-resource export handshake.
  • Queue and error taxonomy: Explains the three queue types (general, resources-write, resources-read), the two-phase read-then-poll contract, and maps every DOCA_ERROR_* to a provider-specific root cause.
  • Use Case: A user reports their DPA kernel never sees entries in an exported pipe; the agent identifies that export_prepare was called after entries were added and walks the corrected configure sequence.

Quick Start

Ask your agent to export an existing DOCA Flow pipe to the DPA so a DPACC-built kernel can disable hash entries inline, and have it verify the queue configuration first.

Frequently Asked Questions about doca-flow-dpa-provider

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I export a DOCA Flow pipe to a DPA kernel?

Call doca_flow_dpa_pipe_export_prepare before adding any entries, then add entries via doca-flow, call doca_flow_dpa_pipe_export, and finally doca_flow_dpa_pipe_get_device_addr. The resulting device address is passed to the DPA kernel as a launch argument.

Why does my DPA kernel never see entries in the exported pipe?

The most common cause is calling doca_flow_dpa_pipe_export_prepare after entries were added to the pipe. Per the installed header, entries added before prepare are not exported, so the DPA side silently sees an empty pipe.

What causes DOCA_ERROR_BAD_STATE from doca_flow_dpa_pipe_export?

BAD_STATE indicates a lifecycle violation: queues were not created before export_prepare, the prepare step failed, or the pipe was already exported. Walk the export lifecycle ordering rather than retrying the same call.

Why does a DPA-side memory read return no value?

The read API is two-phase: doca_flow_external_resource_memory_read issues the request, but the value is populated only after polling the RESOURCES_READ completion queue. Also confirm the queue config included the RESOURCES_READ type.

Can I use doca-flow-dpa-provider on a ConnectX-only host?

No. The library requires a BlueField DPU exposing a DPA processor visible to the host, plus DOCA SDK and a DPACC compiler version matched per the DOCA Compatibility Policy. ConnectX-only hosts cannot use it.

When should I use doca-flow or doca-dpa instead of this library?

Use doca-flow for pure host-side Flow pipe programming and doca-dpa for generic DPA compute unrelated to Flow. This library is only the niche bridge when an existing Flow pipe must be reachable from a DPA kernel inline.