尧图网站建设 
1. DAKI、IBGDAGPUDirectRDMA、gpunetioGINGDAGDR这几个词分属三个不同层次技术理念、库/SDK、通信框架特性。下面按层次梳理。1.1. 理念层GPUDirect 家族技术不是库GPUDirect 是 NVIDIA 一系列绕过 CPU的直达技术的总称覆盖存储、网络、GPU 间、视频等方向。网络方向有两个关键成员技术解决的问题含义GPUDirect RDMA (GDR)数据路径网卡通过 PCIe 直接 DMA 读写 GPU 显存零拷贝不再需要 CPU 倒手内存GPUDirect Async (GDA)控制路径GPU 侧自主调度网络操作进一步把 CPU 从控制逻辑中解放出来2016 年 CUDA 8.0 引入GDAKIGPUDirect Async Kernel-Initiated就是 GPUDirect Async 在网络上的具体形态CUDA kernel 里的 GPU 线程自己构造 WQE、敲 NIC doorbell、轮询 CQE整个收发过程 CPU 完全不参与。它在 InfiniBand 上的早期实现叫IBGDAInfiniBand GPUDirect Async最初是 NVSHMEM 内部的一个 transport。1.2. 库层DOCA GPUNetIOGDAKI 的统一实现GDAKI 以前各家NVSHMEM、NCCL各自重复造轮子IBGDANVIDIA 于是把它收敛成一个统一的库——DOCA GPUNetIO官方定位就是同时实现 GPUDirect RDMA数据直达和 GPUDirect Async Kernel-InitiatedGPU 控制通信两项技术。闭源版在 DOCA SDK 里DOCA::gpunetio开源版就是 GitHub 上那个 gpunetio 仓库目标是把多个 GDAKI 实现合并成统一的驱动和库供 NVSHMEM、NCCL、UCX 共用。关系GDAKI 是技术思想GPUNetIO 是这个思想的官方 SDK 实现。官方文档也直接说 “GDAKI is also named IBGDA when used with the RDMA protocol”。1.3. 框架层GINNCCL 的网络模式GINGPU-Initiated Networking是 NCCL 2.28 引入 Device API 时的三种操作模式之一另两个是面向 NVLink/PCIe 的 LSA 和面向 NVLink SHARP 的 MultimemGIN 专管跨节点 RDMA。GIN 的三层架构里最底层是可插拔的网络后端有两个GDAKI 后端libnccl-net-gdaki.so基于DOCA GPUNetIO实现真正的 GPU→NIC 直连要求 ConnectX-6 Dx 及以上Proxy 后端GPU 通过无锁队列把描述符交给 CPU 代理线程转发兼容任意 RDMA 网卡性能较低。1.4. 汇总图┌─────────────────────────────────────────────────────┐ │ 框架层消费者 │ │ NCCL ── Device API ──► GINGPU-Initiated Networking│ │ ├─ GDAKI 后端 ──┐ │ │ └─ Proxy 后端任意 RDMA 网卡│ │ NVSHMEM ── transport: IBGDA ──► 已被 GPUNetIO 取代 │ │ UCX ── GDAKI module │ │ ├───────────────────────────────────┼───────────────────┤ │ 库层实现者 ▼ │ │ DOCA GPUNetIO闭源 SDK / 开源 gpunetio │ │ ├─ GPU 数据路径写 WQE、敲 doorbell、poll CQE │ │ └─ CPU 控制路径建 QP/CQ、导出 GPU 句柄 │ ├──────────────────────────────────────────────────────┤ │ 技术理念层GPUDirect 家族 │ │ GPUDirect RDMA ── 数据路径NIC 直接 DMA 读写 GPU 显存 │ │ GPUDirect Async ── 控制路径GPU 自主调度通信 │ │ └─ GDAKI Kernel-Initiated 形态 │ │ └─ IBGDA GDAKI 在 InfiniBand 上的早期实现 │ └──────────────────────────────────────────────────────┘一条贯穿线GDAKI≈IBGDA是思想 → GPUNetIO 是统一实现 → GIN 是 NCCL 里基于 GPUNetIO 落地的特性而 GPUDirect RDMA 是这一切的地基没有它网卡连 GPU 显存都摸不着。官方生态对应关系是NCCL 的 GIN transport、NVSHMEM 的 GPUNetIO transport替代 IBGDA、UCX 的新 GDAKI 模块全部收敛到 GPUNetIO 之上。顺带一个和你上一个问题的衔接点NVSHMEM 的 GPUNetIO transport 依赖 DOCA SDK 来解锁 Data Direct Placement 等高级网卡特性最低要求版本正是 DOCA 3.4也是通过DOCA_SDK_LIB_PATH环境变量指定的——这就是开源 gpunetio 里那个 SDK 模式设计的实际用途。2. DOCA::gpunetio 与 开源 gpunetio2.1. DOCA 3.4 的模块、作用与依赖关系DOCA 3.4 的 SDK 在编程指南中把组件分为三层DOCA Libraries核心功能库、DOCA Utils辅助工具、DOCA Drivers驱动框架。官方说明每个库都提供 API、文档和示例用于加速数据中心和网络应用开发。1. DOCA Libraries按官方文档结构模块作用DOCA Common含 DOCA Core DOCA Log所有库的地基设备打开、内存管理buf/mmap、进度引擎PE、Sync Event、日志DOCA Flow通用包转发与流表卸载match-action 流水线、steering、RSS、hairpin 等含 Flow Connection Tracking、Flow TuneDPA SubsystemDOCA DPA、DPA Comms、DPA Verbs在 BlueField 的 DPA数据路径加速器核上编程DOCA PCC可编程拥塞控制ZTR-RTTCC、DCQCN 算法DOCA DMABlueField DMA 引擎的内存拷贝DOCA ComchHost 与 DPU 之间的通信通道DOCA UROM把 HPC/AI 并行计算任务从主机卸载到 DPU 的框架DOCA RDMA高层 RDMA 操作封装Write/Send/Read/RecvDOCA RDMA Verbs低层 verbs 风格的 QP/CQ/UMEM/UAR 直接管理是 GDAKI 的基础DOCA Ethernet以太网 TXQ/RXQ 队列创建与管理DOCA GPUNetIOGPU 中心数据路径GDAKI本文主角DOCA App Shield主机入侵检测DOCA Compress硬件压缩/解压卸载DOCA SHA硬件 SHA 计算DOCA Erasure Coding纠删码卸载DOCA AES-GCMAES-GCM 加解密卸载DOCA Rivermax媒体流网络库ST 2110 等DOCA Telemetry / Telemetry Exporter设备遥测数据采集与导出含 Adp Retx、Diag、DPA、PCC、PCI、PHY 子项DOCA Device EmulationDevEmu PCI / Virtio在 DPU 上模拟 PCI/Virtio 设备virtio-fs/net/blk 等DOCA STA简化存储 target 应用如 SPDK、NVMe-oF在 BlueField-3 上的集成与卸载DOCA Management通过 Linux fwctl 框架管理 DPU/主机设备及其 PF/VF/SF、固件配置DOCA UtilsDOCA Arg Parser命令行解析。DOCA DriversDOCA UCX、MLX 驱动文档IB/Ethernet/RDMA 底层驱动能力。2. 模块间依赖关系核心依赖链可概括为DOCA Common / Corelibdoca_common 设备、内存 buf/mmap、PE、Sync Event、Log ┌──────────┼──────────┬──────────┐ ▼ ▼ ▼ ▼ DOCA Flow DPA 子系统 DOCA RDMA DOCA DMA Ethernet RDMA Verbs Comch ... │ ┌──┴──┐ │ │ DOCA PCC UROM │ ▼ ▼ ▼ ▼ └─────► DOCA GPUNetIO ◄─────┘ 组合 EthernetFlow / RDMA / Verbs / DMA / Comch一切库都依赖 DOCA Common设备句柄、内存注册、进度引擎、日志都由它提供。DPA 子系统基于 CorePCC的数据路径运行在 DPA 上UROM基于 DPA Comch。RDMA / RDMA Verbs / Ethernet底层走 mlx5/libibverbs 驱动层。GPUNetIO 是组合者它本身不创建队列而是给 Core、Ethernet、Flow、RDMA、Verbs、DMA、Comch 创建的对象导出 GPU 句柄让 CUDA kernel 直接操作。2.2. 开源 gpunetio 依赖 DOCA 的哪些模块答案默认模式下一个 DOCA 模块都不依赖。这正是它的设计目标——“open-source version of DOCA GPUNetIO and DOCA Verbs libraries”即用开源代码重新实现这两个库的功能子集让 GDAKI 可以在无 DOCA SDK 的环境运行。我克隆仓库分析了 Makefile 和源码它的实际依赖是依赖方式说明libibverbslibmlx5直接链接-libverbs -lmlx5rdma-core / MLNX_OFED 用户态 verbsQP/CQ/MR 的实际创建者libcudaCUDA Driver APIlibcudart_static直接链接GPU 控制与示例libgdrapi.so.2GDRCopy运行时 dlopenCPU 侧映射/访问 GPU 显存MPI可选示例用Makefile 里有MPI_HOME它自带了doca_verbs_dev/qp/cq/umem/uar和doca_gpu_*的完整开源实现src/doca_verbs_*.cpp直接调ibv_*和mlx5dv_*所以纯开源模式与 DOCA 解耦。但有一个可选的 “SDK 模式”设置环境变量DOCA_SDK_LIB_PATH指向 DOCA 安装目录如/opt/mellanox/doca/lib/x86_64-linux-gnu后它会通过dlopen动态加载三个 DOCA 闭源库以解锁受限功能libdoca_common.soDOCA Corelibdoca_verbs.soDOCA RDMA Verbslibdoca_gpunetio.soDOCA GPUNetIO 闭源版我在源码中确认了这三个.so正是*_sdk_wrapper.cpp里 dlopen 的目标。2.3. 闭源完整版GPUNetIO 依赖 DOCA 的哪些模块闭源 GPUNetIO 由三部分组成libdoca_gpunetio.soCPU 控制路径、libdoca_gpunetio_device.aGPU 数据路径静态库含 RDMA/DMA/CommCh 的 device 函数、doca_gpunetio_dev_*.cuh头文件Ethernet 和 Verbs 的内联 device 函数。按官方架构文档它依赖/组合的 DOCA 模块如下DOCA 模块在 GPUNetIO 中的作用必要性DOCA Common / Core创建网卡设备句柄、GPU 设备、内存管理必需DOCA RDMA Verbs创建 QP/CQ/UAR/UMEM供 Verbs GDAKIIBGDA数据路径使用支持单边双边 RDMAVerbs 功能必需DOCA RDMA高层 RDMA 队列Write/Send/Read/Recvdevice 函数在静态库.a里高层 RDMA 必需DOCA Ethernet创建 TXQ/RXQ 收发队列并导出 GPU 句柄以太网功能必需DOCA Flow安装流规则把报文 steering 到 GPU 管理的队列以太网接收必需需 rootDOCA DMA创建 DMA 队列GPU kernel 可触发 BlueField DMA 引擎拷贝DMA 功能必需DOCA ComchGPUNetIO CommCh 设备函数GPU 侧通道通信包含在静态库中CommCh 功能必需官方原文也明确以太网 GDAKI 需要 GPUNetIO Ethernet Flow 三个库组合DMA 则需要 GPUNetIO DMA 两个库。此外是外部非 DOCA依赖libdoca_gpunetio.so依赖libcuda.soCUDA Driver API静态设备库libdoca_gpunetio_device.a用 CUDA 13.0 预编译链接它的应用必须用 CUDA 13.0另有 GDRCopy、mlx5 驱动、nvidia-peermem/dmabuf 等系统级依赖。开源 vs 闭源速览能力闭源 Full SDK开源版Verbs 单边 GPU 数据路径Read/Write/Atomic✔✔头文件两边相同Verbs 双边 GPU 数据路径Send/Recv✔✘Ethernet GPU 数据路径依赖 EthFlow✔✘DMA GPU 数据路径依赖 DOCA DMA✔✘CommCh GPU 数据路径✔✘CPU 控制路径闭源 .so开源 C直连 libibverbs/libmlx5对 DOCA 的依赖依赖 Core/Verbs/RDMA/Eth/Flow/DMA/Comch无可选 dlopen 三个 .so 解锁受限功能功能差异以官方 README 的 Open vs Full 表为准。总结开源 gpunetio 是对 DOCA GPUNetIO DOCA Verbs 的开源重写默认只依赖 rdma-corelibibverbs/libmlx5、CUDA 和 GDRCopy不依赖任何 DOCA 闭源模块闭源完整版则建立在 DOCA Core 之上横向组合 Verbs、RDMA、Ethernet、Flow、DMA、Comch 六个模块功能覆盖单边/双边 RDMA、以太网收发和 DMA。 DOCA 的模块、作用与依赖关系
1. DAKI、IBGDAGPUDirectRDMA、gpunetioGINGDAGDR这几个词分属三个不同层次技术理念、库/SDK、通信框架特性。下面按层次梳理。1.1. 理念层GPUDirect 家族技术不是库GPUDirect 是 NVIDIA 一系列绕过 CPU的直达技术的总称覆盖存储、网络、GPU 间、视频等方向。网络方向有两个关键成员技术解决的问题含义GPUDirect RDMA (GDR)数据路径网卡通过 PCIe 直接 DMA 读写 GPU 显存零拷贝不再需要 CPU 倒手内存GPUDirect Async (GDA)控制路径GPU 侧自主调度网络操作进一步把 CPU 从控制逻辑中解放出来2016 年 CUDA 8.0 引入GDAKIGPUDirect Async Kernel-Initiated就是 GPUDirect Async 在网络上的具体形态CUDA kernel 里的 GPU 线程自己构造 WQE、敲 NIC doorbell、轮询 CQE整个收发过程 CPU 完全不参与。它在 InfiniBand 上的早期实现叫IBGDAInfiniBand GPUDirect Async最初是 NVSHMEM 内部的一个 transport。1.2. 库层DOCA GPUNetIOGDAKI 的统一实现GDAKI 以前各家NVSHMEM、NCCL各自重复造轮子IBGDANVIDIA 于是把它收敛成一个统一的库——DOCA GPUNetIO官方定位就是同时实现 GPUDirect RDMA数据直达和 GPUDirect Async Kernel-InitiatedGPU 控制通信两项技术。闭源版在 DOCA SDK 里DOCA::gpunetio开源版就是 GitHub 上那个 gpunetio 仓库目标是把多个 GDAKI 实现合并成统一的驱动和库供 NVSHMEM、NCCL、UCX 共用。关系GDAKI 是技术思想GPUNetIO 是这个思想的官方 SDK 实现。官方文档也直接说 “GDAKI is also named IBGDA when used with the RDMA protocol”。1.3. 框架层GINNCCL 的网络模式GINGPU-Initiated Networking是 NCCL 2.28 引入 Device API 时的三种操作模式之一另两个是面向 NVLink/PCIe 的 LSA 和面向 NVLink SHARP 的 MultimemGIN 专管跨节点 RDMA。GIN 的三层架构里最底层是可插拔的网络后端有两个GDAKI 后端libnccl-net-gdaki.so基于DOCA GPUNetIO实现真正的 GPU→NIC 直连要求 ConnectX-6 Dx 及以上Proxy 后端GPU 通过无锁队列把描述符交给 CPU 代理线程转发兼容任意 RDMA 网卡性能较低。1.4. 汇总图┌─────────────────────────────────────────────────────┐ │ 框架层消费者 │ │ NCCL ── Device API ──► GINGPU-Initiated Networking│ │ ├─ GDAKI 后端 ──┐ │ │ └─ Proxy 后端任意 RDMA 网卡│ │ NVSHMEM ── transport: IBGDA ──► 已被 GPUNetIO 取代 │ │ UCX ── GDAKI module │ │ ├───────────────────────────────────┼───────────────────┤ │ 库层实现者 ▼ │ │ DOCA GPUNetIO闭源 SDK / 开源 gpunetio │ │ ├─ GPU 数据路径写 WQE、敲 doorbell、poll CQE │ │ └─ CPU 控制路径建 QP/CQ、导出 GPU 句柄 │ ├──────────────────────────────────────────────────────┤ │ 技术理念层GPUDirect 家族 │ │ GPUDirect RDMA ── 数据路径NIC 直接 DMA 读写 GPU 显存 │ │ GPUDirect Async ── 控制路径GPU 自主调度通信 │ │ └─ GDAKI Kernel-Initiated 形态 │ │ └─ IBGDA GDAKI 在 InfiniBand 上的早期实现 │ └──────────────────────────────────────────────────────┘一条贯穿线GDAKI≈IBGDA是思想 → GPUNetIO 是统一实现 → GIN 是 NCCL 里基于 GPUNetIO 落地的特性而 GPUDirect RDMA 是这一切的地基没有它网卡连 GPU 显存都摸不着。官方生态对应关系是NCCL 的 GIN transport、NVSHMEM 的 GPUNetIO transport替代 IBGDA、UCX 的新 GDAKI 模块全部收敛到 GPUNetIO 之上。顺带一个和你上一个问题的衔接点NVSHMEM 的 GPUNetIO transport 依赖 DOCA SDK 来解锁 Data Direct Placement 等高级网卡特性最低要求版本正是 DOCA 3.4也是通过DOCA_SDK_LIB_PATH环境变量指定的——这就是开源 gpunetio 里那个 SDK 模式设计的实际用途。2. DOCA::gpunetio 与 开源 gpunetio2.1. DOCA 3.4 的模块、作用与依赖关系DOCA 3.4 的 SDK 在编程指南中把组件分为三层DOCA Libraries核心功能库、DOCA Utils辅助工具、DOCA Drivers驱动框架。官方说明每个库都提供 API、文档和示例用于加速数据中心和网络应用开发。1. DOCA Libraries按官方文档结构模块作用DOCA Common含 DOCA Core DOCA Log所有库的地基设备打开、内存管理buf/mmap、进度引擎PE、Sync Event、日志DOCA Flow通用包转发与流表卸载match-action 流水线、steering、RSS、hairpin 等含 Flow Connection Tracking、Flow TuneDPA SubsystemDOCA DPA、DPA Comms、DPA Verbs在 BlueField 的 DPA数据路径加速器核上编程DOCA PCC可编程拥塞控制ZTR-RTTCC、DCQCN 算法DOCA DMABlueField DMA 引擎的内存拷贝DOCA ComchHost 与 DPU 之间的通信通道DOCA UROM把 HPC/AI 并行计算任务从主机卸载到 DPU 的框架DOCA RDMA高层 RDMA 操作封装Write/Send/Read/RecvDOCA RDMA Verbs低层 verbs 风格的 QP/CQ/UMEM/UAR 直接管理是 GDAKI 的基础DOCA Ethernet以太网 TXQ/RXQ 队列创建与管理DOCA GPUNetIOGPU 中心数据路径GDAKI本文主角DOCA App Shield主机入侵检测DOCA Compress硬件压缩/解压卸载DOCA SHA硬件 SHA 计算DOCA Erasure Coding纠删码卸载DOCA AES-GCMAES-GCM 加解密卸载DOCA Rivermax媒体流网络库ST 2110 等DOCA Telemetry / Telemetry Exporter设备遥测数据采集与导出含 Adp Retx、Diag、DPA、PCC、PCI、PHY 子项DOCA Device EmulationDevEmu PCI / Virtio在 DPU 上模拟 PCI/Virtio 设备virtio-fs/net/blk 等DOCA STA简化存储 target 应用如 SPDK、NVMe-oF在 BlueField-3 上的集成与卸载DOCA Management通过 Linux fwctl 框架管理 DPU/主机设备及其 PF/VF/SF、固件配置DOCA UtilsDOCA Arg Parser命令行解析。DOCA DriversDOCA UCX、MLX 驱动文档IB/Ethernet/RDMA 底层驱动能力。2. 模块间依赖关系核心依赖链可概括为DOCA Common / Corelibdoca_common 设备、内存 buf/mmap、PE、Sync Event、Log ┌──────────┼──────────┬──────────┐ ▼ ▼ ▼ ▼ DOCA Flow DPA 子系统 DOCA RDMA DOCA DMA Ethernet RDMA Verbs Comch ... │ ┌──┴──┐ │ │ DOCA PCC UROM │ ▼ ▼ ▼ ▼ └─────► DOCA GPUNetIO ◄─────┘ 组合 EthernetFlow / RDMA / Verbs / DMA / Comch一切库都依赖 DOCA Common设备句柄、内存注册、进度引擎、日志都由它提供。DPA 子系统基于 CorePCC的数据路径运行在 DPA 上UROM基于 DPA Comch。RDMA / RDMA Verbs / Ethernet底层走 mlx5/libibverbs 驱动层。GPUNetIO 是组合者它本身不创建队列而是给 Core、Ethernet、Flow、RDMA、Verbs、DMA、Comch 创建的对象导出 GPU 句柄让 CUDA kernel 直接操作。2.2. 开源 gpunetio 依赖 DOCA 的哪些模块答案默认模式下一个 DOCA 模块都不依赖。这正是它的设计目标——“open-source version of DOCA GPUNetIO and DOCA Verbs libraries”即用开源代码重新实现这两个库的功能子集让 GDAKI 可以在无 DOCA SDK 的环境运行。我克隆仓库分析了 Makefile 和源码它的实际依赖是依赖方式说明libibverbslibmlx5直接链接-libverbs -lmlx5rdma-core / MLNX_OFED 用户态 verbsQP/CQ/MR 的实际创建者libcudaCUDA Driver APIlibcudart_static直接链接GPU 控制与示例libgdrapi.so.2GDRCopy运行时 dlopenCPU 侧映射/访问 GPU 显存MPI可选示例用Makefile 里有MPI_HOME它自带了doca_verbs_dev/qp/cq/umem/uar和doca_gpu_*的完整开源实现src/doca_verbs_*.cpp直接调ibv_*和mlx5dv_*所以纯开源模式与 DOCA 解耦。但有一个可选的 “SDK 模式”设置环境变量DOCA_SDK_LIB_PATH指向 DOCA 安装目录如/opt/mellanox/doca/lib/x86_64-linux-gnu后它会通过dlopen动态加载三个 DOCA 闭源库以解锁受限功能libdoca_common.soDOCA Corelibdoca_verbs.soDOCA RDMA Verbslibdoca_gpunetio.soDOCA GPUNetIO 闭源版我在源码中确认了这三个.so正是*_sdk_wrapper.cpp里 dlopen 的目标。2.3. 闭源完整版GPUNetIO 依赖 DOCA 的哪些模块闭源 GPUNetIO 由三部分组成libdoca_gpunetio.soCPU 控制路径、libdoca_gpunetio_device.aGPU 数据路径静态库含 RDMA/DMA/CommCh 的 device 函数、doca_gpunetio_dev_*.cuh头文件Ethernet 和 Verbs 的内联 device 函数。按官方架构文档它依赖/组合的 DOCA 模块如下DOCA 模块在 GPUNetIO 中的作用必要性DOCA Common / Core创建网卡设备句柄、GPU 设备、内存管理必需DOCA RDMA Verbs创建 QP/CQ/UAR/UMEM供 Verbs GDAKIIBGDA数据路径使用支持单边双边 RDMAVerbs 功能必需DOCA RDMA高层 RDMA 队列Write/Send/Read/Recvdevice 函数在静态库.a里高层 RDMA 必需DOCA Ethernet创建 TXQ/RXQ 收发队列并导出 GPU 句柄以太网功能必需DOCA Flow安装流规则把报文 steering 到 GPU 管理的队列以太网接收必需需 rootDOCA DMA创建 DMA 队列GPU kernel 可触发 BlueField DMA 引擎拷贝DMA 功能必需DOCA ComchGPUNetIO CommCh 设备函数GPU 侧通道通信包含在静态库中CommCh 功能必需官方原文也明确以太网 GDAKI 需要 GPUNetIO Ethernet Flow 三个库组合DMA 则需要 GPUNetIO DMA 两个库。此外是外部非 DOCA依赖libdoca_gpunetio.so依赖libcuda.soCUDA Driver API静态设备库libdoca_gpunetio_device.a用 CUDA 13.0 预编译链接它的应用必须用 CUDA 13.0另有 GDRCopy、mlx5 驱动、nvidia-peermem/dmabuf 等系统级依赖。开源 vs 闭源速览能力闭源 Full SDK开源版Verbs 单边 GPU 数据路径Read/Write/Atomic✔✔头文件两边相同Verbs 双边 GPU 数据路径Send/Recv✔✘Ethernet GPU 数据路径依赖 EthFlow✔✘DMA GPU 数据路径依赖 DOCA DMA✔✘CommCh GPU 数据路径✔✘CPU 控制路径闭源 .so开源 C直连 libibverbs/libmlx5对 DOCA 的依赖依赖 Core/Verbs/RDMA/Eth/Flow/DMA/Comch无可选 dlopen 三个 .so 解锁受限功能功能差异以官方 README 的 Open vs Full 表为准。总结开源 gpunetio 是对 DOCA GPUNetIO DOCA Verbs 的开源重写默认只依赖 rdma-corelibibverbs/libmlx5、CUDA 和 GDRCopy不依赖任何 DOCA 闭源模块闭源完整版则建立在 DOCA Core 之上横向组合 Verbs、RDMA、Ethernet、Flow、DMA、Comch 六个模块功能覆盖单边/双边 RDMA、以太网收发和 DMA。