DOCA Flow gRPC Remote Control
Deploy, secure, smoke-test, and troubleshoot DOCA Flow’s gRPC control plane for non-C++ clients.
The skill explicitly discloses grpc::InsecureServerCredentials(), the absence of built-in TLS/mTLS/token authentication, and the need for a trusted segment, external controls, and smoke testing before expansion. Deductions apply because the safety text repeatedly requires TLS/auth as if they were server-configurable, conflicting with the stated binary limitation; least-privilege authorization, rollback, and recovery procedures are not concretely specified.
SKILL.md, CAPABILITIES.md, and TASKS.md provide a fairly complete configure, run, smoke-test, and layered-debug workflow using logs, status codes, and installed .proto files. Deductions apply because TLS failure, certificates, and authentication are still described as server-side configuration scenarios, with no committed executable test suite, fixed expected outputs, or abnormal-input reproduction evidence; static review caps this at 10.
The audience, use cases, trigger phrases, non-fit boundaries, and remote-versus-direct decision criteria are clear, and multiple client languages are covered. Deductions apply because Chinese-language support is not addressed and key references depend on grpc.io and NVIDIA online documentation; the local function is not entirely dependent on overseas services, but mainland-China reachability of external guidance is unverified.
The SKILL.md/CAPABILITIES.md/TASKS.md layering is readable and includes dependencies, limitations, related skills, maintenance contacts, and routing. The front matter states Apache-2.0. Deductions apply because SKILLCARD.yaml has repository-path and license inconsistencies with the supplied metadata, version/signature/scan fields remain TBD, and BENCHMARK.md records missing recommended sections, missing author metadata, and an unexpected file finding.
The remote-versus-local decision, .proto-as-contract rule, binding verification, one-client smoke test, status-code diagnosis, and retesting after configuration changes are directly useful for the target task. Deductions apply because the skill intentionally omits concrete RPCs, complete commands, client examples, and test fixtures, and assumes an installed DOCA environment plus a healthy doca-flow application; static evidence cannot establish directly usable execution, so this remains at most 7.
The material directs agents to installed-version .proto files, --help output, logs, and verbatim status codes, and points to public references; BENCHMARK.md reports evaluation results. Deductions apply because no server implementation, committed key-path tests, or reproducible CI evidence is included, the benchmark dataset is unavailable, and several critical implementation claims require external verification; static review caps this at 5.
- The server exposes a plaintext control plane. Do not interpret the TLS/mTLS/token discussion as binary switches; protection must come from an external proxy, tunnel, or isolated trusted network.
- CAPABILITIES.md and TASKS.md retain authentication/TLS failure scenarios that conflict with the stated lack of built-in authentication. Treat the actual binary, --help output, logs, and installed-version .proto files as authoritative.
- SKILLCARD.yaml has license, repository-path, version, and signature inconsistencies with the supplied metadata, and the benchmark report lacks reproducible evaluation data.
- The skill supplies no concrete RPCs, client implementation, or rollback procedure; real dataplane changes require manual security review and environment validation.
What does this skill do, and when should you use it?
This skill is for operators and developers who need to control a running DOCA Flow pipeline from a process across a network boundary. It covers build prerequisites, server startup and binding, client connectivity, one-client smoke testing, version issues, and layered failure diagnosis. The shipped server uses plaintext gRPC and has no TLS, mTLS, or token-auth configuration knob, so it must remain on a trusted isolated segment protected by an external proxy, sidecar, or VPN. It does not replace the doca-flow API, DOCA installation guidance, or generic gRPC tooling.
It helps users choose between a remote gRPC control plane and directly linking libdoca_flow.so; locate the installed .proto contract and generate language bindings with standard gRPC tooling; build the doca_flow_grpc artifact from a DOCA source tree with gRPC enabled; plan the external proxy, sidecar, VPN, and network segment; and follow startup, binding, smoke-test, and layered debugging workflows. The guidance refers to SKILL.md, CAPABILITIES.md, TASKS.md, DOCA build files, and installed .proto files, producing deployment, routing, testing, and security recommendations.
- A control-plane engineer wants to program Flow rules on a BlueField from Python, Go, or Rust running on another host.
- A platform operator needs to run the remote control surface alongside an existing doca-flow application.
- A security engineer finds the server bound to 0.0.0.0 and needs an external protection and network-isolation plan.
- A developer needs to locate the installed Flow .proto files and generate a version-matched client.
- An operator is investigating connection timeouts, RPC failures, Flow precondition errors, or client-server version mismatches.
What are this skill's strengths and limitations?
- Directly targets remote DOCA Flow control from non-C++ clients.
- Uses the installed .proto files as the contract source of truth instead of pinning stale RPC details or client code.
- Clearly documents the plaintext-only server posture and the need for external security infrastructure.
- Provides routing between a remote control plane and direct libdoca_flow.so linking.
- Requires DOCA, Linux, compatible NVIDIA hardware, and a source build with gRPC enabled.
- doca_flow_grpc is not installed by default, and the supplied material does not include a complete build command or prebuilt binary.
- There is no built-in TLS, mTLS, or token authentication; security depends on an external proxy, sidecar, or VPN.
- It includes no ready-made client code, scripts, samples, RPC method inventory, or message-field inventory.
How do you install this skill?
Install the skill with the repository’s documented skills CLI flow:
npx skills add nvidia/skills --skill doca-flow-grpc-server --yes
The skill becomes available when the target agent next loads relevant skills. It does not ship a prebuilt doca_flow_grpc package; the source states that the binary must be built from a DOCA source tree with gRPC support enabled.
How do you use this skill?
Use it in a Linux environment with DOCA installed, a working doca-flow application, and a BlueField DPU or ConnectX NIC. Example trigger: “I need to program DOCA Flow rules on a BlueField from a Python service on another host; how should I deploy and validate the gRPC server?” Read SKILL.md first, then consult CAPABILITIES.md for the contract, security posture, and error taxonomy, and TASKS.md for configure, run, test, or debug workflows. Smoke-test one client and one RPC end to end before exposing the endpoint more broadly. Do not treat TLS, mTLS, or token authentication as settings of the shipped binary.
How does this skill compare with similar options?
Compared with directly linking libdoca_flow.so, the gRPC control plane fits cases where the controlling process is on another host or across a process boundary. When the client can link the Flow library directly, the skill routes users to consider whether a remote control plane is unnecessary.