【RDMA】librdmacm库和连接建立过程

bandaoyu

已于 2024-12-08 02:31:31 修改

阅读量9.1k

点赞数 3

文章标签： RDMA

于 2023-10-19 04:50:30 首次发布

本文链接：https://blog.csdn.net/bandaoyu/article/details/133918204

版权

概述：

rdma_cm是用于建立RDMA传输上的通信的管理器。

rdmacm 原理：https://blog.csdn.net/bandaoyu/article/details/125234340

说明：

RDMA CM是一个用于建立可靠连接和不可靠数据报数据传输的通信管理器。它为建立连接提供了一个RDMA传输中立的接口。该API基于套接字，但为队列对（QP）的语义进行了调整：通信必须通过特定的RDMA设备进行，并且数据传输是基于消息的。

RDMA CM仅提供RDMA API的通信管理（连接建立/拆除）部分。它与libibverbs库定义的verbs API配合使用。libibverbs库提供了发送和接收数据所需的接口。

客户端操作：

此部分提供了通信的主动端（或客户端）的基本操作概述。一般的连接流程如下：

1. rdma_create_event_channel：创建接收事件的通道。
2. rdma_create_id：分配一个rdma_cm_id，类似于socket。
3. rdma_resolve_addr：获取本地RDMA设备以到达远程地址。
4. rdma_get_cm_event：等待RDMA_CM_EVENT_ADDR_RESOLVED事件。
5. rdma_ack_cm_event：确认事件。
6. rdma_create_qp：为通信分配一个QP。
7. rdma_resolve_route：确定到达远程地址的路由。
8. rdma_get_cm_event：等待RDMA_CM_EVENT_ROUTE_RESOLVED事件。
9. rdma_ack_cm_event：确认事件。
10. rdma_connect：连接到远程服务器。
11. rdma_get_cm_event：等待RDMA_CM_EVENT_ESTABLISHED事件。
12. rdma_ack_cm_event：确认事件。
13. 在连接上执行数据传输。
14. rdma_disconnect：撤销连接。
15. rdma_get_cm_event：等待RDMA_CM_EVENT_DISCONNECTED事件。
16. rdma_ack_cm_event：确认事件。
17. rdma_destroy_qp：销毁QP。
18. rdma_destroy_id：释放rdma_cm_id。
19. rdma_destroy_event_channel：释放事件通道。

用于在节点之间建立不可靠数据报（UD）通信的过程几乎相同。但是，QPs之间不会形成实际的连接，因此不需要断开连接。

虽然此示例显示客户端发起断开连接，但连接的任一方都可以发起断开连接。

服务器操作：

此部分提供了通信的被动端（或服务器端）的基本操作概述。一般的连接流程如下：

1. rdma_create_event_channel：创建接收事件的通道。
2. rdma_create_id：分配一个rdma_cm_id，类似于socket。
3. rdma_bind_addr：将本地端口号设置为监听的端口号。
4. rdma_listen：开始监听连接请求。
5. rdma_get_cm_event：等待带有新的rdma_cm_id的RDMA_CM_EVENT_CONNECT_REQUEST事件。
6. rdma_create_qp：在新的rdma_cm_id上为通信分配一个QP。
7. rdma_accept：接受连接请求。
8. rdma_ack_cm_event：确认事件。
9. rdma_get_cm_event：等待RDMA_CM_EVENT_ESTABLISHED事件。
10. rdma_ack_cm_event：确认事件。
11. 在连接上执行数据传输。
12. rdma_get_cm_event：等待RDMA_CM_EVENT_DISCONNECTED事件。
13. rdma_ack_cm_event：确认事件。
14. rdma_disconnect：撤销连接。
15. rdma_destroy_qp：销毁QP。
16. rdma_destroy_id：释放已连接的rdma_cm_id。
17. rdma_destroy_id：释放监听的rdma_cm_id。
18. rdma_destroy_event_channel：释放事件通道。

返回值：成功返回0，错误返回-1。如果函数以异步方式运行，则返回值为0表示成功启动操作。操作仍然可能以错误完成；用户应该检查相关事件的状态。如果返回值为-1，则errno将包含有关失败原因的其他信息。

先前版本的库对于与ENOMEM、ENODEV、ENODATA、EINVAL和EADDRNOTAVAIL代码有关的某些情况会返回-errno并且不设置errno。希望检查这些代码并与先前版本的库兼容的应用程序必须在返回代码小于-1时手动将errno设置为返回代码的负值。

代码示例

RDMA编程链接管理库 librdmacm 源码：rdma-core/librdmacm/examples at master · linux-rdma/rdma-core (github.com)

在：rdma-core/librdmacm/examples

服务端：rdma_server.c

客户端：rdma_client.c

mellaonx驱动源码中也提供了rdma-core源目录码:MLNX_OFED_LINUX-5.8-1.1.2.1-rhel9.0-ext/src/MLNX_OFED_SRC-5.8-1.1.2.1/SRPMS

rdma-core-58mlnx43-1.58112.src.rpm

rpm -ivh rdma-core-58mlnx43-1.58112.src.rpm 安装完成后

源码解压到：/root/rpmbuild/SOURCES/

编译

$ bash build.sh

输出在：build/bin 和 build/lib

build/bin 目录包含示例程序，build/lib 目录包含共享库。构建配置是“原地”运行所有程序的，因此无法安装。

注意：目前不易从构建目录运行插件，插件仅从系统路径加载

编译之前环境可能需要安装一些依赖，如：

CentOS 7:

$ yum install epel-release

$ yum install cmake3 ninja-build pandoc

详情见README.md

编译出来的内容：

略

rdma_xclient.c 和 rdma_client.c 的区别

rdma_xclient.c 客户端只发，接收端只收

rdma_client.c 双边相互收发

这里有一个理解难点

就是执行rdma_get_cm_event之后的输出resp 是从哪里来的？

其实就是用户态和内核态的交流,户态和内核态主要是通过write()系统调用来对/dev/infiniband/uverbsN字符设备文件进行操作从而实现交流信息的。

最近的协议栈也支持了ioctl()系统调用，通过ioctl把cmd命令发到内核的，内核的rdma cm模块会根据cmd做相应处理

rdma_get_cm_event 就是通过ioctl把cmd命令发到内核的，内核的rdma cm模块会根据cmd做相应处理，通过resp返回结果。

用户态和内核态如何交流

前置知识

用户态和内核态如何交流

控制路径上，用户态和内核态主要是通过write()系统调用来对/dev/infiniband/uverbsN字符设备文件进行操作的，

从而实现交流信息的。最近的协议栈也支持了ioctl()系统调用，

通过ioctl把cmd命令发到内核的，内核的rdma cm模块会根据cmd做相应处理

ABI

ABI（Application Binary Interface）是应用程序间的二进制接口，本文中RDMA软件栈架构图中的Userspace和Kernel之间的uverbs接口就是一种ABI。ABI定义了运行时的程序之间交流的格式，比如参数以什么形式传递（分别写到指定的寄存器/使用栈）、以什么格式传递以及返回值放到哪里等等。

uverbs API规定了用户态和内核态之间的命令消息cmd的格式和返回消息resp的格式，大致是下图这个意思：

我们在“RDMA之Verbs”一文中介绍过用户态库和内核驱动，它们各自都按照自己的节奏发布版本，用户态和内核态之间交互，涉及到很多命令的传递，而不同版本之前的交互格式是有差异的。RDMA软件栈通过设计uverbs ABI接口来保证不同版本的用户态和内核态之间的兼容性，即某个版本的用户态库，可以直接运行在各种版本的内核上。

我们还是拿Create QP的动作来举例，软件栈中是这样ibv_create_qp()的定义cmd和resp的：

可以看到cmd分为三个部分：

命令码：告诉内核态当前陷入内核态想要执行的操作
公共域段：所有厂商的创建QP动作都需要从用户态传递到内核态的参数
驱动自定义域段：各个厂商自定义的需要传递到内核的参数

resp分为两个部分：

公共域段：所有厂商在内核创建完QP之后，需要返回给用户态的参数

驱动自定义域段：各个厂商的自定义返回参数

上面的格式都是由uverbs ABI接口定义的，具体来说整套用户态和内核的交互机制都是由内核的ib_uverbs.ko和用户态的libibverbs.so相配合实现的。

实际上除了各个厂商的驱动开发者，RDMA应用程序开发者以及普通用户不必用关心ABI的实现，只需要关心API就可以了。

原文链接：https://blog.csdn.net/bandaoyu/article/details/113125473

rdma-core 编译出来的工具

使用 RDMA verbs API，较为底层，需要手动管理连接和操作；使用 RDMA CM API，更高层，封装了一些操作，使得代码更简洁易读。

用法：

usage: rdma_xserver

[-p port_number]

[-c communication type]

r - RC: reliable-connected (default)

x - XRC: extended-reliable-connected

usage: rdma_xclient

[-s server]

[-p port_number]

[-c communication type]

r - RC: reliable-connected (default)

x - XRC: extended-reliable-connected

服务端：

rdma_xserver -p 8888

客户端：

rdma_xclient -s 10.252.8.1 -p 8888

usage: rdma_server

[-s server_address]

[-p port_number]

usage: rdma_xclient

[-s server]

[-p port_number]

[-c communication type]

r - RC: reliable-connected (default)

x - XRC: extended-reliable-connected

服务端：

rdma_server -s 10.252.8.1 -p 8888

客户端：

rdma_client -s 10.252.8.1 -p 8888

在编译出来的bin下还有：

[root@localhost bin]# ls

check_lft_balance.pl ibaddr iblinkinfo ibrouters ibv_asyncwatch ibv_xsrq_pingpong rdma_server sminfo udpong

cmtime ibcacheedit ibnetdiscover ibsendtrap ibv_devices mckey rdma_xclient smpdump umad_compile_test

dump_fts ibccconfig ibnodes ibstat ibv_devinfo mcm_rereg_test rdma_xserver smpquery umad_reg2

dump_lfts.sh ibccquery ibping ibstatus ibv_rc_pingpong perfquery riostream srp_daemon umad_register2

dump_mfts.sh ibfindnodesusing.pl ibportstate ibswitches ibv_srq_pingpong rcopy rping testleaks umad_sa_mcm_rereg_test

ibacm ibhosts ibqueryerrors ibsysstat ibv_uc_pingpong rdma_client rstream ucmatose vendstat

ib_acme ibidsverify.pl ibroute ibtracert ibv_ud_pingpong rdma_rename saquery udaddy

他们的用法可以使用：man xxx 查询如：man rdma_client

udaddy “udp”的测试

如果系统上没有安装doc手册，则可以访问： Index of /linux/man-pages/man1 在页面搜索相关的命令，查看其用法

cmtime

确定客户端和服务器应用程序之间的RDMA CM连接建立和拆除中各个“步骤”的最小和最大时间定时的“步骤”包括：

创建id、绑定地址、解析地址、解析路由、创建qp、连接、断开连接和销毁。

例子：

服务端

cmtime -p 888

客户端：

cmtime -p 888 -s 10.252.8.1

-s server_address 服务器系统监听连接的网络名称或IP地址。所使用的名称或地址必须经过RDMA设备路由。客户端需

指定。

-b bind_address

要绑定到的本地网络地址。

-c connections

客户端与服务器之间建立的连接数。（默认100）

-p port_number

服务器的端口号。

-r retries

解析地址或路由时的重试次数。（默认2）

-t timeout_ms

解析地址或路由时的超时时间，以毫秒（ms）为单位。（默认2000 - 2秒）

ucmatose

使用librdmacm在两个节点之间建立一组可靠的RDMA连接，可选择在节点之间传输数据，然后断开连接。

用法：

ucmatose [-s server_address] [-b bind_address]
                 [-f address_format] [-P port_space]
                 [-c connections] [-C message_count] [-S message_size] [-a ack_timeout]
       ucmatose -s server_address [-b bind_address]
                 [-f address_format] [-P port_space]
                 [-c connections] [-C message_count] [-S message_size] [-t tos] [-a ack_timeout]

例子：

服务端：

ucmatose -b 10.252.8.1

客户端：

ucmatose -s 10.252.8.1