参考IB协议版本V1.4：https://download.csdn.net/download/zz2633105/88148107

参考知乎文章《RDMA基本服务类型》：https://zhuanlan.zhihu.com/p/144099636

可靠服务

何为可靠服务呢，引用IB协议中的原话（IB V1.4版本9.7章节）。

Reliable Service provides a guarantee that messages are delivered from a requester to a responder at most once, in order and without corruption.Key elements of the reliable service include a protection scheme to enable detection of corrupted data (CRC), an acknowledgment mechanism allowing the requester to ascertain that the message had been successfully delivered, a packet numbering mechanism to detect missing packets and to allow the requester to correlate responses with requests, and a timer to allow detection of dropped or missing acknowledgment messages.

可靠服务保证消息最多一次从请求端传递到响应端，而且是有序且不损坏的。可靠服务的关键要素包括:启用检测损坏数据(CRC)的保护方案、允许请求者确定消息已成功传递的确认机制（ACK/NAK）、用于检测丢失数据包并允许请求者将响应与请求相关联的数据包编号机制（PSN），以及用于检测丢失或丢失确认消息的计时器。

可靠服务提供了一种保证，即消息从请求方传递到响应方最多传递一次，按顺序传递，并且不会被损坏。

这种保证依赖于三个机制：

• CRC机制
• 确认机制
• PSN机制

可靠服务依赖机制

CRC机制

CRC全称为Cyclic Redundancy Check，该算法通过对传输的数据进行多项式计算来生成一个校验和，校验和可以用于检测数据是否在传输过程中被损坏或篡改。如果数据损坏或篡改，接收方可以通过校验和的不匹配来检测错误，并请求重传。

简单来说就是，发送端会将Header和Payload经过算法得到一个校验值放到尾部（ICRC），然后接收端也会使用相同算法出校验值与发送端放到数据包尾部的校验值比较，如果结果不一致，则接收端这边会静默丢弃这个数据包，不会告知上层app，也不会给发送端任何反馈。

确认机制

对于可靠服务，IB协议要求每个发送出来的数据包，都必须得到显式或隐式的确认。如下图所示。

显式确认：请求端发送请求报文 r1 发送到响应端；响应端处理完成后返回确认报文 a1 给请求端显式确认 r1 报文。

隐式确认：请求端发送请求报文 r2和r3 发送到响应端；响应端处理完成后返回确认报文 a3 给请求端显式确认 r3 报文并且隐式确认了 r2 报文，这种确认多个报文行为称为确认合并。

确认分为两种，一种是肯定确认ACK，一种是否定确认NAK。只有肯定确认ACK能够合并确认，这也合理，响应端接收多个报文且成功执行，那只需要告诉请求端最后成功执行报文的编号即可表示前面都报文都成功执行了。

对于收到否定确认NAK的数据包，由NAK的内容及请求端的配置来决定是否重发数据包。

对于确认机制来说，其还包含两个小机制，分别为 发包定时（计时）机制 和 数据包重传机制。怎么体现呢？对于未收到确认的数据包，则请求端等待超时后（定时机制），便认为是丢包了，将会重发数据包（重传机制），若重发多次还未收到确认，则上报错误。

综上，确认机制可以极大可能确保数据包被对端正确接收。

PSN机制

PSN全称为Packet Sequence Numbers，即数据包序列号。请求端发送的每个数据包都含有PSN，响应端会检查收到数据的PSN是否与预期一致。

引用一下IB协议原文（IB协议V1.4第9.71章节）。

PSNs are transmitted within the Base Transport Header (BTH) for all packets. They are used to detect missing or out-of-order packets, and, for reliable services, to relate a response packet to a given request packet. Each IBA QP consists of a send queue and a receive queue; likewise, an EE Context has a send side and a receive side. There is a relationship between the PSN on a requester’s send queue and the PSN on the responder’s corresponding receive queue. Thus, each half of a QP (or EE Context) maintains an independent PSN; there is no relationship between the PSNs used on the Send queue and Receive queue of a given queue pair, or between different connection.

简单来说，QP维护一组相互独立的PSN，分别为发送PSN和接收PSN，它们之间没有任何关系，发送PSN是本端随机产生的，而接收PSN是对端告诉的。如下图所示，节点A的QP与节点B的QP建立联系时，A节点QP的SQ随机产生PSN（发送PSN）并告诉B节点，而B节点将A节点告诉的PSN填入到自己QP的RQ中（接收PSN），同样，B节点QP的SQ随机产生PSN也会告诉A节点。

通过建立联系，响应端可以知道请求端下一个发过来的报文PSN是多少，所以可以清楚的知道数据包是否丢失或乱序。

当响应端接收到数据包后，将会使 接收PSN 增加（按某种规则计算），以保证正确接收下一个数据包。

可靠连接（RC）

在IB协议中，连接意味着（IB协议V1.4版本3.2.2章节）：

For connected service, each QP is associated with exactly one remote consumer. In this case the QP context is configured with the identity of the remote consumer’s queue pair. … During the communication establishment process, this and other information is exchanged between the two nodes.

在连接服务中，每个QP（Queue Pair）与一个远程节点相关联。在这种情况下，QP Context中会配置有远程消费者的队列对的标识。在通信建立过程中，这些信息以及其他信息会在两个节点之间进行交换。

简单来说，连接就是让两个QP（不同节点）相互存储对端的标识，标识包含QPn和端口信息，类似于TCP中的IP和端口号。

引用一下知乎《RDMA基本服务类型》文章中一段关于连接的描述和图片。

A、B和A、C节点的网卡在物理上是连接在一起的，A上面的QP2和B上面的QP7、A上面的QP4和B上面的QP2建立了逻辑上的连接，或者说“绑定到了一起”。在连接服务类型中的每个QP，都和唯一的另一个QP建立了连接，也就是说QP下发的每个WQE的目的地都是唯一的。拿上图来说，对于A的QP2下发的每个WQE，硬件都可以通过QPC得知其目的为B的QP7，就会把组装好的数据包发送给B，然后B会根据QP7下发的RQ WQE来存放数据；同理，对于A的QP4下发的每个WQE，A的硬件都知道应该把数据发给Node C的QP2。

两个QP连接，相当于之间建立管道，我发送的东西必然去你那，你发送的东西必然来我这，但这并不意味着发送的东西一定能送达对端。在连接基础上加上可靠服务，就是可靠连接服务，引用一下IB协议第9.7.7章节原文：

A reliable connection is a connection created between a single local QP and a single remote QP and that can guarantee that messages are delivered at most once, in order and without corruption (in the absence of unrecoverable errors) between the local and remote QPs.

可靠连接是在单个本地QP和单个远程QP之间创建的连接，该连接可以保证在本地QP和远程QP之间最多传递一次消息，并且没有损坏（在没有不可恢复错误的情况下）。

可靠连接非常类似于TCP/IP协议，一对一单点通信。

MSN

对于可靠连接，响应端需要返回给请求端MSN。MSN全称为Message Sequence Number，即消息序列号。这个MSN和PSN有什么关系？有了PSN为什么还需要PSN？

在前文说道，请求端每发一个数据包，都会带上数据包序列号PSN，这个PSN是用来标识数据包个数的，而不是标识请求个数的。了解TCP/IP协议的伙伴们应该知道，用户传输一笔大数据（大于MTU）时，底层都时按MTU拆成一个个小包发送的，同样在IB协议中也是，用户一个请求数据大小，可能会超过PMTU大小，HCA（RDMA网卡）会将一个请求按PMTU拆成一个个带有PSN的小包发送。

为了方便指示请求端请求完成情况，IB协议要求响应端返回的ACK报文中必须携带MSN（可靠连接），它的作用就是指示请求端哪些请求完成了。

光说可能不太清楚，举个例子，看下图。

本端取下WQE1请求，将其拆分成5个小包发送到远端，如果没有MSN的话，想要知道WQE1请求完成情况，硬件必须记录WQE1最后一个小包的PSN（即PSN5），那远端回复的每个ACK（带有完成的PSN），本端都需要对比一下是否大于等于记的PSN（PSN5），这样才能知道WQE1请求是否完成了。

上面的操作有两个问题：1）需要硬件增加寄存器来寄存WQE最后的PSN，若支持outstanding很大的话，就需要很多寄存器，这是一个QP情况，多QP需要资源非常多；2）每次远端回复ACK都需要对比这个QP所有暂存PSN的寄存器，增加耗时。

当存在MSN时，本端只需要看ACK回复的MSN即可知道本端WQE1是否完成。

与MSN相应的是SSN（Send Sequence Number），即发送序列号。SSN是本端使用的，一个WQE对应一个SSN号。QP建链时，发送端将SSN初始化为1，表示即将处理SSN为1的请求，而接收端将MSN初始化为0，表示已完成的请求号为0，来看看一个官方的示例。

上图中请求1（request 1）拆分成了两个PSN包，响应端处理完第二个PSN包才会MSN=1。

MSN还有一个重要作用，就是让请求端刷新credit信息。

端到端流控（credit）

引用一下IB协议第9.7.7.2章节原文。

IBA provides an end-to-end (or message level) flow control capability for reliable connections that can be used by a responder to optimize the use of its receive resources. Essentially, a requester cannot send a request message unless it has appropriate credits to do so.

IBA为可靠连接提供端到端(或消息级)流控制功能，响应端可以使用它来优化其接收资源的使用。也就是说，请求者除非拥有信用(credit)额度，否则不能发送请求消息。

简单来说，就是初始化时，响应端告诉请求端我这里能接受多少个请求（需要消耗RQ资源的请求，不考虑SRQ），这样请求端就知道了自己的credit。

举个例子：

• 初始化时，响应端告诉请求端可以接收10个请求，那么请求端的credit=10、SSN=1、LSN=10（最大发送序列号，值等于credit+SSN-1）。
• 工作阶段，请求端发送了5个工作请求，响应端回复ACK（credit=5、MSN=5）表示在完成5个工作请求的情况下，还能接受5个请求。
• 请求端更新credit=5、SSN=6、LSN=10，知道自己还能发送5个请求，所以又发送了5个请求。
• 响应端回复ACK（credit=2、MSN=10）表示在完成10个工作请求的情况下，还能接受2个请求。

不应该是（credit=0、MSN=10）吗？怎么是（credit=2、MSN=10）？这是因为在响应端处理请求时，应用层可能会下发更多的资源来容纳发送端发过来的请求，所以IB协议设计了credit和MSN来指示请求端能发送多少请求。

放一张官方图加深一下印象，更多关于端到端流控计算信息，请查看IB协议V1.4版本第9.7.7.2章节。

可靠数据包(RD)

在IB协议中，数据报意味着（IB协议V1.4版本3.2.2章节）：

For datagram service, a QP is not tied to a single remote consumer, but rather information in the WQE identifies the destination. A communication setup process similar to the connection setup process needs to occur with each destination to exchange that information.

对于数据报服务，QP不绑定到单个远程消费者，而是WQE中的信息标识目的地。类似于连接类型服务，建立通信的过程也需要两端交换对端信息，但是数据报服务对于每个目的节点都需要执行一次这个交换过程。

类似于连接类型，数据报类型也需要存储远端节点信息，这个存储信息的空间成为End to End Context（EEC），即端到端上下文，此上下文提供定位远程节点、数据包序列号和交换确认以及维护可靠性所需的信息。

这里讲解的比较抽象，还是放一张官方图来说明一下。

如上图所示，节点1上QP4与节点2上QP24、QP25通信，节点1上QP与节点3上QP14通信，那么只需要为连个节点之间建立EEC即可。本端QP想要和哪个节点上的QP通信，只需在WQE中指定本地EEC编号、目标QP编号、目标Q_key即可。以上图举例，节点1上QP4想要发请求给节点2上QP24，则将WQE（EEC：27、dest QPN：24、Q_key：YYY）下发给QP4即可（Q_key是建立联系拿到的，暂不展开）。

数据包类型加上三种可靠机制（CRC、确认、PSN）就是可靠数据包服务，那么相比于可靠连接服务来说，它有什么优势呢？引用一下IB协议原文（IB协议V1.4版本第9.7.8章节）：

The motivation for using Reliable Datagram is to economize the QP name space for applications that engage in “all to all” communication. Consider N processor nodes, each with M processes. If all M processes wish to communicate with all the processes on all the nodes, a Reliable Connection service requires M2*(N-1) QPs on each node. By comparison, the Reliable Datagram service only requires M QPs + N “end-to-end” (EE) connections on each node for exactly the same communications.

使用可靠数据报的动机是为了节省参与“all to all”通信的应用程序QP个数。考虑N个处理器节点，每个节点有M个进程。如果所有M个进程都希望与所有节点上的所有进程通信，那么可靠的连接服务需要每个节点上有M^2（N-1）个QPs（M(N-1)*M）。相比之下，可靠的数据报服务只需要在每个节点上建立M个QPs+N个“端到端”（EE）连接，以实现完全相同的通信。

MSN

对于可靠的数据报业务，消息序列号（Message Sequence Number）是响应端返回给请求端的数字，表示响应端在EE上下文中完成的消息数。这里的MSN与可靠连接服务中的MSN功能基本一样。

扩展可靠连接(XRC)

XRC服务类型了解不多，这里不详细介绍，引用一下协议原文（IB协议V1.4版本第9.7.9.1章节）：

XRC allows significant savings in the number of QPs required to establish all to all process connectivity in large clusters.

XRC可显著节省在大型集群中建立all to all连接所需的QP数量。

The established trend in multi core processors results in a direct increase in the number of processes that typically run on each endnode of a typical IB connected cluster. Multi core node systems are very common today with road maps showing even more cores per node in the not so distant future.

多核处理器的日益增长的趋势，导致在典型IB连接集群的每个终端节点上运行的进程数量直接增加。如今，多核节点系统非常普遍，在不久的将来，每个节点将拥有更多的内核。

With the Reliable Connected (RC) Transport Service, the number of QPs required per endnode to achieve full process to process connectivity is equal to Npp (where N is the number of nodes in the cluster and p the number of processes per node)12. As the number of processes grows together with the number of cores per system, the number of RC QPs (and its associated memory resources) start to become of significant impact.

对于可靠连接(RC)传输服务，完全实现每个终端节点间进程到进程连接所需的qp数量等于N*p*p(其中N为集群中的节点数，p为每个节点中的进程数)。随着进程数量和每个系统的内核数量一起增长，RC qp(及其相关的内存资源)的数量开始产生重大影响。

XRC is different from RD in several ways but first and foremost it eliminates the most significant limitation of the RD Transport Service which is the single outstanding message supported per EE context.

XRC在很多方面与RD不同，但最重要的是，它消除了RD传输服务最重要的限制，即每个EE上下文中只支持一条未完成的消息。

简要来说，XRC服务最主要的目的就是进一步节省资源（大规模集群情况），同时解决RD服务类型的缺陷。

不可靠服务

不可靠服务有以下特点：

1. 请求者不会收到消息接收的确认。
2. 没有数据包序列号保证。
3. 响应端正常验证传入的数据包（验证适当的报头字段、CRC检查）。损坏的数据包可能会被静默丢弃，从而导致消息被丢弃。
4. 当检测到传入数据包（如丢弃/无序的数据包）中的错误时，响应端不会停止，而是继续接收传入的数据包。
5. 一旦响应端以正确的顺序接收到完整的消息，并且所有适当的有效性检查（包括变量和不变的CRC检查）都已完成，则认为操作完成。
6. 一旦“最后一个”或“唯一”数据包提交到fabric，请求者认为消息操作完成。

很重要的一点，在本端发送完WQE最后一笔PSN报文后，就认为WQE完成了，接着便会产生CQE，如下图所示。

本端将WQE1的PSN1~PSN5都发出后，便认为WQE已经完成，不需要远端确认。当然，如果在处理WQE1中出错，也会立即完成这个WQE。

不可靠连接(UC)

引用一下IB协议V1.4版本第9.8.2原文：

An unreliable connection consists of a one-to-one correspondence between two QPs. Packets are sent from one QP to the other but no acknowledgments are generated by the destination QP. The chief characteristics are that there are no delivery guarantees made to the requester. The responder, however can detect data corruption and out of order packets.

不可靠连接由两个qp之间的一对一通信组成。数据包从一个QP发送到另一个QP，但不由目标QP生成确认。其主要特征是不向请求者提供交付保证。然而，响应器可以检测数据损坏和乱序数据包。

与可靠连接相比，不可靠连接只有CRC机制与PSN机制，也就是说，不可靠连接能检查到错误或丢包，但不会告诉请求端，即使执行正确，也不会给请求端反馈。其他与可靠连接一样，同样会在QP的Context中存储对端QP的标识信息（QPn和端口信息）。

因为没有确认报文（ACK），不可靠连接不支持端到端流控以及MSN。

不可靠数据报(UD)

引用一下IB协议V1.4版本第9.8.3原文：

Unreliable Datagrams are a form of communication that allow a source QP to send each message to one of many destination QPs that may exist on the same or multiple destination endnodes.

• For each message to be sent, the requester must be supplied with the destination address (see 11.2.2.1 Create Address Handle on page 598), the destination QP, the destination Q_Key etc.
• The responder must deliver to the client the requester’s address, QP etc.

不可靠数据报是一种通信形式，允许源QP将每条消息发送到可能存在于同一或多个目的地终端节点上的多个目的地QP中的一个。

• 对于要发送的每条消息，必须向请求者提供目的地地址（见第11.2.2.1节“创建地址句柄”，即AH）、目的地QP、目的地Q_Key等。
• 响应端必须向客户提供请求者的地址、QP等

不可靠数据报不需要EEC，只需要在WQE中填写目的地地址AH（QP建立联系时创建的，不展开）、Dest QPn、Q_key，即可将数据包发送给指定目的地，此外，不可靠服务只有CRC机制，无法检测到丢包或乱包，类似于TCP/IP协议中的UDP。

放个IB协议原图：

原始数据报

完全不了解，跳过~~~想要了解的可以查看IB协议9.8.4章节。

服务类型支持操作

RDMA不同服务类型支持的操作有差异，以下是各种服务类型支持操作的汇总：

具体的操作介绍将在下一章节讲解。