23. RDMA之基于CM API的QP间建链

30 篇文章 12 订阅

转自:https://zhuanlan.zhihu.com/p/494826608

我们在前面的文章“RDMA之基于Socket API的QP间建链”中介绍了RDMA Queue Pair间基于Socket API的建链方式。Socket API学习成本低,使用也很方便,但是对于使用Infiniband协议的节点来说,这是一种“带外”的建链方式。所谓“带外”,指的区别于数据传输通道的另外一条传输通道。用人话讲,就是使用Infiniband协议的节点,需要TCP/IP协议的支持,才能使用Socket进行建链。这就要求节点使用的Infiniband网卡支持TCP/IP,或者部署有另外一块传统以太网卡。

那么有没有Infiniband协议的网卡可以直接使用的QP间建链方式呢?有,那就是大名鼎鼎的CM。CM是RDMA技术中专门用来在QP之间建立连接的机制,它有一套专属的报文格式、交互流程和用户接口。

之前有很多读者都问过关于CM的问题,标准文档比较晦涩,网上资料也比较少。而在本文中,我将对CM进行一次全方位科普。介绍其概念、目的、使用场景、交互流程以及实现原理,关于报文格式、编程方法等更多细节,请读者期待后续的文章。

概述

CM这一缩写有多重含义,它既可以指协议,也可以指RDMA网络中的一个管理角色,还可以指编程接口(API)。

通信管理协议

CM在作为协议时的全称为Communication Management Protocol,即通信管理协议。它指的是一种建立于Infiniband/RoCE协议基础之上的建链方式。

类似于TCP协议的“三次握手”,CM协议也是通过报文的多次往返来建立连接的,同时它也规定了断链的方式。

通信管理器

CM作为Infiniband/RoCE通信系统中的角色时,全称为Communication Manager,即通信管理器。这是一个比较抽象的概念,它的作用是建立和维护两个节点间的连接。虽然抽象,但是它是有“实体”的,RDMA软件协议栈中实现了CM管理器的功能

CM编程接口

CM作为Infiniband/RoCE/iWARP的用户编程接口时,全称也是Communication Manager,即通信管理接口。CM接口之于CM协议,就如Socket接口之于TCP协议,其调用流程也和Socket非常相似,我们也可以说,CM API是基于RDMA而非传统以太网实现的类Socket接口。

我们来总结一下,上面几个概念的关系是:用户通过调用CM编程接口,控制CM通信管理器发出和接收CM协议的报文。它们的关系如下图所示:

CM相关概念间的关系

它们经常被当成一个整体提及,即使单指其中一项时也比较容易识别,因此本文的剩余部分中,我不会特别区分这几个概念。


为什么需要CM

最主要的原因我其实已经在本文的最开始做出了解释——因为Infiniband协议没有Socket这种通道来在双方交换业务数据前传递必要的信息,比如QPN、Virtual Address和Remote Key等等。它需要一种不依赖于以太网的QP间建联方式,所以会有CM协议和通信管理器的存在。

建链作为一个由用户发起和中止的动作,自然也需要用户的编程接口来对其进行控制,因此就需要定制出CM API。

CM诞生于RoCE之前。RoCE v1和v2协议中都使用了Infiniband协议的传输层,而CM是基于Infiniband传输层实现的,因此RoCE v1/v2自产生开始就天然支持CM建链。而又因为RoCE底层是基于以太网的,一般支持RoCE v2的网卡都会支持TCP/IP协议,因此大多数RoCE网卡都可以支持Socket和CM两种建链方式。

iWARP的情况比较特殊。iWARP自成体系,它通过IETF的RFC 5044和RFC 6581(详情见“iWARP”一文)对于建链方式做出了规定。iWARP的做法是规定了一套基于在TCP之上的MPA层的交互流程,与CM协议毫不相关。并且由于在TCP层上面加了一层,往往由各个厂商自己在驱动程序中进行差异化实现,所以也无法使用标准Socket API

iWARP后来逐渐和Infiniband/RoCE统一了软件接口和软件栈,这其中就包括CM API。它虽然使用着CM API,但是底层还是按照其RFC中的规定所实现的。


协议分层

我们在之前的文章“Verbs”中讲解过Verbs接口,它作为目前最主流的RDMA API,对用户隐藏了下层协议的细节。从Verbs API看RDMA各个协议的分层关系是下图这个样子:

Verbs API视角的协议层次

各种协议的分层差异我们在专栏之前的文章中有涉及过,就不在本文展开了。注意对于一般的RDMA网卡来说,上图中Verbs API下面的所有协议层次,都是硬件实现的

CM API的目的跟Verbs一样,它定义了一套Infiniband/RoCE/iWARP协议通用的建链接口,对用户隐藏了底层差异。从CM API看,协议分层是下图这样:

CM API视角的协议层次

除了分层关系,跟上面Verbs的协议分层图另一个比较大的差异是,对于RoCE/Infiniband来说,CM和MAD层是软件实现的;对于iWARP来说,建链时使用的MPA及以下各层,也是软件实现的

下面我们来简单讲一下上图中还没有涉及过的几个层次:

MPA层

MPA层的全称是Marker PDU Aligned framing,它是iWARP协议族的最底层,向下基于TCP层,向上为DDP层提供服务。我们在“MPA”一文中对它的功能做了详细的介绍,其中就包括建链部分的报文和流程分析,感兴趣的读者可以去继续了解。

MAD层

MAD全称为Management Datagram,即管理数据报。我们在“RDMA基本服务类型”一文中讲过,数据报是面向连接的反义词,就是通信双方不需要建立连接。我们很容易联想到UD服务类型的全称是不可靠数据报,其实MAD层就是基于IB传输层的UD服务类型实现的。也就是说,它在UD服务类型的报文的基础上,利用其Payload部分又实现了一层协议。

协议视角

MAD层通常不直接向用户提供功能,它主要作为中间层向上支持GS(General Services)和SM(Subnet Management)两种服务。SM只用于Infiniband网络,我也不了解,咱们暂且不提。General Service包括性能管理、设备管理、应用管理以及本文的主角——CM连接管理。

之前在“Queue Pair”一文中我曾经提到过两个特殊的保留QP——QP0以及QP1。这两个QP之所以特殊,是因为它们是专门用于收发MAD层管理报文的。QP0和QP1由内核协议栈创建,无法被用户直接使用。其在软件协议栈中的QP类型分别为SMI(Subnet Management Interface)和GSI(General Services Interface),但是实际上就是UD类型的QP,只是因为其特殊的权限,所以取了两个专有的类型名。

我们来思考一下,为什么MAD使用的是UD,而不是RC呢?UD服务类型最大的特点便是可以把报文发送给任意节点,也可以接收来自任何节点的报文(当然也要保证合法性)。对于CM这种需要试探性地收发、收发频率低、无需保证可靠性的报文,UD自然称为了首选。所有的节点只需要建立一个专门用于CM的UD(GSI) QP,就可以和所有其他任意节点间进行建链的交互。试想如果用RC来实现,每一对CM连接都需要独立的RC QP,这在复杂组网情况下将消耗大量的内存资源,而且两端也很难协商到底用哪个QPN收发MAD报文。

我们在“Socket建链”一文中讲到,UD QP之间通信,至少要知道对端的QPN和Queue Key,只有对端校验通过后才会接收我们的报文。MAD如何解决这个问题呢?非常简单,所有的GSI QP都必须使用相同的QPN,即QP1;以及相同的Queue Key——特殊的值0x8001_0000。而最高位为1的Queue Key都是特权Key,普通的用户无法使用,这也就保证了CM只能由内核态协议栈来管理。

软件视角

MAD层除了处理自己这一层的报文之外,还对Infiniband/RoCE协议的CM层提供了RDMA资源上的支持,包括PD、MR、QP、CQ等等,是CM层的基础。

MAD层的细节我们不在本文展开,以后有空给大家讲。

CM层

协议视角

顾名思义,这一层自然指的是CM协议,细节我们在后面的小节介绍。

软件视角

软件层面的CM层包含两个功能,一方面负责为用户提供类似Verbs API的CM API,并处理用户对API的调用。另一方面根据网卡使用的协议来组装或者解析报文。

发送方向上,如果是RoCE/Infiniband协议,则CM层会负责组装CM协议报文,并下送给MAD层做进一步处理,最后通过GSI QP发送建链报文;如果是iWARP协议,则它会调用各个厂商注册的回调函数组装MPA层的报文,厂商的驱动最终会调用Socket接口,由内核协议栈继续组装TCP/IP层的报文并发送。

接收方向上,CM层也负责使用RoCE/Infiniband时MAD+CM协议的报文解析,或者在使用iWARP协议时,调用网卡驱动注册的回调函数对MPA报文进行解析。

我们以一个基于RoCE v2的CM报文为例,它的结构如下图所示:

CM报文层次示意图


CM协议

下面我们介绍用于Infiniband/RoCE设备的CM协议。CM协议中,RC和UD服务类型使用的是不同的报文和交互流程,主要差异点在于,因为RC是面向连接的,所以其建链过程中也必须经历建立连接——数据交互——断开连接的过程;而UD无连接,所以双方在获得必要的信息后,就可以进行数据交互了,最后也不用断开连接。

RC QP建链

RC QP的CM建链和断链流程和TCP非常相似,如下图所示,建链是一个“三次握手”的流程:

RC QP间的CM建链流程

RC QP的CM建链报文交互(参考自IB Specification Release 1.4 Figure 132)

  1. 首先Client端要发起一个REQ(Request)消息,表示一个连接请求,消息的报文中携带有连接参数,比如本端要连接的QP的QPN(这个QP是在CM建链流程中通过CM API创建的,下文会介绍)、起始PSN、重传次数上限等等。另外也可以跟iWARP的MPA建链一样携带一些自定义的Private Data,用于满足用户的定制化需求。
  2. Server端在Client端发起连接请求前就一直处于监听状态,当它监听到连接请求后,CM层会对连接参数进行校验和记录,而Private Data会被上送给用户进行校验。校验通过后,Server端会发送REP(Reply)消息,表示接受之前的连接请求,并且在消息报文中携带自己的连接参数——包括QPN、起始PSN等等。REP报文也可以携带自定义的Private Data。
  3. Client端收到REP消息后,将对其中的内容进行校验和记录,然后发送一个RTU(Ready To Use)消息,表示同意你的参数,可以利用双方约定好的QP进行数据交互了。

如上图所示,Client端在发出RTU消息之后就可以发送数据了,而Server端在接收到RTU消息后才可以发送数据。

上述过程中,如果任意一个校验过程中检出了错误,则会回复给对端一个REJ(Reject)消息,终止本次连接流程,消息报文中会携带拒绝连接的原因。

RC QP断链

RC QP的断链一般是一个“四次挥手“的过程。关于断链的过程,IB规范并没有规定两端谁先发起、后发的一方是否要先回复Reply后再发送Request等细节,下图中的例子只是一种可能的情况:

RC QP间的CM断链流程

  1. 首先Client端发送DREQ(Disconnect Request)消息,表示自己想要断开某个连接,消息中携带着指定连接的ID以及QPN等信息。这个过程也可以携带Private Data,用于定制化功能。
  2. Server端收到DREQ消息并校验通过后,回复一个DREP(Disconnect Reply)消息,表示同意断链请求。
  3. Server端发送DREQ消息,同1。
  4. Client端收到DREQ消息,校验通过后回复DREP,同2。

上图中Client端和Server端收到对端回复的DREP消息后,就可以销毁跟对端有关的CM软硬件资源了。

UD QP建链

UD QP的CM建链流程相对于RC要简单,主要原因自然是UD服务类型不用建立连接,也不需要保证可靠性,对端收不收的到无所谓。由上层应用的逻辑保证建链的完成,比如Client端可以在一定时间内没收到Reply就重发Request。这个过程下图所示:

UD QP间的CM建链流程

首先需要解释一个名词——SIDR,全称为Service ID Resolution Protocol,大家别被又一个Protocol吓到,它的过程非常简单:

  1. Client端发送请求消息SIDR_REQ(SIDR Request),其中会携带一个Service ID字段,表明它需要Server端提供的服务。这个过程中也可以携带Private Data用于定制化实现。
  2. Server端收到SIDR_REQ消息后,会对请求进行校验。校验通过后,在回复消息SIDR_REP(SIDR Reply)中会携带一个和Service ID对应的可用QP的QPN以及Queue Key,此后Client就可以以它为目的QP发送数据给Server。这个过程中也可以携带Private Data。

Client端收到Server发出的回复后,就可以从报文中获取对端可以用来接收消息的QPN和Q_Key了,至此SIDR的标准交互流程就结束了。至于Service ID和QPN的对应关系,IB规范中并没有做出规定,这个可以由用户应用程序自行决定。

细心的读者可能会发现,这个流程中Server端好像不知道Client端的QPN。

这是因为作为被动一方的Server端并不一定要知道Client端的QPN。如果Server端也有向Client端发送消息的需求的话,才需要通过其他方式获得Client端的信息。具体的实现由用户决定,比如Client端可以在首个Send报文的Payload部分就携带本端的QPN、Q_Key等信息;也可以通过在Send with immediate消息中携带立即数,这个立即数即为Client端的QPN或者Q_Key。

CM报文交互的内容很多,我们不在本文中展开,以后有时间再单独讲。感兴趣的读者可以结合文末的实验和IB Specification的第12章自行学习。

另外请大家一定注意:整个CM建链过程中出现了两个QP,一个是用于处理CM和MAD报文的GSI(UD)类型的QP,一个是建链之后两端具备的一对相互之间可以发送Send消息的QP。用户无法使用GSI QP来传递业务消息,只能使用后者。

另外对于RC QP来说,此时两端并未掌握对端的Virtual Address和Remote Key。所以如果要进行RDMA Write/Read操作,还需要通过这一对QP间Send消息来传递VA和R_Key。这个过程也是由用户自己决定如何实现的。

实验

好了,下面我们来做个试验。本次实验中,我们将分别通过Soft-RoCE和Soft-iWARP设备来观察CM建链的报文。

准备工作

虚拟机环境及其配置过程同“RoCE & Soft-RoCE”和“iWARP & Soft-iWARP”两篇文章。

本次执行的示例程序是rdma_server/client,以及udaddy。它们的源码都位于rdma-core仓库的librdmacm/examples目录下。如果按照“RoCE & Soft-RoCE”一文的步骤安装了用户态动态链接库的几个软件包,那么是可以直接执行这三个可执行程序的。

rdma_server/rdma_client

它们是配对执行的两个示例应用程序,使用RC服务类型,在两端通过调用CM API实现了“建链——数据交互——断链”的过程,数据交互使用的是Send操作类型。

udaddy

这是个UD QP的CM建链示例应用程序,在两端的UD QP之间通过CM建链后进行Send操作类型的数据交互。

抓包

Wireshark抓包的配置步骤不再赘述,请大家参考“RoCE & Soft-RoCE”一文。

RoCE v2 RC

我们首先来看一下RoCE v2的RC QP间的CM建链,该实验中用到的是Soft-RoCE(RXE)设备。

Server端执行:

rdma_server

Client端执行:

rdma_client -s 192.168.217.128

下图是抓包的结果,可以看到分成了三个部分:完成CM建链之后,利用建链好的RC QP,做了一次ping-pong操作,最后进行了断链。

RoCE v2 RC QP CM抓包结果

我们打开26号报文,可以看到Request报文的分层关系,也可以看到CM报文中的QPN等信息:

CM REQ报文

27号是Reply报文,从中也可以看到CM层的报文里有QPN等信息:

CM REP报文

总结一下,上面的整个流程如下图所示,整个通信流程都是通过RoCE v2报文完成的。对比“Socket建链”文末中Socket建链的报文交互图,相信读者可以更好的理解本文最开始提到的Socket建链对于RoCE/Infiniband协议来说是一种“带外”的方式的含义。

基于CM建链的RoCE v2报文交互流程

RoCE v2 UD

然后我们继续使用相同的Soft-RoCE设备抓取RoCE v2 UD QP的CM建链报文。

Server端执行:

udaddy

Client端执行:

udaddy -s 192.168.217.128

报文如下图所示,可以看到SIDR协议交互之后,就进行了数据交互,数据交互使用的是Send with Immediate操作类型,即带立即数的Send。如果展开报文的话,会发现这个立即数就是QPN。

RoCE v2 UD QP CM抓包结果及SIDR_REQ报文

上图中我们顺便也展开了443号报文,这是一个SIDR_REQ消息,wireshark当前并不支持对其的解析,所以我们只能对照IB规范来解析其内容了。SIDR_REP也是一样,我就不贴图了。

iWARP RC

我们卸载Soft-RoCE设备并加载Soft-iWARP设备,并执行rdma_server和rdma_client,就可以观察到iWARP协议的CM建链报文了。

可以看到明显的分成了四个部分:TCP建链、MPA建链、数据交互和TCP断链。MPA的内容我们在“MPA”一文中有介绍,此处不再展开讲了。

iWARP RC QP CM建链抓包结果

通过对Soft-RoCE和Soft-iWARP的RC QP的CM建链实验我们可以发现,同样的程序,不需要修改就可以跑在两种协议类型的设备上,这就是CM API作为统一的RDMA CM建链接口的最大价值所在。

除了上面的应用程序外,RDMA Write/Read操作类型也有对应的示例,比如rping,感兴趣的读者可以自己执行并抓包。

好了,本文对于CM建链就科普到这里,下一篇将给大家介绍CM API的使用。

参考内容

  1. Connection Queue Pairs. RDMAmojo. Connecting Queue Pairs - RDMAmojo RDMAmojo
  2. IB Specification. Chapter 12 Communitcation Management. IBTA
  3. IB Specification. 13.4 Management Datagrams. IBTA
  4. rdma_cm(7). Linux man page. rdma_cm(7): RDMA communication manager - Linux man page (die.net)
  5. rdma_client(1). Linux man page. rdma_client(1) - Linux man page (die.net)
  6. rdma_server(1). Linux man page. rdma_server(1) - Linux man page (die.net)
  7. udaddy(1). Linux man page. udaddy(1) - Linux man page (die.net)

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
第1章 RDMA背景简介 ............................................. 5 第2章 哪些网络协议支持RDMA ..................................... 8 2.1 InfiniBand(IB)........................................... 8 2.2 RDMA过融合以太网(RoCE)................................... 8 2.3 互联网广域RDMA协议(iWARP)................................ 8 第3章 RDMA技术优势 ............................................. 9 第4章 RDMA有哪些不同实现 ...................................... 10 第5章 RDMA有哪些标准组织 ...................................... 14 第6章 应用和RNIC传输接口层 .................................... 18 6.1 内存Verbs(Memory Verbs)............................... 19 6.2 消息Verbs(Messaging Verbs)............................ 20 第7章 RDMA传输分类方式 ........................................ 20 7.1 RDMA原语................................................ 21 7.2 RDMA 队列对(QP)....................................... 23 7.3 RDMA完成事件............................................ 23 7.4 RDMA传输类型............................................ 24 7.5 RDMA双边操作解析........................................ 26 7.6 RDMA单边操作解析........................................ 27 7.7 RDMA技术简单总结........................................ 27 第8章 InfiniBand技术和协议架构分析 ............................ 29 8.1 InfiniBand技术的发展.................................... 29 8.2 InfiniBand技术的优势.................................... 30 8.3 InfiniBand基本概念...................................... 32 8.4 InfiniBand协议简介...................................... 33 8.4.1 物理层 ............................................ 34 8.4.2 链路层 ............................................ 34 8.4.3 网络层 ............................................ 34 8.4.4 传输层 ............................................ 35 8.4.5 上层协议 .......................................... 35 8.5 IB应用场景.............................................. 36 第9章 InfiniBand主流厂商和产品分析 ............................ 37 9.1 InfiniBand网络和拓扑.................................... 38 9.2 软件协议栈OFED.......................................... 42 9.3 InfiniBand网络管理...................................... 43 9.4 并行计算集群能力........................................ 44 9.5 基于socket网络应用能力.................................. 45 9.6 存储支持能力............................................ 45 9.7 Mellanox产品介绍........................................ 46 9.8 Infiniband交换机........................................ 48 9.9 InfiniBand适配器........................................ 51 9.10 Infiniband路由器和网关设备............................. 52 9.11 Infiniband线缆和收发器................................. 53 9.12 InfiniBand主要构件总结................................. 54 9.13 InfiniBand对现有应用的支持和ULPs支持................... 55 第10章 RDMA over TCP(iWARP)协议和工作原理 ..................... 56 10.1 RDMA相关简介........................................... 57 10.2 RDMA工作原理........................................... 59 10.3 RDMA 操作类型.......................................... 61 10.4 RDMA over TCP详解...................................... 61 10.5 RDMA标准组织............................................ 7 第11章 RoCE(RDMA over Converged Ethernet)原理 ............... 65 第12章 不同RDMA技术的比较 ..................................... 67 12.1 IB和TCP、Ethernet比较.................................. 69 12.2 RoCE和InfiniBand比较................................... 70 12.3 RoCE和IB协议的技术区别................................. 71 12.4 RoCE和iWARP的区别...................................... 71 第13章 Intel Omni-Path和InfiniBand对比分析 .................... 72 13.1 Intel True Scale Fabric介绍............................ 73 13.2 Intel True Scale InfiniBand产品........................ 74 13.3 Intel Omni-Path产品.................................... 76 第14章 RDMA关键技术延伸 ....................................... 80 14.1 RDMA指令的选择......................................... 80 14.2 慎用atomic类指令....................................... 81 14.3 减少交互次数........................................... 82 14.3.1 Wr 聚合 .......................................... 82 14.3.2 SGE 聚合 ......................................... 82 14.3.3 使用imm数据 ...................................... 83 14.3.4 使用inline数据 ................................... 83 14.3.5 CQE中使用inline数据 .............................. 83 14.3.6 WC聚合 ........................................... 84 14.4 运行模式选择........................................... 84 14.4.1 连接的模式 ....................................... 84 14.4.2 运行模式 ......................................... 85 14.5 性能与并发............................................. 86 14.6 避免CPU缓存抖动........................................ 87 14.7 避免芯片内部的缓存Miss................................. 87 14.8 时延的隐藏............................................. 88 14.8.1 利用Prefetch预取指令 ............................. 88 14.8.2 异步交互操作优先 ................................. 88 14.9 RDMA性能分析........................................... 89

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值