What problem does it solve?
Developers sometimes need low-level RDMA or Ethernet queue control that the higher-level DOCA libraries (doca-rdma, doca-eth, doca-rmax) do not expose, such as a specific work-request flag, QP attribute, SRQ option, or congestion-control group. This Skill helps an agent decide whether dropping to the raw doca-verbs API is justified, and then walks through configuring, building, porting, testing, and debugging doca_verbs_* code inside the DOCA Core lifecycle.
Core Features & Use Cases
- Drop-down decision gating: Re-checks whether the higher-level DOCA library already covers the user's case and routes most users back up before any raw-verbs work begins.
- Capability discovery: Uses doca_verbs_query_device and the doca_verbs_device_attr_get_* family to verify that a specific verb, opcode, WR flag, or QP feature is supported on the installed device and DOCA version.
- libibverbs porting guidance: Walks through replacing ibv_* handles with doca_verbs_* handles, integrating with the DOCA Core lifecycle and progress engine, and enforcing the no-mixing rule between the two libraries.
- Error diagnosis: Maps DOCA_ERROR_* results from doca_verbs_* calls to lifecycle, capability, permission, or completion-status causes, including the IO_FAILED rule that the answer lives in the completion-queue entry.
- Use case: A developer porting an existing libibverbs sender that relies on a custom QP attribute can use this Skill to confirm the higher-level library cannot express it, capability-query the device, build the verbs context, and drive completions through the DOCA progress engine.
Quick Start
Ask your agent whether you need to drop to doca-verbs for a specific raw QP attribute that the doca-rdma task API does not expose, and have it walk the configure and capability-query workflow.