---

license: Apache-2.0 name: doca-flow-grpc-server description: > PLAINTEXT-ONLY: the shipped doca_flow_grpc server uses grpc::InsecureServerCredentials() with NO TLS / mTLS / token-auth knob on the binary — transport security must come from external infrastructure (e.g. an mTLS proxy / sidecar) on a trusted segment. Use this skill when bringing up, configuring, hardening, or debugging doca_flow_grpc — the DOCA-shipped gRPC remote-control surface in front of doca-flow that lets non-C++ clients (Python, Go, Rust, Java) program Flow pipes and entries over RPC instead of linking libdoca_flow.so directly. Trigger even when the user doesn't say 'doca-flow-grpc-server' or 'gRPC' — e.g. 'program Flow rules from Python on another host', 'remotely configure pipes on the BlueField', 'client times out connecting to the Flow server', 'where is the .proto for Flow', 'UNAUTHENTICATED / FAILED_PRECONDITION on a Flow RPC'. Route elsewhere for the underlying doca-flow API, generic gRPC tooling (protoc, language bindings), or DOCA install / BFB bring-up. metadata: kind: tool compatibility: > Requires DOCA on Linux (Ubuntu 22.04/24.04 or RHEL/SLES) with a BlueField DPU or ConnectX NIC. The doca_flow_grpc binary is a build artifact (install: false in tools/flow_grpc_server/meson.build, gated by flag_enable_grpc_support + flag_enable_grpc_flow_library) — NOT installed under a default DOCA path; build it from the DOCA source tree with gRPC enabled. Its .proto lives under libs/doca_flow/grpc/. Confirm Flow via pkg-config doca-flow.

---

DOCA Flow gRPC Server (doca_flow_grpc)

CRITICAL transport-security correction (Run-12 + R13). The shipped doca_flow_grpc / doca_flow_grpc_client binaries hard-code the gRPC plaintext credentials surface: the server uses grpc::InsecureServerCredentials() (the C++ gRPC server-side API in tools/flow_grpc_server/server/); the C++ client uses grpc::InsecureChannelCredentials() (the C++ gRPC client-side API; the client lives in libs/doca_flow/grpc/client/, compiled into the doca_flow library, NOT under tools/flow_grpc_client/); the Python client uses grpc.aio.insecure_channel(...). Do NOT cite the server-side string as grpc::InsecureChannelCredentials() — that is the client-side API name and a Grep-against-source verification will fail. There is no TLS, no mTLS, and no token-auth knob on the shipped control plane today. Any prose below (or in CAPABILITIES.md / TASKS.md) that frames "mTLS / token auth / TLS posture" as a configurable knob on this server is the bundle's previous aspirational framing and is wrong against the shipped source. Treat the server as plaintext-on-a-trusted-segment only: it MUST be bound on a control-plane-only network segment behind an external proxy, sidecar, or VPN that itself enforces TLS + identity. Any "TLS / mTLS / token- auth" discussion below is about the operator's external hardening layer, NOT a knob on this binary. Routing for an TLS / identity design discussion must stay on the selected external proxy, sidecar, or VPN; never route it to a shipped-today binary knob.

Where to start: This is a tool skill for standing up and operating doca_flow_grpc, the DOCA-shipped gRPC remote- control surface for doca-flow. Open TASKS.md and start at ## configure to decide whether a remote control plane is the right answer at all (vs talking to libdoca_flow.so directly), then ## run for the start → bind → one-client-smoke sequence, then ## test for the smoke-before-bulk loop that gates any RPC that mutates Flow / dataplane state. Open CAPABILITIES.md when the question is what the gRPC contract surface looks like (the .proto files shipped under the tool's source tree on the user's install), which external proxy / sidecar / VPN protects the plaintext server, which language bindings the gRPC ecosystem covers, or how to interpret the server's own logs alongside the live Flow application's logs. If DOCA is not installed, route to doca-setup first; if the user has not stood up doca-flow yet, route to doca-flow FIRST — the gRPC server is a remote control plane on top of the Flow library, not a replacement for it.

Example questions this skill answers well

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

• "Do I actually need a remote control plane for my Flow pipeline, or should my client just link libdoca_flow.so directly?" — worked example: "my client is a Python service on a different host; can it program Flow rules remotely?". Answered by the when-to-use-gRPC decision in CAPABILITIES.md ## Capabilities and modes
  • the routing into doca-flow when a direct library link is the better answer.
• "Where is the gRPC contract surface actually defined on my install?" — worked example: "I want to generate a Python client; where do I get the .proto file?". Answered by the the-.proto-file-is-the-source-of-truth rule in CAPABILITIES.md ## Capabilities and modes
  • the language-bindings discussion of standard gRPC tooling (protoc + the language-specific gRPC plugin per the official gRPC docs on grpc.io).
• "How do I harden the gRPC endpoint so it isn't an open door into my dataplane?" — worked example: "the server is bound on 0.0.0.0; what should I do before exposing it?". Answered by the admin attack surface posture in CAPABILITIES.md ## Safety policy
  • the external protection / network-segment decision in TASKS.md ## configure.
• "How do I smoke ONE client end-to-end before opening the server to the fleet?" — worked example: "my Python client can dial the endpoint; what is the first RPC I run to prove it talks to the live Flow application?". Answered by the smoke-before-bulk loop in TASKS.md ## test + CAPABILITIES.md ## Safety policy smoke-before-bulk rule.
• "My client cannot reach the server — is the server down, the wrong endpoint, an external-proxy mismatch, or a version mismatch?" — worked example: "the client times out connecting". Answered by the layered error taxonomy in CAPABILITIES.md ## Error taxonomy
  • the layered ladder in TASKS.md ## debug.
• "Is my non-C++ client (Python / Go / Rust) actually the right shape for the gRPC contract, or is there a cleaner path?" — worked example: "I want a Rust client; what does the .proto-generated API look like?". Answered by the language-bindings discussion in CAPABILITIES.md ## Capabilities and modes
  • the routing through standard gRPC tooling.

Audience

This skill serves external operators, control-plane developers, and AI agents who need to program a running DOCA Flow pipeline from a non-C++ process across a network boundary instead of linking libdoca_flow.so directly into the controlling process. Concretely:

• A control-plane engineer writing a Python / Go / Rust client that programs Flow rules on a BlueField from outside the BlueField's address space.
• A platform operator running a Flow-using service on BlueField who wants to expose a remote-control surface to a centralized control plane.
• An AI agent driving the "can I program these Flow rules from this client / this network position" triage step before recommending a code change to the surrounding doca-flow application.

It is not for users debugging the gRPC server's source code, not a substitute for the live public DOCA Flow gRPC Server guide on docs.nvidia.com, and not the place to learn the doca-flow API — that audience belongs in doca-flow.

doca_flow_grpc is a single CLI binary built from the DOCA source tree (executable('doca_flow_grpc', ..., install: false) in tools/flow_grpc_server/meson.build, gated by flag_enable_grpc_support), plus its companion .proto contract files under libs/doca_flow/grpc/; per the tool's source tree (server/, dpa_device/, packet_buffering/) the tool can also be paired with a packet-buffering / DPA-side helper on configurations that need them. The skill uses the same kind: tool three-file shape (SKILL.md + CAPABILITIES.md + TASKS.md) the rest of the bundle's tool slot uses — front matter at the top of this file already says kind: tool. (Prior bundle revisions said "library three-file shape" here; that wording was internally inconsistent with the front matter and is corrected.)

Language scope

This skill governs deployment, configuration, hardening, and client-side bring-up across the languages standard gRPC tooling covers — Python, Go, C++, Rust, Java, Node.js, C#, Kotlin, Ruby, PHP, Dart — via the language-specific gRPC plugin generated from the shipped .proto files (see the gRPC language support index on grpc.io). The server itself is C++ + DOCA; the client languages are open, gated only by the standard protoc plugin set. For the doca-flow API the server programs, see doca-flow — that surface is C-language.

When to load this skill

Load this skill when the user is — or the agent needs to — bring up doca_flow_grpc against a running doca-flow application (or its preconditions) and connect a non-C++ client to it. Concretely:

• Deciding whether a remote gRPC control plane is the right surface (vs a direct libdoca_flow.so link in the client process).
• Locating the .proto files on the user's install so a language-binding client can generate the appropriate stubs.
• Deciding the deployment's transport-security posture and network segment. NOTE: the shipped server is plaintext-only (grpc::InsecureServerCredentials()); TLS / mTLS / token-auth are NOT binary configuration knobs — they are external infrastructure concerns handled by a capable proxy, sidecar, or VPN, and the plaintext endpoint must stay on a trusted, isolated segment.
• Standing up the server alongside a known-good Flow setup and smoke-testing one client end-to-end before exposing the endpoint to the fleet.
• Diagnosing a connect / version / RPC failure through the layered taxonomy.

Do not load this skill for general DOCA orientation, doca-flow API work, DOCA install, or general gRPC tooling (use the grpc.io docs directly for those).

What this skill provides

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

• CAPABILITIES.md — what doca_flow_grpc exposes: the gRPC remote-control surface in front of doca-flow, the .proto-files-as-authoritative-contract rule (the shipped .proto files under the tool's source on the user's install are the source of truth), the when-to-use- gRPC vs direct-library-link decision, the language- bindings story (any language standard gRPC tooling covers), the external proxy / sidecar / VPN and network-segment decision, the packet-buffering / DPA-side option per the shipped packet_buffering/ and dpa_device/ subtrees, the version overlay (server rides the doca-flow library version it links against), the layered error taxonomy (server-not-started / server-binding-failed / external-layer- rejected / RPC-call-error / Flow-precond