[BUG] IGX Thor DevKit raw GPUDirect Testing Follow-ups

[RamyaGuru]

Body

Four follow-ups from the IGX Thor raw GPUDirect session (aarch64, driver 580.00/CUDA 13.0, 256 MiB BAR1, ConnectX-7, daqiri 1134167).

---

1. build-container.sh hardcodes CUDA 13.1 — unusable on IGX Thor (driver 13.0) [High]

scripts/build-container.sh unconditionally sets DAQIRI_OS_BASE_IMAGE=nvcr.io/nvidia/cuda:13.1.0-devel-ubuntu24.04. The IGX Thor BSP ships driver 580.00/CUDA 13.0; a 13.1 runtime cannot init against it (cudaGetDeviceCount → "unsupported display driver / cuda driver combination"; cuda-compat is datacenter-only and doesn't apply to Tegra). The Dockerfile already threads DAQIRI_OS_BASE_IMAGE as a build-arg but the wrapper script never exposes it.

Fix: let DAQIRI_OS_BASE_IMAGE (or a CUDA_VERSION shorthand) pass through from the environment instead of being hardcoded; document a cuda:13.0.0-devel override option. Optionally auto-detect the host driver's CUDA version.

Verified workaround: --build-arg DAQIRI_OS_BASE_IMAGE=nvcr.io/nvidia/cuda:13.0.0-devel-ubuntu24.04 builds and runs fine (~1 min rebuild with DPDK layer cached).

---

2. NIC descriptor ring depth hardcoded at 8192 with no YAML config path [Medium-High]

DpdkEngine::default_num_rx_desc / default_num_tx_desc are fixed at 8192 with no way to override from YAML. adjust_memory_regions documents that a queue-backed MR needs num_bufs ≥ ~3× ring (= 24576) to avoid worker starvation (rx_mbuf_allocation_errors in the 100ks → flow-control pauses TX → ~885 pps). On a 256 MiB BAR1 GPU, two 8 KB-buffer GPUDirect regions cannot reach 24576 bufs (24576 × 8192 × 2 = 384 MiB), so the ring must shrink — but there is no supported way to do it.

Workaround used this session: env overrides DAQIRI_NUM_RX_DESC/DAQIRI_NUM_TX_DESC read in DpdkEngine::initialize() (not upstreamed). Setting both to 2048 → num_bufs 12288 is ~6× ring, no starvation, 178 Gb/s.

Proper fix: promote to per-queue YAML fields (num_rx_desc/num_tx_desc) with the env vars as a fallback override; document the num_bufs sizing rule alongside it.

---

3. Silent TX hang when num_bufs < 2 * batch_size — no preflight error [Medium]

DpdkEngine::is_tx_burst_available requires avail_mbufs >= num_pkts * 2. When this isn't satisfied, TX produces bursts=0 forever with no error — indistinguishable from a misconfigured flow or dead link. adjust_memory_regions only guards the ring-deadlock case (1.5× ring), not the 2×-batch case.

Fix: add a validate_config() check that each TX queue's backing MR has num_bufs ≥ 2 * batch_size, aborting init with an actionable message (mirror the existing hugepage-preflight style). Document the constraint.
---
### 4. DPDK engine: silent dma-buf → peermem fallback produces cryptic error [Low]
When CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED is 0 (e.g. wrong GPU selected — common on Tegrane_dpdk.cppsilently falls back torte_extmem_register (peermem). This later fails atrte_dev_dma_mapwith a bareInvalid argument, and the root cause (dma-buf unsupported for the selected device, peermem not loaded) is very hard to infer. Note: #239 added a clearer message for the analogous path in the ibverbs engine's register_mr. The DPDK engine's dma-buf-to-peermem fallback path is still silent. **Fix:** when CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED` is 0 in the DPDK engine, log the selected device name/UUID and whether the peermem kernel module is loaded before falling back, so "wrong GPU selected" is diagnosable.

---

Discovered on: IGX Thor aarch64, kernel 6.8.0-1019-nvidia-tegra-rt, host driver 580.00oceP4p3s0f0/f1), daqiri 1134167`.