DOCA Common Foundation
A shared programming foundation for DOCA applications on BlueField and ConnectX.
The material is explicitly documentation guidance, states that no credentials are required, and routes installation, hardware safety, and debugging elsewhere. However, its run workflows involve devices, file redirection, and hardware-adjacent actions without a complete confirmation, least-privilege, rollback, or sensitive-data-handling procedure, so points are deducted.
SKILL.md, CAPABILITIES.md, and TASKS.md are broadly consistent on lifecycle order, capability checks, PE progress, and error routing, and commonly require stopping or escalating on failure. Static review cannot reproduce key paths; several API, version, and installation assumptions depend on the local environment, and test coverage and failure-output contracts are thin, so the score is capped and reduced.
Triggers, audience, examples, and non-fit boundaries are unusually explicit, including C/C++ and FFI consumers. There is no Chinese-language guidance or mainland-China reachability analysis, while core references and prerequisites depend on NVIDIA documentation, a local DOCA installation, and specialized hardware, so points are deducted.
The loader, capability reference, and task workflows provide good progressive structure, cross-links, examples, boundaries, evaluation notes, and security contacts. Version, signature, and scan fields remain TBD; maintenance ownership and change history are incomplete; and license statements conflict across files (Apache-2.0, Apache-2.0 AND CC-BY-4.0, and NOASSERTION metadata), so points are deducted.
The files directly address device discovery, capability gating, buffer lifecycles, contexts, progress engines, logging, and debugging routes, plausibly covering the core guidance task. They provide no directly compilable implementation or representative reproducible outputs, and BENCHMARK.md says the evaluation dataset is unavailable; static evidence cannot establish complete directly usable results, so the score is limited to the static ceiling.
Committed evals, BENCHMARK.md, SKILLCARD, and traceable symbol/workflow references provide limited auditability. The evaluation dataset is unavailable, reported results cannot be independently reproduced from the supplied files, and there is little corroboration across independent evidence types, so points are deducted.
- This is a low-confidence static review; no commands, samples, or tests were executed.
- Before use, verify the local DOCA version, hardware capabilities, permissions, and API availability; the documented workflows are not verified code.
- License, version/signing, and maintenance metadata should be reconciled, with Chinese guidance, failure-output examples, confirmation requirements, and rollback boundaries added.
What does this skill do, and when should you use it?
DOCA Common is for developers building DOCA applications on a BlueField DPU or ConnectX NIC. It covers doca_ctx lifecycle management, device discovery and capability gating, zero-copy buffer wiring, progress-engine completion handling, and DOCA Log’s two-tier model. The skill is a thin loader that directs agents to CAPABILITIES.md and TASKS.md for substantive guidance. It assumes the DOCA SDK is already installed and does not cover installation or isolated per-library programming.
It directs the agent to inspect the local DOCA installation with pkg-config --modversion doca-common and the /opt/mellanox/doca/{lib,include,samples,applications} layout; plan lifecycles and connections for doca_devinfo, doca_dev, doca_ctx, doca_mmap, doca_buf_inventory, doca_buf, and doca_pe; gate feature use on doca_*_cap_* checks against the active device information; explain the distinction between --sdk-log-level and application-side log settings; and route installation, documentation lookup, and library-specific questions to related skills.
- A developer starting a BlueField-3 Flow, RDMA, or Ethernet application who needs the shared context and progress-engine skeleton first.
- A developer who must discover a device and decide at runtime whether its active capabilities support a feature.
- A developer sharing zero-copy buffers across doca-eth, doca-dma, and doca-rdma.
- A developer whose submitted tasks do not complete and who needs to inspect the doca_pe progress loop.
- A developer whose application `DOCA_LOG_DBG` lines remain invisible after setting `--sdk-log-level`.
- A developer designing Rust, Go, or Python bindings around the DOCA public C ABI.
What are this skill's strengths and limitations?
- Covers the shared ctx, dev, buf, PE, and logging primitives used across DOCA applications.
- Treats capabilities on the active doca_devinfo as the runtime authority for feature use.
- Targets common lifecycle, cross-library zero-copy, completion, and logging failure modes.
- Keeps the foundation language-neutral for FFI and binding users while treating the public C ABI as authoritative.
- Requires a preinstalled DOCA SDK, Linux, and an attached BlueField DPU or ConnectX NIC; it does not install DOCA.
- The SKILL.md is a thin loader, so detailed procedures depend on CAPABILITIES.md and TASKS.md, whose contents are not included here.
- It deliberately provides no buildable application source, standalone build manifests, samples, bindings, or reference subtree.
- The source states supported Linux distributions but provides no independent test results or detailed hardware coverage matrix.
How do you install this skill?
Install the named skill using the repository README’s Skills CLI flow: npx skills add nvidia/skills --skill doca-common --yes. The CLI selects or writes the installation destination; manually cloning the repository or copying the folder is not required. The README does not document a separate doca-common package installer.
How do you use this skill?
On a Linux host with the DOCA SDK installed, ask the agent for a hands-on foundation task, for example: My doca_rdma tasks submit successfully but never complete; inspect the doca_pe and run loop. For universal primitives, have it read CAPABILITIES.md; for configure, build, modify, run, test, debug, use, or log workflows, have it read TASKS.md. Load the matching per-library skill alongside it for Flow, RDMA, Ethernet, or other library-specific work.