loosp

为什么说 AllReduce = ReduceScatter + AllGather？——结合 NCCL Ring AllReduce

2026-09-10T02:00:00.000Z

为什么说 AllReduce = ReduceScatter + AllGather？——结合 NCCL Ring AllReduce

参考
NVIDIA NCCL Collective Operations：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html
Demystifying NCCL: An In-depth Analysis of GPU Communication Protocols and Algorithms, Fig. 4：https://arxiv.org/pdf/2507.04786

其实直接看https://arxiv.org/pdf/2507.04786的 fig.4就行了

NVIDIA NCCL 官方文档明确指出：

ReduceScatter 后执行 AllGather，在结果上等价于 AllReduce。

这个等式可以从两个层面理解：

语义上为什么等价
NCCL 的 Ring AllReduce 实际上怎样把这两个阶段做出来

1. 先从最终目标看

假设有 4 个 GPU，每个 GPU 上都有 4 个 chunk：

GPU0: [a0, a1, a2, a3]
GPU1: [b0, b1, b2, b3]
GPU2: [c0, c1, c2, c3]
GPU3: [d0, d1, d2, d3]

假设 reduction 操作是 SUM。

最终应该得到：

S0 = a0 + b0 + c0 + d0
S1 = a1 + b1 + c1 + d1
S2 = a2 + b2 + c2 + d2
S3 = a3 + b3 + c3 + d3

所以 AllReduce 的最终目标是：

GPU0: [S0, S1, S2, S3]
GPU1: [S0, S1, S2, S3]
GPU2: [S0, S1, S2, S3]
GPU3: [S0, S1, S2, S3]

注意这里其实包含两个不同的问题：

问题 1：怎样把 a0、b0、c0、d0 合成 S0，把 a1、b1、c1、d1 合成 S1，…… 这是 Reduce。

然后 问题 2：S0、S1、S2、S3 已经算出来以后，怎样让每一个 GPU 都拥有全部 S0~S3？这是 Gather / Dissemination。

因此可以自然地把 AllReduce 拆成：

            AllReduce

                │
        ┌───────┴───────┐
        │               │
        ▼               ▼
 ReduceScatter       AllGather

把结果算出来       把结果传播给所有 GPU
每个 GPU 留一块

2. ReduceScatter 做了什么？

ReduceScatter 并不是让每个 GPU 都立刻得到完整结果。

它做的是：

所有 GPU 的输入
       │
       ▼
    Reduce
       │
       ▼
[S0, S1, S2, S3]
       │
       │ Scatter
       ▼

最后变成类似：

GPU0: [S1]
GPU1: [S2]
GPU2: [S3]
GPU3: [S0]

具体哪个 rank 最后拥有哪个 chunk，取决于 Ring 的调度和 chunk 编号方式；关键不是编号，而是：

ReduceScatter 完成后，每一个最终 reduced chunk 已经被完整计算出来，但它们分散在不同 GPU 上。

也就是说：

完整逻辑结果：

[S0, S1, S2, S3]


物理分布：

GPU0        GPU1        GPU2        GPU3
 S1          S2          S3          S0

此时缺的已经不是 reduction——所有的 S0~S3 都已经算好了，缺的是：

“把这些 chunk 复制给其他 GPU。”

这正好就是 AllGather。

3. AllGather 接着做什么？

ReduceScatter 结束时：

GPU0: S1
GPU1: S2
GPU2: S3
GPU3: S0

执行 AllGather 后：

GPU0: [S0, S1, S2, S3]
GPU1: [S0, S1, S2, S3]
GPU2: [S0, S1, S2, S3]
GPU3: [S0, S1, S2, S3]

这已经和直接执行 AllReduce 的输出完全相同。

所以：

ReduceScatter
    │
    │ 先算出所有 reduced chunk
    │ 但每个 GPU 只保存其中一块
    ▼

GPU0: S1
GPU1: S2
GPU2: S3
GPU3: S0

    │
    │ AllGather
    ▼

GPU0: S0 S1 S2 S3
GPU1: S0 S1 S2 S3
GPU2: S0 S1 S2 S3
GPU3: S0 S1 S2 S3

因此：

AllReduce = ReduceScatter + AllGather

4. Ring AllReduce 是怎么实现这个过程的？

论文 Fig. 4 给出了 NCCL 在 4 个 GPU 上执行 Ring AllReduce 的具体过程。

假设 Ring 为：

GPU0 ──→ GPU1
 ↑         │
 │         ↓
GPU3 ←── GPU2

也就是：

1	GPU0 → GPU1 → GPU2 → GPU3 → GPU0

每个 GPU：

从左侧 / predecessor 接收数据
向右侧 / successor 发送数据

整个 Ring AllReduce 可以看成：

┌──────────────────────┐
│   ReduceScatter      │
│                      │
│ 数据一边绕 Ring      │
│ 一边做 reduction     │
└──────────┬───────────┘
           │
           ▼
   每个 GPU 得到一个
   完整 reduced chunk
           │
           ▼
┌──────────────────────┐
│      AllGather       │
│                      │
│ reduced chunk 继续   │
│ 沿 Ring 传播         │
└──────────┬───────────┘
           │
           ▼
 每个 GPU 得到全部 chunk

5. 第一阶段：Ring ReduceScatter

仍然使用：

GPU0: [a0, a1, a2, a3]
GPU1: [b0, b1, b2, b3]
GPU2: [c0, c1, c2, c3]
GPU3: [d0, d1, d2, d3]

Ring：

1	GPU0 → GPU1 → GPU2 → GPU3 → GPU0

Round 1

各 GPU 同时发送一个不同的 chunk：

GPU0: a0 ─────────→ GPU1
GPU1: b1 ─────────→ GPU2
GPU2: c2 ─────────→ GPU3
GPU3: d3 ─────────→ GPU0

接收方拿到以后，与自己的同编号 chunk 做 reduction：

GPU1:

a0 + b0

GPU2:

b1 + c1

GPU3:

c2 + d2

GPU0:

d3 + a3

因此现在 Ring 上出现了 4 个 partial sum：

chunk0: a0 + b0
chunk1: b1 + c1
chunk2: c2 + d2
chunk3: d3 + a3

Round 2

这些 partial sum 继续向下一个 GPU 传：

GPU1 ── (a0+b0) ──→ GPU2
GPU2 ── (b1+c1) ──→ GPU3
GPU3 ── (c2+d2) ──→ GPU0
GPU0 ── (d3+a3) ──→ GPU1

每个接收 GPU 再把自己的对应 chunk 加进去：

GPU2:

a0 + b0 + c0

GPU3:

b1 + c1 + d1

GPU0:

c2 + d2 + a2

GPU1:

d3 + a3 + b3

现在每个 partial sum 已经包含 3 个 GPU 的贡献。

Round 3

再向前传一次：

GPU2 ── (a0+b0+c0) ──→ GPU3
GPU3 ── (b1+c1+d1) ──→ GPU0
GPU0 ── (c2+d2+a2) ──→ GPU1
GPU1 ── (d3+a3+b3) ──→ GPU2

接收方加入自己的最后一部分：

GPU3:

a0+b0+c0+d0 = S0

GPU0:

a1+b1+c1+d1 = S1

GPU1:

a2+b2+c2+d2 = S2

GPU2:

a3+b3+c3+d3 = S3

于是 ReduceScatter 阶段完成：

GPU0: S1
GPU1: S2
GPU2: S3
GPU3: S0

最重要的一点是：

到这里 reduction 已经全部完成了，此时不需要再做任何加法。

6. 第二阶段：Ring AllGather

现在 Ring 中分散着：

GPU0: S1
GPU1: S2
GPU2: S3
GPU3: S0

接下来只需要把这些完整的 reduced chunk 沿 Ring 传播。

注意：

ReduceScatter 阶段：receive + reduce + send
而 AllGather 阶段：receive + copy + send，不再进行 reduce

AllGather Round 1

GPU0 ── S1 ──→ GPU1
GPU1 ── S2 ──→ GPU2
GPU2 ── S3 ──→ GPU3
GPU3 ── S0 ──→ GPU0

现在每个 GPU 有两个结果 chunk。例如：

1
2
3

GPU0:

S1 + S0

AllGather Round 2

刚收到的数据继续向下传：

GPU0 ── S0 ──→ GPU1
GPU1 ── S1 ──→ GPU2
GPU2 ── S2 ──→ GPU3
GPU3 ── S3 ──→ GPU0

此时每个 GPU 有三个结果 chunk。

AllGather Round 3

最后再传播一轮：

GPU0 → GPU1
GPU1 → GPU2
GPU2 → GPU3
GPU3 → GPU0

最终：

GPU0: [S0, S1, S2, S3]
GPU1: [S0, S1, S2, S3]
GPU2: [S0, S1, S2, S3]
GPU3: [S0, S1, S2, S3]

这就是完整的 AllReduce。

7. 用一张图看完整 Ring AllReduce

输入：

GPU0: a0 a1 a2 a3
GPU1: b0 b1 b2 b3
GPU2: c0 c1 c2 c3
GPU3: d0 d1 d2 d3

          │
          │
          ▼

=========================================
          ReduceScatter
=========================================

数据沿 Ring 流动：

GPU0 → GPU1 → GPU2 → GPU3 → GPU0

每经过一个 GPU：

partial_sum
     +
local_chunk
     ↓
new_partial_sum

经过足够多的 GPU 后：

GPU0: S1
GPU1: S2
GPU2: S3
GPU3: S0

其中：

S0 = a0+b0+c0+d0
S1 = a1+b1+c1+d1
S2 = a2+b2+c2+d2
S3 = a3+b3+c3+d3


          │
          │
          ▼

=========================================
             AllGather
=========================================

S0、S1、S2、S3 已经全部算好。

它们继续沿 Ring 传播：

GPU0 → GPU1 → GPU2 → GPU3 → GPU0

只：

recv + copy + send

不再 reduce。

          │
          ▼

GPU0: S0 S1 S2 S3
GPU1: S0 S1 S2 S3
GPU2: S0 S1 S2 S3
GPU3: S0 S1 S2 S3

所以：

                  AllReduce

                      │
         ┌────────────┴────────────┐
         │                         │
         ▼                         ▼

   ReduceScatter               AllGather

recv + reduce + send       recv + copy + send
         │                         │
         ▼                         ▼
每人得到一个完整结果块      每人得到所有结果块

         └────────────┬────────────┘
                      │
                      ▼

              完整 AllReduce 结果

8. Fig. 4 中 NCCL primitive 到底是什么意思？

论文没有只停留在”ReduceScatter + AllGather”这个抽象描述，而是进一步展示了 NCCL Ring AllReduce 内部使用的 primitive。

对于 k 个 GPU，论文 Table V 给出的一个 loop iteration 是：

Step 0:      send

Step 1 ~ k-2:   recvReduceSend

Step k-1:       recvReduceCopySend

Step k ~ 2k-3:  recvCopySend

Step 2k-2:      recv

对于 4 个 GPU：k = 4，因此是：

Step 0: send

Step 1: recvReduceSend
Step 2: recvReduceSend

Step 3: recvReduceCopySend

Step 4: recvCopySend
Step 5: recvCopySend

Step 6: recv

总共：

1
2
3

2k - 1
=
7 primitive steps

9. 这些 primitive 分别在干什么？

send

读取本地 chunk
      │
      ▼
发送给下一个 GPU

用于启动 Ring 中的数据流动。

recvReduceSend

这是 ReduceScatter 阶段最关键的 primitive：

从前一个 GPU 收数据
          │
          ▼
        recv
          │
          ▼
和自己的 local chunk 做 reduction
          │
          ▼
       reduce
          │
          ▼
把 partial result 发给下一个 GPU
          │
          ▼
        send

也就是：recv + reduce + send。数据每经过一个 GPU，就多融合一份输入。

recvReduceCopySend

这是 Fig. 4 里最值得注意的一步。它位于：

ReduceScatter
      ↓
    边界
      ↓
AllGather

这个 primitive 同时做：

recv
最后一次 reduce
copy 到自己的 output buffer
把已经完全 reduce 好的 chunk 发给下一张 GPU

也就是：

recv
   ↓
final reduce
   ↓
得到完整 Sx
   ├────────→ copy 到本地 output
   │
   └────────→ send 给下一 GPU

因此它实际上把两个阶段的边界连接起来了：

1
2
3

ReduceScatter 最后一步
        +
AllGather 第一次传播

recvCopySend

进入 AllGather 后已经没有 reduction，所以：

recv
 ↓
copy 到自己的 output buffer
 ↓
send 给下一 GPU

即：recv + copy + send。这里传播的是已经完整计算好的：

1	S0 / S1 / S2 / S3

recv

最后一块数据只需要接收并放到对应位置：

1
2
3

recv
 ↓
AllReduce 完成

此时所有 GPU 都拥有完整结果。

10. 为什么 Fig. 4 是 2k-1 个 step，而我们常说两个阶段各 k-1 轮？

这里非常容易混淆。

从算法语义 / 通信轮次理解 Ring AllReduce：

1 2	ReduceScatter : k - 1 rounds AllGather : k - 1 rounds

因此通常写成 2(k - 1) 个 Ring 通信轮次。

但 Fig. 4 分析的是 NCCL 内部 primitive 的执行序列。它把：

最开始的 send
最后的 recv

也分别列成 primitive step，并且在两个阶段的交界处使用 recvReduceCopySend，把 final reduction + copy + 下一阶段的 send 融合起来。

所以论文的 primitive 计数是：

1	1 + (k - 2) + 1 + (k - 2) + 1 = 2k - 1

这和 “ReduceScatter + AllGather” 并不矛盾——两者描述的粒度不同：

1
2
3

k-1 + k-1   描述：算法层面的 Ring rounds

2k-1        描述：Fig.4 中 NCCL primitive sequence

11. 所以”AllReduce = ReduceScatter + AllGather”应该怎么准确理解？

最准确的说法不是”NCCL 内部一定真的调用 ncclReduceScatter(...) 然后 ncclAllGather(...)“，而应该说：

从 collective 的数据语义来看，AllReduce 可以分解为 ReduceScatter 和 AllGather；Ring AllReduce 的实现也确实表现为前半段进行 ReduceScatter-like 的逐块归约，后半段进行 AllGather-like 的结果传播。

NCCL 的 Ring 实现会进一步做 primitive 融合（recvReduceCopySend），所以实际执行不是两个完全独立的 collective kernel 简单拼接。

可以理解为：

理论 / 语义：

AllReduce = ReduceScatter + AllGather

而 NCCL Ring 实现：

send
  ↓
recvReduceSend
  ↓
recvReduceSend
  ↓
recvReduceCopySend     ← 两阶段边界被融合
  ↓
recvCopySend
  ↓
recvCopySend
  ↓
recv

12. 为什么 Ring 要把数据切成 chunk？

如果整个 tensor 都由一个 GPU 收集并做 reduction：

1
2
3

GPU0 ← GPU1
GPU0 ← GPU2
GPU0 ← GPU3

GPU0 很容易成为瓶颈。

Ring 的做法是把 N 个元素切成 k 份：

Tensor:

┌──────┬──────┬──────┬──────┐
│ C0   │ C1   │ C2   │ C3   │
└──────┴──────┴──────┴──────┘

让所有 GPU 同时 send + recv + reduce：

GPU0 → GPU1
GPU1 → GPU2
GPU2 → GPU3
GPU3 → GPU0

四条链路可以同时工作。

因此不存在唯一的 reduction root，不同 chunk 的最终 reduction 分散到不同 GPU：

GPU0 负责一个 chunk
GPU1 负责一个 chunk
GPU2 负责一个 chunk
GPU3 负责一个 chunk

这正是 ReduceScatter 的含义。然后再利用同一个 Ring 做 AllGather。

13. Ring AllReduce 的通信量

假设每个 GPU 上的数据总量为 N bytes，一共有 k 个 GPU，每个 chunk 大约是 N/k。

ReduceScatter 有 k-1 轮，每一轮每个 GPU 发送一个 chunk：

1	ReduceScatter 每 GPU 发送量 = (k-1) × N/k = N(k-1)/k

AllGather 同样：

1	AllGather 每 GPU 发送量 = N(k-1)/k

因此 Ring AllReduce 每个 GPU 总发送量约为：

2N(k-1)/k

当 GPU 数量很大时，(k-1)/k ≈ 1，所以：

总发送量 ≈ 2N

这也是 Ring AllReduce 能较好利用链路带宽的重要原因之一：所有 GPU 都持续承担通信，而不是让一个 root 承担全部数据传输。

14. 最后总结

一句话：

ReduceScatter 负责”把每个结果 chunk 算完整”，AllGather 负责”让每个 GPU 都拿到这些已经算完整的 chunk”，两步接起来后，每个 GPU 都得到完整 reduction 结果，所以等价于 AllReduce。

结合 Fig. 4：

           Ring AllReduce

                │
                ▼

┌─────────────────────────────┐
│       ReduceScatter-like    │
│                             │
│ send                        │
│ recvReduceSend              │
│ recvReduceSend              │
│                             │
│ partial sum 不断沿 Ring     │
│ 流动并累加                   │
└──────────────┬──────────────┘
               │
               │ recvReduceCopySend
               │
               │ 最后一次 reduce
               │ + copy
               │ + send
               ▼
┌─────────────────────────────┐
│        AllGather-like       │
│                             │
│ recvCopySend                │
│ recvCopySend                │
│ recv                        │
│                             │
│ 完整 reduced chunk 沿 Ring  │
│ 传播，不再做 reduction       │
└──────────────┬──────────────┘
               │
               ▼

 每个 GPU 都得到完整 reduction result

所以最终可以记成：

AllReduce = ReduceScatter + AllGather

但在 NCCL Ring 的实际实现中，更准确地说是：

AllReduce = ReduceScatter-like reduction phase + AllGather-like dissemination phase

并且两阶段的边界通过 recvReduceCopySend 进行了融合。

RDMA 单边操作：QP、WR/WQE 与 RDMA WRITE / PUT 流程

2026-09-09T13:00:00.000Z

RDMA 单边操作：QP、WR/WQE 与 RDMA WRITE / PUT 流程

1. 什么叫单边 RDMA？

单边 RDMA（One-sided RDMA） 指的是：

发起方可以直接读写远端机器已经注册好的内存，而远端 CPU 不需要为这次数据传输主动执行 recv()、read() 或 write()。

典型的单边操作有：

RDMA WRITE：把本地内存的数据写到远端内存
RDMA READ：把远端内存的数据读到本地内存
Atomic：远端原子操作，例如 Compare-and-Swap、Fetch-and-Add

例如：

Host A                                      Host B

CPU / GPU                                   CPU
   │
   │ RDMA WRITE
   ▼
 RNIC A =================================> RNIC B
                                             │
                                             │ DMA
                                             ▼
                                      Remote Memory

假设 B 已经有一块内存：

1	0x70000000 ~ 0x70000fff

B 先把这块内存注册给 RNIC，并把：

1 2	remote_addr = 0x70000000 rkey = 0x123456

告诉 A。

之后 A 就可以发起：

1	RDMA WRITE

让自己的 RNIC 直接把数据写进：

1	B: 0x70000000

整个数据传输过程中：

1	B CPU 不需要调用 recv()

这就是所谓的 one-sided。

单边和双边的区别

双边操作典型是：

1	SEND / RECV

要求：

A:
post_send()

B:
post_recv()

也就是说双方都要参与。

流程类似：

A SQ                        B RQ

SEND WQE  ------------->   RECV WQE
                               │
                               ▼
                            B Buffer

而单边：

1
2
3

A SQ                      B Memory

RDMA WRITE WQE ---------> 直接写入

B 不需要为这一条 WRITE 提前放一个 Receive WQE。

所以：

1
2
3

SEND/RECV = two-sided

READ/WRITE = one-sided

2. 什么是 QP？

QP 全称：

1	Queue Pair

也就是：

一对 Work Queue。

一个 QP 最基本包含：

          QP

┌─────────────────────┐
│                     │
│   SQ          RQ    │
│                     │
│ Send Queue Receive  │
│            Queue    │
└─────────────────────┘

即：

1	QP = SQ + RQ

其中：

SQ：Send Queue

放主动发起的任务。

例如：

SEND
RDMA WRITE
RDMA READ
Atomic

这些 WR 最终都会进入 SQ。

RQ：Receive Queue

主要服务于：

1	SEND / RECV

例如 B 希望接收 A 发来的 SEND：

B 需要提前：

1	post_recv()

放一个 Receive WQE 到：

B.RQ

3. CQ 是什么？

除了 QP，还通常会有：

1 2	CQ Completion Queue

CQ 用来告诉软件：

某个 Work Request 完成了。

例如：

A CPU
 │
 │ ibv_post_send()
 ▼
A SQ
 │
 │
 ▼
RNIC
 │
 │ RDMA WRITE
 ▼
Network
 │
 ▼
B Memory

完成以后

A RNIC
 │
 ▼
A CQ
 │
 ▼
WC
Work Completion

CPU 可以：

1	ibv_poll_cq(...)

检查完成状态。

因此常见关系是：

        QP
 ┌──────────────┐
 │              │
SQ              RQ
 │              │
 └──────┬───────┘
        │
        ▼
        CQ

严格来说：

CQ 不属于 QP

而是 QP 在创建时指定自己的：

1 2	send_cq recv_cq

多个 QP 甚至可以共享一个 CQ。

4. 单边 RDMA 需要 RQ 吗？

这是一个非常重要的问题。

对于：

1 2	RDMA WRITE RDMA READ

数据传输本身不需要远端 RQ。

例如：

A                                   B

SQ                                  RQ
│                                   │
│ RDMA WRITE                         │
│                                   │
└───────────────> B memory           │
                                    X
                              不消费 Receive WQE

因此可以说：

RDMA WRITE / READ 不依赖远端 RQ 中的 Receive WQE。

但不能简单地说：

1	单边 RDMA 的 QP 没有 RQ

因为从 QP 结构上：

1	QP = SQ + RQ

RQ 仍然是 QP 的组成部分。

只是在纯单边通信场景下：

1	RQ 可以基本不用。

所以更准确的说法是：

单边 RDMA 操作仍然通过 QP 发起，但 RDMA READ/WRITE 不需要远端提前 post receive，因此远端 RQ 不参与这次数据搬运。

5. 单边 RDMA 是不是只需要 SQ + CQ？

从操作路径来看，可以近似理解成：

Local:

SQ
 │
 ▼
RNIC
 │
 ▼
Remote Memory

+
CQ 返回完成结果

因此对于纯 RDMA WRITE：

A SQ
A CQ

B 注册好的 Memory Region

基本就足够完成数据传输了。

不过还是要注意：

1 2	RQ 是 QP 的一部分，只是这次 RDMA WRITE 没有用它。

6. WR 和 WQE 是什么关系？

软件层面通常操作的是：

1 2	WR Work Request

例如 libibverbs 中：

1	struct ibv_send_wr

应用程序构造 WR：

WR
│
│ ibv_post_send()
▼
QP Send Queue
│
▼
WQE

可以简单理解为：

1
2
3

WR = 软件告诉 RDMA 驱动"我要做什么"

WQE = RNIC 真正能够读取和执行的队列项

概念上：

Application
    │
    │ WR
    ▼
libibverbs / Driver
    │
    ▼
   WQE
    │
    ▼
   SQ
    │
    ▼
  RNIC

7. 我要发一个 RDMA WRITE，WR 里要填什么？

假设：

1	A 要把自己的 buffer 写到 B 的 buffer。

基本需要两类信息：

1
2
3

本地信息
+
远端信息

7.1 本地信息

A 需要告诉 RNIC：

1
2
3

数据在哪？
数据多长？
这块内存是否有权限访问？

对应一个 SGE：

struct ibv_sge {
    uint64_t addr;
    uint32_t length;
    uint32_t lkey;
};

也就是：

1
2
3

addr
length
lkey

例如：

A local buffer:

addr   = 0x10000000
length = 4096
lkey   = 0xaaaa

含义：

addr

本地数据起始地址

length

传多少字节

lkey

RNIC 用来验证：

1	这个 QP 是否有权限 DMA 访问这块本地内存

8. 为什么要有 lkey？

因为不能让 RNIC 随便 DMA 任意虚拟地址。

应用需要先：

1	ibv_reg_mr(...)

Memory
   │
   │ ibv_reg_mr
   ▼
   MR
 ┌───────────┐
 │ addr      │
 │ length    │
 │ lkey      │
 │ rkey      │
 └───────────┘

其中：

lkey

主要用于本地 RNIC 访问本地 Memory Region。

9. RDMA WRITE 还需要远端信息

A 还必须知道：

1 2	B.remote_addr B.rkey

WR 中类似：

1 2	wr.wr.rdma.remote_addr = remote_addr; wr.wr.rdma.rkey = rkey;

因此：

RDMA WRITE WQE

┌─────────────────────────┐
│ opcode = RDMA_WRITE     │
│                         │
│ local_addr              │
│ local_length            │
│ local_lkey              │
│                         │
│ remote_addr             │
│ remote_rkey             │
└─────────────────────────┘

10. 还要填什么？

一个典型 Send WR 还会包含：

wr_id
opcode
send_flags
SGE

例如：

struct ibv_send_wr wr = {};

wr.wr_id      = 123;
wr.opcode     = IBV_WR_RDMA_WRITE;
wr.sg_list    = &sge;
wr.num_sge    = 1;
wr.send_flags = IBV_SEND_SIGNALED;

wr.wr.rdma.remote_addr = remote_addr;
wr.wr.rdma.rkey        = rkey;

因此可以总结成：

WR
│
├── 做什么？
│    └── opcode
│
├── 本地数据在哪？
│    ├── local_addr
│    ├── length
│    └── lkey
│
├── 远端写到哪？
│    ├── remote_addr
│    └── rkey
│
├── 完成以后怎么识别？
│    └── wr_id
│
└── 是否产生 CQE？
     └── send_flags

11. 接收方 B 要提供什么？

这是单边 RDMA 中最容易问到的问题。

对于 RDMA WRITE，B 最重要的是提供：

1 2	remote_addr rkey

通常流程是：

B:

malloc buffer
    │
    ▼
ibv_reg_mr()
    │
    ▼
得到 MR
    │
    ├── addr
    └── rkey

然后：

1 2	B ----------------------> A remote_addr + rkey

这种信息交换本身通常走：

TCP
RDMA SEND/RECV
RPC
控制面协议

而不是”凭空知道”。

12. B 要不要把 length 给 A？

从 RDMA WRITE WQE 本身来说：

A 写多少字节，是由 A 本地 SGE 中的 length 决定的。

因此 WQE 里的远端部分主要是：

1 2	remote_addr rkey

没有一个：

1	remote_length

字段。

但是实际协议里，B 通常仍然需要告诉 A：

1	这块 buffer 有多大。

例如：

B 告诉 A：

remote_addr = 0x70000000
rkey        = 1234
capacity    = 4096

这样 A 才知道不能写：

1	8192 bytes

否则可能越界。

所以需要区分：

硬件 WQE 必须字段：

remote_addr
rkey

和：

1
2
3

软件协议通常也会交换：

buffer length / capacity

13. 把 WR 转成一个具体例子

假设：

A local buffer:

0x10000000
4 KB

B remote buffer:

0x70000000
4 KB

A 有：

1
2
3

local_addr = 0x10000000
length     = 4096
lkey       = 0x1111

B 给 A：

1 2	remote_addr = 0x70000000 rkey = 0x2222

于是 A 创建：

                   RDMA WRITE WR

┌────────────────────────────────────────┐
│ opcode      = RDMA_WRITE              │
│                                        │
│ local addr  = 0x10000000              │
│ length      = 4096                    │
│ lkey        = 0x1111                  │
│                                        │
│ remote addr = 0x70000000              │
│ rkey        = 0x2222                  │
└────────────────────────────────────────┘

提交：

1	ibv_post_send(qp, &wr, &bad_wr);

14. RDMA WRITE 的完整流程

现在把 QP 加进来。

假设：

1 2	A = Initiator B = Target

Step 0：两边先建立 QP

两边都创建：

1
2

QP_A
QP_B

对于 RC：

1	Reliable Connected

需要建立：

1	QP_A <------------> QP_B

连接关系。

例如会交换：

1
2
3

QPN
PSN
LID / GID

等连接信息。

Step 1：B 注册远端内存

B CPU
 │
 ▼
malloc()
 │
 ▼
Buffer
 │
 ▼
ibv_reg_mr()
 │
 ▼
MR

得到：

1 2	addr = 0x70000000 rkey = 0x2222

Step 2：B 把远端信息告诉 A

控制面：

B                         A

remote_addr
rkey
buffer size
    -------------------->

至此 A 知道：

1	我要往 B 的哪里写。

15. Step 3：A 创建并提交 RDMA WRITE WR

A 构造：

WR

opcode      = RDMA_WRITE

local_addr
length
lkey

remote_addr
rkey

然后：

1	ibv_post_send(qp_A, &wr, ...);

逻辑上：

A Application
     │
     │ ibv_post_send()
     ▼
   QP_A.SQ
     │
     │ WQE
     ▼

WQE 被放进：

1	QP_A 的 Send Queue

16. Step 4：Doorbell

仅仅把 WQE 写进 SQ 还不够。

需要告诉 RNIC：

SQ 的 producer 状态更新了，有新的 WQE 可以执行。

于是 CPU 或 GPU 会：

1	ring doorbell

例如：

CPU
 │
 │ write doorbell
 ▼
RNIC

RNIC 于是知道：

1	QP_A.SQ 中出现了新的任务。

17. Step 5：A RNIC 获取 WQE

A RNIC
 │
 ▼
读取 QP_A.SQ
 │
 ▼
解析 WQE

发现：

1	opcode = RDMA_WRITE

并解析：

local_addr
length
lkey

remote_addr
rkey

18. Step 6：A RNIC DMA 读取本地内存

A RNIC 根据：

1	local_addr + lkey

访问：

A Memory

例如：

A Memory
0x10000000
     │
     │ PCIe DMA READ
     ▼
A RNIC

也就是说：

1	CPU 不负责 memcpy

数据由 RNIC DMA 取得。

19. Step 7：通过网络发给 B

RNIC 将数据封装成 RDMA 网络包：

A RNIC
   │
   │ RDMA WRITE packets
   ▼
Network
   │
   ▼
B RNIC

包里会包含足够的信息，让 B RNIC 找到目标 MR，例如：

1
2
3

remote virtual address
rkey
payload

20. Step 8：B RNIC 验证 rkey

B RNIC 收到以后：

B RNIC
 │
 ├── 检查 rkey
 │
 ├── 检查访问权限
 │
 └── 检查地址是否合法

例如确认：

1	0x70000000

确实属于对应 MR。

21. Step 9：B RNIC DMA 写入 B 内存

验证成功：

B RNIC
 │
 │ PCIe DMA WRITE
 ▼
B Memory

0x70000000

于是：

A buffer
0x10000000

        │
        │ RDMA WRITE
        ▼

B buffer
0x70000000

整个数据面过程中：

1 2	B CPU 没有调用 recv() B RQ 没有消费 WQE

22. Step 10：完成通知

对于可靠连接 RC，远端 RNIC 会按照协议完成可靠传输确认。

最终 A RNIC 可以在：

A CQ

中生成一个 CQE。

然后 A：

1	ibv_poll_cq(...)

得到：

1	Work Completion

于是知道：

1	这条 RDMA WRITE 已经完成。

完整路径：

              Host A                              Host B

Application
    │
    │ post_send
    ▼
 QP_A.SQ
    │
    │ WQE
    ▼
 RNIC A
    │
    │ DMA READ
    ▼
A Memory
    │
    │
    └────────────┐
                 │
                 ▼
              RNIC A
                 │
                 │ RDMA WRITE
                 │
=================│================================ Network
                 │
                 ▼
              RNIC B
                 │
                 │ check rkey
                 │ DMA WRITE
                 ▼
              B Memory


RNIC A
   │
   ▼
A CQ
   │
   ▼
Work Completion

注意：

1	B.RQ 完全没有出现在数据路径中。

23. 那么 PUT 是什么？

这里需要特别区分。

在标准 InfiniBand Verbs 中，通常使用的术语是：

1	IBV_WR_RDMA_WRITE

也就是：

1	RDMA WRITE

Verbs 本身并没有一个独立的 IBV_WR_PUT 操作。

但是很多上层通信模型中会使用：

PUT

这个词。

PUT 的语义通常是：

把本地数据放到远端指定地址。

也就是：

1	PUT(local_buffer, remote_buffer)

从语义来看：

1	PUT ≈ remote write

因此很多 RDMA 系统中：

PUT
    ↓
最终底层实现
    ↓
RDMA WRITE

例如：

Application

put(dst_remote, src_local, size)

        │
        ▼

Runtime / Communication Library

        │
        ▼

ibv_post_send()

opcode = IBV_WR_RDMA_WRITE

        │
        ▼

QP.SQ

所以如果讨论的是普通 RDMA/InfiniBand：

PUT 通常不是另一种硬件传输协议，而是上层 API 对”把数据写到远端”这一动作的称呼，底层通常映射为 RDMA WRITE。

24. RDMA WRITE 和 PUT 的 Step 3 分别是什么？

如果老师把：

WRITE

和：

PUT

分开讲，通常可以这样理解。

RDMA WRITE 的 Step 3

用户直接构造 RDMA WRITE WR：

Application
    │
    │ create WR
    ▼

opcode = RDMA_WRITE

local_addr
length
lkey

remote_addr
rkey

    │
    │ post_send
    ▼

QP.SQ

即：

发起方直接把一个 RDMA WRITE WQE 放入本地 QP 的 SQ，随后 ring doorbell，RNIC 消费该 WQE。

PUT 的 Step 3

如果 PUT 是一个上层 API：

1	put(remote_addr, local_addr, size)

那么 runtime 首先需要：

PUT
 │
 ▼
查找远端地址对应信息
 │
 ├── remote_addr
 └── rkey
 │
 ▼
构造 RDMA WRITE WR
 │
 ▼
post 到 QP.SQ

之后：

1	PUT 和 RDMA WRITE 的底层流程基本相同。

也就是说：

Application PUT
      │
      ▼
Runtime
      │
      │ translate
      ▼
RDMA WRITE WR
      │
      ▼
QP.SQ
      │
      ▼
RNIC

25. 从 QP 角度比较 WRITE 和 PUT

可以画成：

RDMA WRITE：

Application
    │
    │ ibv_post_send(RDMA_WRITE)
    ▼
 QP.SQ
    │
    ▼
 RNIC
    │
    ▼
Remote Memory

而 PUT：

Application
    │
    │ put()
    ▼
Runtime / Library
    │
    │ convert to RDMA WRITE
    ▼
 QP.SQ
    │
    ▼
 RNIC
    │
    ▼
Remote Memory

核心区别通常只在：

1	API / programming abstraction

而不是网络数据路径。

26. 单边 WRITE 时，两端 QP 分别在干什么？

这个问题值得单独说明。

假设：

1	QP_A <======== RC connection ========> QP_B

A 发 WRITE：

QP_A.SQ
  │
  │ RDMA WRITE WQE
  ▼
RNIC A

但是 B：

QP_B.RQ

没有 Receive WQE 被消费。

可以理解为：

             RC QP Connection

A QP                                  B QP

┌───────────────┐                ┌───────────────┐
│               │                │               │
│ SQ            │                │ SQ            │
│               │                │               │
│ WRITE WQE ----│--------------->│ RNIC handling │
│               │                │               │
│ RQ            │                │ RQ            │
│               │                │               │
│               │                │     unused    │
└───────────────┘                └───────────────┘
                                         │
                                         ▼
                                    B Memory

这里：

B QP

依然参与 RC 连接的协议状态，例如可靠性、packet sequence 等。

但：

B.RQ

不负责提供目标 buffer。

目标 buffer 来自：

1	remote_addr + rkey

27. 这和 SEND / RECV 最大区别在哪里？

SEND

A 只需要知道：

1	我要发送 local buffer

并不知道：

1	最终写到 B 的哪个具体虚拟地址

B 必须提前：

1	post_recv()

例如：

A                                 B

QP_A.SQ                            QP_B.RQ

SEND WQE -----------------------> RECV WQE
                                     │
                                     ▼
                                  Buffer

RDMA WRITE

A 明确知道：

1 2	B.remote_addr B.rkey

因此：

A                                 B

QP_A.SQ

RDMA WRITE WQE ----------------> registered MR
                                   0x70000000

QP_B.RQ
   X

所以二者最大的区别可以理解为：

SEND：

"B，你找一块提前准备好的 receive buffer 接住它。"

RDMA WRITE：

"B，我已经知道地址了，我直接写到 0x70000000。"

28. 最后总结

什么叫单边 RDMA？

单边 RDMA 是：

发起方 RNIC 可以直接访问远端已经注册并授权的内存，远端 CPU 不需要参与每一次数据搬运。

典型操作：

1
2
3

RDMA READ
RDMA WRITE
Atomic

什么是 QP？

1	QP = SQ + RQ

SQ：

主动发送任务
SEND
READ
WRITE
Atomic

RQ：

1	主要用于接收 SEND

单边 READ/WRITE：

1	不需要远端提前 post_recv()

因此：

1	远端 RQ 不参与数据搬运。

一个 RDMA WRITE WR 要有什么？

最核心的信息：

                 RDMA WRITE WR

       Local                         Remote

local_addr                       remote_addr
length                           rkey
lkey

              +
            opcode
            wr_id
          send_flags

即：

我要干什么？
WRITE

从哪里读取？
local_addr + lkey

读多少？
length

写到哪里？
remote_addr

有没有权限？
rkey

接收方要提供什么？

最核心：

1 2	remote_addr rkey

实际系统通常还会告诉：

1	buffer capacity

这些信息一般通过控制面提前交换。

RDMA WRITE 完整数据路径

A Application
      │
      │ WR
      ▼
A QP.SQ
      │
      │ WQE
      ▼
   Doorbell
      │
      ▼
A RNIC
      │
      │ DMA read
      ▼
A Memory
      │
      ▼
A RNIC
      │
      │ network
      ▼
B RNIC
      │
      │ check rkey
      │ DMA write
      ▼
B Memory

      B CPU 不参与
      B RQ 不参与

WRITE 和 PUT

在 InfiniBand Verbs 中：

1	RDMA WRITE

是真正的硬件 Work Request 类型。

而：

PUT

通常是上层编程模型中的语义：

PUT
 ↓
runtime
 ↓
RDMA WRITE WR
 ↓
QP.SQ
 ↓
RNIC
 ↓
Remote Memory

因此大多数情况下：

PUT 是”我要把这段数据放到远端”的 API 语义，而 RDMA WRITE 是底层真正执行这个动作的 RDMA Verb。

复习（占位）

2026-09-06T03:00:00.000Z

占位文章，防止分类为空；后续可删除或替换为真实的复习笔记。