doca-gpunetio

DOCA GPUNetIO

Examples

• "CUDA kernel reading packets directly from the NIC." — this is in scope. Stay on doca_gpu_eth_rxq / _txq and the persistent kernel; do not rewrite it as host-CPU Ethernet.
• "DOCA_ERROR_DRIVER on doca_gpu_create." — check CUDA device match and dmabuf / nvidia-peermem registration before changing queue type.

Instructions

Follow Loading order below. Open the tasks companion for configure / build / run. Open the capabilities companion for GPU vs host path selection. Do not open every companion file.

Where to start: This skill assumes DOCA is already installed, the CUDA toolkit is installed and matched to the DOCA install, and the user is doing hands-on GPUNetIO work — i.e. wiring a DOCA network queue into a CUDA kernel on an NVIDIA GPU. Open the tasks companion if the user wants to do something (configure / build / modify / run / test / debug); open the capabilities companion when the question is what can GPUNetIO express on this version + this GPU. If the user has not installed DOCA yet, route to doca-setup/SKILL.md first; if the user has not set up the underlying Ethernet RX/TX queues yet, that is a DOCA Ethernet question — route to doca-eth/SKILL.md.

Example questions this skill answers well

The CLASSES of GPUNetIO questions this skill is built to answer, each with one worked example. The agent should treat the class as the load-bearing piece — the worked example is a single instance.

• "How do I get a CUDA kernel to receive packets directly from the NIC?" — worked example: "persistent kernel on one GPU reads packets from a doca_gpu_eth_rxq built on top of a representor doca_eth_rxq and counts them per-flow". Answered by the persistent-kernel pattern in

  Capabilities and modes

  • the GPU-side bring-up workflow in

  configure.

• "Can I run GPUNetIO on this GPU?" — worked example: "my host has one Ampere card and one Turing card; which one supports GPU-initiated networking?". Answered by the dual capability-discovery rule (DOCA cap-query AND cudaGetDeviceProperties against the CUDA device ordinal) in

  Capabilities and modes

  • the device-enumeration step in

  configure.

• "Why does my GPUNetIO setup fail with DOCA_ERROR_NOT_SUPPORTED even though doca-eth came up fine?" — worked example: "nvidia_peermem is not loaded so GPUDirect RDMA is unavailable". Answered by the env preconditions in ## Safety policy
  • the env checklist in

  configure step 1.

• "How do I move data between CUDA-allocated buffers and a DOCA queue?" — worked example: "use cudaMalloc for the receive buffer pool and register it with DOCA via doca_buf_arr_create_* before starting the context". Answered by the CUDA-allocator
  • DOCA-registration overlay in

  Safety policy

  • the buffer-prep step in

  configure step 4.

• "Is the GPUNetIO API I'm reading about on my installed DOCA + CUDA combination?" — worked example: "is the persistent-kernel helper available with the CUDA toolkit version I have?". Answered by the version-compatibility overlay in

  Version compatibility

  which cross-links the canonical detection chain in doca-version/SKILL.md and adds the GPUNetIO-specific DOCA must match CUDA overlay.
• "What does this DOCA_ERROR_* from a GPUNetIO call mean and which layer caused it?" — worked example: "DOCA_ERROR_DRIVER on doca_gpu_*_create — is it DOCA, CUDA, or the underlying doca-eth queue?". Answered by the GPUNetIO overlay on the cross-library taxonomy in

  Error taxonomy

  • the layered ladder in

  debug that escalates to

  doca-debug/SKILL.md.