业余程序员plus-优快云博客

原创 RDMA-Verbs-GPU 内存与 DMA-BUF（十一）

GPU DMA-BUF 路径包含三个不同问题：exporter 先把 GPU allocation 封装为共享对象；importer 再取得面向自身设备的 DMA mapping；应用最后负责安排 GPU 和 RDMA 的执行顺序。返回 GPU pointer。ROCr 在 allocation map 中定位包含该指针的 allocation，libhsakmt 把指针转换成 KFD handle 和导出对象内 offset。AMDKFD 由 handle 找到kgd_mem。

2026-10-23 14:10:11 378

原创 RDMA-Verbs-数据收发与完成（十）

接口定义功能把一个或多个发送 WR 发布到 SQ。把一个或多个接收 WR 发布到 RQ。为指定设备 context 创建 completion channel，成功返回 channel，失败返回NULL并设置errno。应用随后在创建 CQ 时传入该 channel，以关联完成通知。销毁 completion channel，关闭其 fd 并释放用户态对象。仍有关联 CQ 时返回EBUSY，成功返回 0。从 CQ 获取 WC(work completions)。时任意新 CQE 均可触发；

2026-10-23 10:41:00 180

原创 RDMA-Verbs-QP、CQ 和 EQ（九）

用户态与内核态的资源入口和队列内存所有权不同，但最终都建立相同的 QPC、CQC、QPN、CQN 和 EQN。QP 通过 QPC 中的 send/recv CQN 选择 CQ，CQ 通过 CQC 中的 EQN 选择 completion EQ；二者分别承担完成对象关联和通知关联。是 completion EQ 软件映射表的逻辑索引，不是 EQN、MSI-X vector index 或 Linux IRQ number。

2026-10-22 17:51:58 141

原创 RDMA-Verbs-内存管理（八）

RDMA 内存管理不同类型的内存、分配接口和注册机制：主机或设备内存可由应用、provider 或设备驱动分配，DMA-BUF 表达共享来源；ibv_bufibv_dm管理分配对象，MR 注册将地址区间、PD 和访问权限关联到 MKey。

2026-10-22 17:47:40 190 1

原创 RDMA-Verbs-内核 MLX5 驱动（七）

MLX5 内核驱动由相互配合的两层组成。mlx5_core是设备公共层，管理 PCI function、BAR、DMA、固件命令、IRQ、EQ 和 auxiliary device；mlx5_ib是 RDMA 协议层，把 RDMA Core 的设备和 Verbs 对象转换成 mlx5 设备资源，并把设备事件转换为 RDMA 事件。两层通过、命令接口和 notifier 接口连接。

2026-10-22 17:21:35 252

原创 RDMA-Verbs-内核 RDMA Core（六）

Linux RDMA Core 位于 uverbs、内核消费者与硬件驱动之间。其用表示一个 RDMA 设备，以连接 mlx5_ib 驱动，并为 PD、MR、CQ、QP 等资源提供通用对象、依赖计数和资源跟踪。用户态命令和内核 Verbs 最终都可以到达同一组驱动回调，但两条路径的对象入口、用户数据和清理规则不同。RDMA 驱动创建设备对象：mlx5_ib 的调用，由 RDMA Core 的分配包含内嵌ib_device的完整对象。Device（设备管理）负责ib_device的注册、端口和设备引用；

2026-10-21 14:48:23 340

原创 RDMA-Verbs-内核 uverbs 接口（五）

本文分析 Linux 内核中的 uverbs 实现。uverbs 通过接收用户态 libibverbs 和 provider 提交的控制请求，校验命令与参数，管理用户上下文和资源句柄，并通过通用辅助函数或设备回调完成 PD、MR、CQ、QP 等资源操作。它还提供能力查询、事件文件和内存映射入口。当前实现同时保留两套命令路径。原生 ioctl ABI 用 object、method 和 attribute 描述请求，内核根据运行期 UAPI 树校验并分发属性；

2026-10-21 11:46:59 246

原创 RDMA-Verbs-MLX5 用户态库（四）

mlx5 provider 接收 libibverbs 分发的 Verbs 操作，在用户态建立私有对象、队列 buffer、doorbell record（DBR）和 UAR 映射。创建资源时，provider 通过 uverbs 完成设备配置。在用户态操作 QP 和门铃完成数据收发，通过轮询和解析用户态 CQ 队列中的 CQE 获取完成事件信息。下图将 mlx5 provider 分成操作分发、控制面、数据面和公共资源四部分。控制面在verbs.c中管理资源并封装命令；qp.c构造和提交 WQE，

2026-10-21 11:33:46 317

原创 RDMA-Verbs-文章导读（一）

本系列以 Linux、rdma-core 和 mlx5 为分析对象，从 Verbs API 开始逐层分析用户态 provider、uverbs、RDMA Core、mlx5 内核驱动和 HCA 硬件，并进一步梳理内存注册、队列创建、数据收发、完成通知以及 GPU DMA-BUF 使用流程。本文说明各篇文章的定位、阅读顺序和源码入口。

2026-10-20 20:44:09 217

原创 RDMA-Verbs-软件架构（二）

软件通过设备命令配置资源，通过 MMIO 等设备接口通知 HCA 执行请求，通过 CQ 获取完成结果，并按需接收事件通知。应用通过 WR 描述请求，通过 WC 获得相应的完成结果。RDMA 软件栈分为五层：应用组织通信任务，用户态库提供 API 和设备相关操作，内核服务管理设备与资源，mlx5 驱动连接通用接口与具体设备，HCA 根据配置访问内存并执行请求。是 RDMA 设备驱动，负责把通用 RDMA 对象和请求转换为 mlx5 资源配置，管理 MR、QP、CQ 等对象，并实现内核态收发与 CQ 处理。

2026-10-20 20:43:45 232

原创 RDMA-Verbs-API 和数据结构（三）

libibverbs 向应用提供一套操作 RDMA 设备的 Verbs API。应用先打开设备，创建 PD、MR、CQ 和 QP，再用 WR 描述要提交的工作，用 SGE 指定本地数据范围，最后从 CQ 取得 WC，判断工作结果并回收缓冲区。公开 API 层、libibverbs 通用处理与分发层、provider 接口层。公开层包含动态库导出函数、头文件 inline 函数和宏适配入口。通用层处理参数适配、资源公共字段、操作表选择，以及事件计数和确认状态；

2026-10-20 20:43:12 390

原创 NCCL软件对象（概念）分析

对于图示的常规 kernel 路径，它选择 algorithm / protocol，分配 Channel / chunk，生成 ncclKernelPlan 和 work descriptors，并准备所需的 Proxy 操作。下面的示意图以 2 个 node、4 个 CUDA device、4 个 rank 为例，展示 NCCL 中各对象的归属关系、通信任务的提交过程，以及运行时的数据传输机制。图中的两个 Channel 使用不同的 Ring 顺序，并分别突出其负责的数据块。

2026-10-14 19:51:44 267

原创 NCCL架构分析

Simple、LL、LL128 定义经典路径中的 Payload、Flag 和进度处理方式，由 GPU Primitives 执行 Send、Recv、Reduce/Copy 等动作。根据 Topology、数据规模和硬件能力选择 Ring、Tree、PAT、NVLS、CollNet 等算法，并通过 Group/Enqueue、Tuning、Planner 和 Launch 组织 Channel、Chunk 与 Work。运行时层：维护资源、连接状态与通信进度。执行层：呈现计算、访存与互联硬件。

2026-10-13 11:47:31 252

原创 RDMA-HCA-Mellanox网卡队列 (三)

队列链路。QP、SRQ、CQ 和 EQ 构成 HCA 从执行工作到报告结果的完整链路。QPC 维护传输状态并关联发送与接收资源，SRQC 管理共享接收 WQE，CQC 管理完成记录，EQC 管理硬件事件及其中断路径。寻址与所有权。HCA 通过 QPN、SRQN、CQN 和 EQN 定位上下文，再结合页面映射、Key 和地址访问描述符及业务数据。各队列使用 counter 推进生产和消费位置，CQ 与 EQ 进一步通过 owner 交接环形槽位的所有权。通知层次。

2026-09-30 18:46:26 221

原创 RDMA-HCA-Mellanox网卡UAR与门铃 (二)

UAR 是 CPU 通过 MMIO 访问 HCA 的寄存器空间。在本文的 4 KiB 布局中，上半部包含 CQ Doorbell 和 EQ Doorbell，下半部包含四组 BF Register。普通 Send Doorbell 使用 BF Buffer 的起始 8 B；BlueFlame 从同一 Buffer 起始处直接写入 WQE 内容。CQ Doorbell 用于开启下一轮完成通知，EQ Doorbell 用于更新事件消费位置，并通过不同地址选择是否重新开启中断通知。

2026-09-30 18:44:55 355

原创 RDMA-HCA-Mellanox网卡架构与初始化 (一)

HCA 的管理入口是 Command Queue，运行资源由 ICM 页面和各类对象构成，数据入口则是队列缓冲区与 UAR。对象编号连接各类上下文，页面映射连接硬件对象和实际存储。初始化的关键依赖是命令通道、接口选择、页面供给和 HCA 激活。命令描述符通过所有权交接，多个槽位允许并发，存在依赖的命令仍需等待成功结果。关闭时，设备确认、页面归还和软件解除映射共同完成资源回收。

2026-09-30 18:44:05 422

原创 RDMA-HCA-Mellanox网卡地址转换与保护 (四)

HCA 用完整 MKey 选择并验证上下文，MKC 定义范围与保护属性，MTT 和 KLM 定义映射关系。三者共同决定一个地址能否访问，以及访问会落在哪个页面。MTT 按等大页计算索引，非对齐起点要计入首个页内偏移；KLM 按下层缓冲区组成地址空间，间接层数、生命周期和适用权限沿引用关系共同约束访问。UMR 使地址映射可以通过工作队列更新。Fence、操作完成、失效和对象销毁分别解决执行依赖、状态生效、授权撤销和资源回收。只有把硬件对象、在途访问和页面有效期统一管理，更新和释放才具有完整的接口语义。

2026-09-30 18:43:18 273

原创 ROCm 内存管理架构分析

本文梳理 Linux ROCm 内存管理的软件框架、内存模型和关键流程，说明内存请求如何由 HIP API 逐层传递至用户态运行时和内核驱动，并完成内存资源分配、GPU 虚拟地址映射和物理页面关联。分析范围覆盖 HIP Runtime API、Driver-style API、ROCclr/HAL、ROCr/Thunk，以及内核中的 KFD、AMDGPU、DRM/TTM、Linux MM 和 HMM。

2026-09-20 11:03:39 216

原创 NVSHMEM Memory Ordering和Synchronization分析

IBRC 的特点是控制路径经过 CPU Proxy，而 payload 数据仍由 RNIC 通过 GPUDirect RDMA 直接访问 GPU memory。Initiator GPU 把 NVSHMEM 请求交给 Host 侧 Proxy；CPU Proxy 再驱动本地 RNIC 发起 RDMA 操作。Target 侧 one-sided 数据访问通常由 RNIC 直接访问 GPU memory，不需要 Target CPU Proxy 参与。图 3：IBRC 的控制路径与数据路径。

2026-08-23 10:57:19 404

原创 IOMMU如何处理PCIe ATS/ATC/PRI Request

本文按每次访问实际采用的 Address Translation 路径无 ATS/ATC：设备直接发送 Untranslated DMA Request，由 IOMMU 实时完成 Address Translation；设备无须预先取得 ATS Translation。有 ATS/ATC，无 PRI：ATC 未命中后，设备先发送 ATS Translation Request，取得可用 Translation 后再发送 Translated DMA Request。有 ATS/ATC，有 PRI。

2026-07-18 17:17:59 446

原创 Linux DMA-BUF 软件框架分析

DMA-BUF 是 Linux 内核中跨设备、跨子系统共享缓冲区的通用框架。它解决的问题不是“如何分配一块内存”，而是“当一块内存已经由某个子系统拥有时，如何把它安全地交给其他设备或驱动访问”。在多媒体、显示、GPU、摄像头、视频编解码等场景中，同一帧图像或同一块数据经常需要在多个硬件模块之间流转。如果每个模块都复制一份，性能和内存占用都会很差。DMA-BUF 通过 fd 作为用户态句柄，通过作为内核对象，把 buffer 的所有权、映射、同步和生命周期统一起来。避免跨设备数据复制。

2026-07-14 21:31:16 529

原创 Linux Kernel 如何使用 PCIe ACS

PCIe ACS 解决的是“设备间 P2P TLP 是否必须回到上游路径”的问题。IOMMU 解决的是“DMA 地址如何翻译和保护”的问题。两者配合时，ACS 决定设备之间是否存在绕过 IOMMU 的 P2P 路径，IOMMU 据此决定哪些设备能被拆成独立的 IOMMU Group。PCI Core 在枚举 PCIe Topology 时发现并配置 ACS Control；IOMMU Core 不直接配置 ACS，而是读取 ACS path 的隔离结果来决定 IOMMU Group 边界；

2026-07-04 17:18:42 552

原创 PCIe ACS机制分析

ACS（Access Control Services）是在 PCIe 拓扑中设置的一组访问控制点，用来判断一个 TLP 应该正常路由或被阻断，还是被重定向到上游 Root Complex 处理。ACS 适用于 Root Complex、Switch 和 Multi-Function Device 中的相关 Function。从行为上看，ACS 不是单一开关，而是一组硬件能力和软件可配置控制位。

2026-07-04 12:14:35 638

原创 PCIe Transaction Ordering Rules

• 允许超越条件：I/O 或 Configuration Write Completion；且该完成包的 Completer ID 不同于前面已发布请求的 Requester ID。• No：相同 Transaction ID 的完成包不能超越，必须保持顺序。• Y/N：不同 Transaction ID 的完成包可以超越。• 允许超越条件：后发带数据的非发布请求的。• 允许超越条件：后发已发布请求的。• 允许超越条件：后发读请求的。或后发带数据的非发布请求的。

2026-06-23 15:43:06 246

原创 NVSHMEM 内存管理方案分析

NVSHMEM 的内存管理围绕 symmetric heap 展开。NVSHMEM 支持哪些 symmetric heap 类型，每种类型的特点是什么。如何初始化 symmetric heap。软件如何通过 NVSHMEM API 从 symmetric heap 分配和释放内存。symmetric heap 初始化出的元数据如何支撑后续通信路径。NVSHMEM 内存管理的核心是 symmetric heap offset 一致性。

2026-06-18 10:49:10 457

原创 CUDA 统一内存（Unified Memory）总结

CUDA Runtime API 中与 UM 相关的设备属性；基于这些属性抽象工程分类；CUDA 官方文档中的四种 Unified Memory 编程范式；、普通malloc()mmap()和内存的差异；HMM（Heterogeneous Memory Management）与 ATS（Address Translation Services）的区别；HMM 模式下 GMMU 与 IOMMU 的关系；

2026-06-08 15:41:24 443

原创 Scale-Up总线分析

Flit 原生总线和以太网增强方案会长期并存。前者更像“把远端 GPU 继续组织成本地可编程资源”，后者更像“把成熟以太网改造成足够好的 Scale-Up 事务传输层”。NVLink 已经证明了强语义总线在 AI 超节点中的价值；UALink 试图把这种能力开放化、标准化。SUE、ETH-X 和 EthLink 则试图把以太生态拉进 Scale-Up 域，以更低供应链门槛换取接近专用总线的效率。最终胜负不会只由链路速率决定，而会由端侧事务引擎、交换芯片、通信库、运行时、RAS 和可观测性共同决定。

2026-05-18 20:56:24 1082

空空如也

空空如也