RDMA操作类型

原文：https://zhuanlan.zhihu.com/p/142175657
作者：Mellanox（原文标注）
转载声明：本文欢迎非商业转载，转载请注明出处。

前面几篇涉及RDMA的通信流程时一直在讲SEND-RECV，然而它其实称不上是”RDMA”，只是一种加入了0拷贝和协议栈卸载的传统收发模型的”升级版”，这种操作类型没有完全发挥RDMA技术全部实力，常用于两端交换控制信息等场景。当涉及大量数据的收发时，更多使用的是两种RDMA独有的操作：WRITE和READ。

我们先来复习下双端操作——SEND和RECV，然后再对比介绍单端操作——WRITE和READ。

SEND & RECV

SEND和RECV是两种不同的操作类型，但是如果一端进行SEND操作，对端必须进行RECV操作，所以通常都把他们放到一起描述。

为什么称之为”双端操作”？ 因为完成一次通信过程需要两端CPU的参与，并且收端需要提前显式的下发WQE。

下图是一次SEND-RECV操作的过程示意图：

发送端APP                         接收端APP
    |                                |
    | ①下发SEND WQE                 |
    v                                |
发送端SQ                             |
    |                                |
    v                                v
发送端硬件 ---- ②取WQE ----> 接收端硬件
    |                                |
    | ③从内存取数据                  | ⑥提前下发RECV WQE
    |                                |
    v                                v
发送端网卡 ---- ④发送数据包 ----> 接收端网卡
    |                                |
    | ⑤解析数据并写入指定内存        |
    |                                |
    v                                v
发送端硬件 <--- ⑦ACK报文 ------ 接收端硬件
    |                                |
    | ⑧生成CQE                      | ⑪生成CQE
    |                                |
    v                                v
发送端APP                         接收端APP
    |                                |
    | ⑨轮询/中断取CQE               | ⑫轮询/中断取CQE

上一篇我们讲过，上层应用通过WQE（WR）来给硬件下任务。在SEND-RECV操作中，不止送端需要下发WQE，接收端也需要下发WQE来告诉硬件收到的数据需要放到哪个地址。发送端并不知道发送的数据会放到哪里，每次发送数据，接收端都要提前准备好接收Buffer，而接收端CPU自然会感知这一过程。

为了下文对比SEND/RECV与WRITE/READ的异同，我们将上一篇的SEND-RECV流程中补充内存读写这一环节：

步骤④：发送端硬件根据WQE从内存中取出数据封装成可在链路上传输数据包
步骤⑦：接收端硬件将数据包解析后根据WQE将数据放到指定内存区域

另外再次强调一下，收发端的步骤未必是图中这个顺序，比如步骤⑧⑪⑫和步骤⑨⑩的先后顺序就是不一定的。

WRITE

WRITE全称是RDMA WRITE操作，是本端主动写入远端内存的行为，除了准备阶段，远端CPU不需要参与，也不感知何时有数据写入、数据在何时接收完毕。所以这是一种单端操作。

通过下图我们对比一下WRITE和SEND-RECV操作的差异：

请求端APP (本端)                  响应端APP (远端)
    |                                |
    | [准备阶段] 获取key和addr       |
    | (通过SEND-RECV等操作)          |
    v                                v
    |<-------- 授权内存读写权限 ------->|
    |                                |
    | ①下发WRITE WQE                |
    | (包含远端虚拟地址+key)          |
    v                                v
请求端SQ                             |
    |                                | 
    v                                | (远端CPU不参与！)
请求端硬件 ---- ②取WQE              |
    |                                |
    | ③从本地内存取数据              |
    v                                v
请求端网卡 ---- ④发送数据包 ----> 响应端网卡
    |                                |
    |                                | ⑤解析并写入指定内存
    |                                | (虚拟地址->物理地址)
    v                                v
请求端网卡 <--- ⑥ACK报文 -------- 响应端网卡
    |                                |
    | ⑦生成CQE                      |
    |                                |
    v                                v
请求端APP                         响应端APP
    |                                |
    | ⑧取完成信息                   | (无感知！)

关键点：

本端在准备阶段通过数据交互，获取了对端某一片可用的内存的地址和”钥匙”（key），相当于获得了这片远端内存的读写权限
拿到权限之后，本端就可以像访问自己的内存一样直接对这一远端内存区域进行读写
这也是RDMA——远程直接地址访问的内涵所在

key和地址如何获取？

WRITE/READ操作中的目的地址和钥匙是如何获取的呢？

通常可以通过我们刚刚讲过的SEND-RECV操作来完成
因为拿到钥匙这个过程总归是要由远端内存的控制者——CPU允许的
虽然准备工作还比较复杂，但是一旦完成准备工作，RDMA就可以发挥其优势，对大量数据进行读写
一旦远端的CPU把内存授权给本端使用，它便不再会参与数据收发的过程，这就解放了远端CPU，也降低了通信的时延

需要注意的是：

本端是通过虚拟地址来读写远端内存的，上层应用可以非常方便的对其进行操作
实际的虚拟地址—物理地址的转换是由RDMA网卡完成的

WRITE操作流程

忽略准备阶段key和addr的获取过程，下面我们描述一次WRITE操作的流程：

请求端APP以WQE（WR）的形式下发一次WRITE任务
请求端硬件从SQ中取出WQE，解析信息
请求端网卡根据WQE中的虚拟地址，转换得到物理地址，然后从内存中拿到待发送数据，组装数据包
请求端网卡将数据包通过物理链路发送给响应端网卡
响应端收到数据包，解析目的虚拟地址，转换成本地物理地址，解析数据，将数据放置到指定内存区域
响应端回复ACK报文给请求端
请求端网卡收到ACK后，生成CQE，放置到CQ中
请求端APP取得任务完成信息

注：严谨地说，第6步回复ACK之时，RDMA网卡只能保证数据包中的Payload已经被”暂存”了下来，但不能保证一定已经把数据放到目的内存里面了。不过这一点不影响我们对整理流程的理解。

IB Spec. 9.7.5.1.6 ACKNOWLEDGE MESSAGE SCHEDULING原文： “For SEND or RDMA WRITE requests, an ACK may be scheduled before data is actually written into the responder’s memory. The ACK simply indicates that the data has successfully reached the fault domain of the responding node.”

READ

顾名思义，READ跟WRITE是相反的过程，是本端主动读取远端内存的行为。同WRITE一样，远端CPU不需要参与，也不感知数据在内存中被读取的过程。

获取key和虚拟地址的流程也跟WRITE没有区别，需要注意的是”读”这个动作所请求的数据，是在对端回复的报文中携带的。

下面描述一次READ操作的流程，注意跟WRITE只是方向和步骤顺序的差别：

请求端APP (本端)                  响应端APP (远端)
    |                                |
    | [准备阶段] 获取key和addr       |
    | (通过SEND-RECV等操作)          |
    v                                v
    |<-------- 授权内存读权限 -------->|
    |                                |
    | ①下发READ WQE                 |
    | (包含远端虚拟地址+key)          |
    v                                v
请求端SQ                             |
    |                                |
    v                                | (远端CPU不参与！)
请求端硬件 ---- ②取WQE              |
    |                                |
    v                                v
请求端网卡 ---- ③发送READ请求 ----> 响应端网卡
    |                                |
    |                                | ④从指定内存区域取数据
    |                                | (虚拟地址->物理地址)
    |                                v
    |                            响应端硬件
    |                                |
    v                                v
请求端网卡 <--- ⑤回复数据包 ----- 响应端网卡
    |                                |
    | ⑥解析数据并放入指定内存       |
    |                                |
    v                                v
请求端硬件                         响应端APP
    |                                |
    | ⑦生成CQE                      | (无感知！)
    |                                |
    v                                v
请求端APP                         响应端APP
    |                                |
    | ⑧取完成信息                   | (无感知！)

READ操作流程

请求端APP以WQE的形式下发一次READ任务
请求端网卡从SQ中取出WQE，解析信息
请求端网卡将READ请求包通过物理链路发送给响应端网卡
响应端收到数据包，解析目的虚拟地址，转换成本地物理地址，解析数据，从指定内存区域取出数据
响应端硬件将数据组装成回复数据包发送到物理链路
请求端硬件收到数据包，解析提取出数据后放到READ WQE指定的内存区域中
请求端网卡生成CQE，放置到CQ中
请求端APP取得任务完成信息

总结

抽象对比

我们忽略各种细节进行抽象，RDMA WRITE和READ操作就是在利用网卡完成下面左图的内存拷贝操作而已，只不过复制的过程是由RDMA网卡通过网络链路完成的；而本地内存拷贝则如下面右图所示由CPU通过总线完成的：

本地内存          远端内存              本地内存          本地内存
   |                 |                     |                 |
   |                 |                     |                 |
   |    RDMA WRITE   |                     |   本地memcpy    | 
   |<===============>|                     |<===============>|
   |                 |                     |                 |
   v                 v                     v                 v

语义区别

RDMA标准定义上述几种操作的时候使用的单词是非常贴切的：

操作类型	语义	对端CPU参与
SEND/RECV	“收”和”发”	需要两端主动参与
WRITE/READ	“读”和”写”	对端没有主动性，单端操作

使用场景对比

通过对比SEND/RECV和WRITE/READ操作，我们可以发现：

特性	SEND/RECV	WRITE/READ
对端CPU参与	需要	不需要（准备阶段除外）
优势	简单，类似socket	零CPU开销，低延迟
缺点	两端都需要CPU参与	需要准备阶段获取权限
适用场景	控制信息交换	大量数据传输
是否为真RDMA	否（升级版socket）	是（远程直接内存访问）

结论：

传输数据时不需要响应端CPU参与的WRITE/READ有更大的优势
缺点就是请求端需要在准备阶段获得响应端的一段内存的读写权限
但是实际数据传输时，这个准备阶段的功率和时间损耗都是可以忽略不计的
所以RDMA WRITE/READ才是大量传输数据时所应用的操作类型
SEND/RECV通常只是用来传输一些控制信息

后续内容

除了本文介绍的几种操作之外，还有ATOMIC等更复杂一些的操作类型，将在后面的协议解读部分详细分析。

下一篇将介绍RDMA基本服务类型。

参考

[1] RDMA Aware Networks Programming User Manual, Mellanox Technologies

本站所有文章转发 CSDN 将按侵权追究法律责任，其它情况随意。