RDMA技术调研：从选型到性能调优的实战指南

简介这是一份面向网络与高性能计算方向学习者、研发人员的RDMA技术调研文档系统梳理了远程直接内存访问的原理、协议与编程方法适合希望理解数据中心高速网络底层机制、评估RDMA落地场景的读者。资源包内含1个PDF文件整体约1.01MB篇幅紧凑便于集中阅读与查阅。文档从DMA与RDMA的基本概念切入对比传统网络协议栈的转发过程展开零拷贝、内核旁路、CPU卸载三大核心优势并说明低延迟、高带宽、低CPU占用对应的典型业务场景。随后介绍Infiniband、RoCE、iWARP三种协议差异以及WQ、SQ、RQ、CQ、QP等关键术语与SEND/RECV、WRITE/READ、ATOMIC等通信操作还涉及传输模式、内存注册、保护域等概念并对比verbs与rdma-core两种编程接口。目前已有528人学习适合作为入门梳理与方案选型的参考材料。1. RDMA 技术调研从一次跨机内存拷贝的延迟异常说起两台机器各插一张 100G 网卡跑同一个分布式训练任务别人端到端吞吐能到 90Gbps 以上你这边卡在 30Gbps 上下CPU 占用还高得离谱。抓包看应用层逻辑没问题最后定位到数据通路根本没走 RDMA而是退化成了普通 socket 拷贝。这个场景在 RDMA 技术调研里非常典型硬件买了、驱动装了、库也编了但真正跑起来是不是走了 RDMA很多人一开始并不清楚。RDMARemote Direct Memory Access要解决的核心问题是让一台机器直接读写另一台机器的内存数据搬运不经过双方 CPU也不经过内核协议栈的多次拷贝。它适合谁做分布式存储、高性能计算、大规模模型训练、高频交易这类对延迟和 CPU 开销都敏感的场景。这篇调研笔记不堆概念按「先搞清它是什么、再动手跑通、最后看坑在哪」的顺序把 RDMA 的选型、最小验证、参数调优和排错讲透新手能照着复现熟手能对照边界。2. RDMA 三种实现路线怎么选InfiniBand、RoCE 与 iWARP 的取舍做 RDMA 技术调研第一步不是写代码而是先确定你手里的硬件和网络支持哪条路线。RDMA 不是单一协议它是一组能力底层可以由三种不同的网络实现承载。选错路线后面所有调优都是白费力气。2.1 三条路线的本质差异InfiniBand 是原生 RDMA 网络从网卡到交换机整套专有延迟最低、生态最成熟但成本和运维门槛最高通常出现在超算中心和头部大厂的核心集群。RoCE 是在以太网上承载 RDMA分 v1 和 v2 两个版本v1 走二层、基本被淘汰现在说 RoCE 默认指 RoCEv2走 UDP 封装、可路由是当前数据中心最主流的方案。iWARP 走 TCP/IP兼容性最好但性能和生态都不如 RoCE实际落地较少。判断标准很直接如果预算充足且追求极致延迟选 InfiniBand如果已有或计划用以太网组网选 RoCEv2如果网络环境复杂、必须跨广域或强依赖 TCP才考虑 iWARP。绝大多数做 RDMA 技术调研的团队最终落在 RoCEv2 上。2.2 RoCEv2 落地的前置条件RoCEv2 对网络的要求比普通以太网苛刻得多这是调研阶段必须提前确认的。核心是三点无损网络、PFC/ECN 配置、网卡与交换机能力匹配。无损网络是 RoCEv2 的命门。普通以太网丢包会触发 TCP 重传但 RDMA 的传输层如 Go-Back-N 重传机制对丢包极其敏感一旦丢包性能断崖式下跌。所以 RoCEv2 依赖 PFCPriority Flow Control做逐跳流控配合 ECNExplicit Congestion Notification做端到端拥塞标记两者缺一不可。下面这张表是我做选型时常用的对照参数按实际环境填维度InfiniBandRoCEv2iWARP底层网络专有以太网 UDP以太网 TCP是否可路由是是是无损要求原生支持需 PFC/ECN依赖 TCP典型延迟最低低中等运维复杂度高中低适用场景超算/核心集群数据中心主流兼容性优先2.3 网卡与驱动确认的最小命令选型确定后先确认机器上的网卡是否支持 RDMA、驱动是否就绪。这一步不做后面全是玄学问题。# 查看系统识别到的 RDMA 设备 ibv_devices # 查看设备详细信息包括固件版本、端口状态 ibv_devinfo # 查看 RDMA 链路层类型Ethernet 表示 RoCEInfiniBand 表示 IB ibstatibv_devices列出所有可用的 RDMA 设备名如果输出为空说明驱动没装好或网卡不支持。ibv_devinfo里的link_layer字段是关键显示Ethernet就是 RoCE显示InfiniBand就是 IB。ibstat看端口状态State必须是ActiveRate显示链路速率。如果端口是Down或Initializing先解决物理链路和驱动别急着往下走。提示RoCEv2 环境下ibv_devinfo的link_layer显示 Ethernet 是正常的不要误以为没走 RDMA。3. 用 perftest 跑通 RDMA 最小验证带宽与延迟怎么测选型确认后最有效的验证方式不是自己写代码而是先用官方 perftest 工具跑通。perftest 是 RDMA 生态里最通用的基准测试套件能直接告诉你这条链路到底能不能用、性能到什么水平。这一步跑通才说明 RDMA 真正在工作。3.1 安装 perftest 与依赖perftest 依赖 libibverbs 和 librdmacm先装依赖再编译。# Ubuntu/Debian 安装依赖 apt-get install -y libibverbs-dev librdmacm-dev libibumad-dev # 下载并编译 perftest以源码方式便于控制版本 git clone https://github.com/linux-rdma/perftest.git cd perftest ./autogen.sh ./configure make -j$(nproc) make installlibibverbs-dev提供 verbs 编程接口librdmacm-dev提供连接管理接口这两个是 perftest 的硬依赖。编译完成后ib_send_bw、ib_write_bw、ib_read_lat等工具会安装到系统路径。如果configure报找不到 verbs 头文件检查依赖是否装全。3.2 带宽测试ib_write_bw 双机对跑带宽测试需要两台机器一台做 server一台做 client。ib_write_bw测的是写操作带宽是 RDMA 最常用的基准。# 服务端监听指定网卡设备 ib_write_bw -d mlx5_0 -a -F # 客户端连接服务端 IP跑 10 秒 ib_write_bw -d mlx5_0 -a -F 192.168.1.100-d mlx5_0指定 RDMA 设备名用ibv_devices查到的名字替换。-a表示测试所有消息大小从 2 字节到 8MB 全跑一遍能看出不同消息尺寸下的带宽曲线。-F允许在非默认端口运行避免权限问题。客户端最后的 IP 是服务端的业务 IP不是 RDMA 专用地址。跑完后重点看输出里的BW peak和BW average。100G 网卡理论上限约 12.5GB/s实际能到 11GB/s 以上算正常。如果只有几 GB/s大概率是走了 socket 回退或链路降速。3.3 延迟测试ib_read_lat 看单次往返带宽之外延迟是 RDMA 的另一个核心指标。ib_read_lat测读操作的往返延迟。# 服务端 ib_read_lat -d mlx5_0 -F # 客户端 ib_read_lat -d mlx5_0 -F 192.168.1.100输出里的t_avg是平均往返延迟单位微秒。同机房 RoCEv2 环境下小消息延迟通常在 2 到 5 微秒InfiniBand 能到 1 微秒出头。如果延迟到几十甚至上百微秒检查是否走了内核回退路径或者 PFC/ECN 没配好导致重传。注意perftest 默认用第一个可用端口多网卡机器务必用-d明确指定设备否则可能测到错误的链路上。3.4 判断是否真正走了 RDMA跑完 perftest 不代表应用就走了 RDMA。判断方法有两个一是看 CPU 占用RDMA 传输时 CPU 应该几乎不参与数据搬运占用极低二是用ibv_devinfo看端口计数器port_xmit_data和port_rcv_data在测试期间应该快速增长。# 测试前后各看一次对比计数器增量 ibv_devinfo -d mlx5_0 -v | grep -E port_xmit_data|port_rcv_data如果计数器没动说明数据根本没走 RDMA 设备perftest 可能连到了错误的地址或回退到了 TCP。这是调研阶段最常见的翻车点之一。4. RDMA 编程接口与 Go-Back-N 重传机制从 verbs 到可靠传输跑通基准测试后要真正把 RDMA 用进业务得理解它的编程模型和传输可靠性机制。这部分是 RDMA 技术调研里最容易含糊带过的但恰恰决定了你能不能定位性能问题。4.1 verbs 编程的四个核心对象RDMA 编程围绕 verbs API 展开核心对象有四个Context、Protection Domain、Queue Pair、Completion Queue。Context 是设备上下文通过ibv_open_device打开设备获得。Protection DomainPD是内存保护的边界所有注册的内存和队列都必须属于某个 PD。Queue PairQP是通信的基本单位包含发送队列和接收队列分 RC、UC、UD 三种类型RC 提供可靠连接、最常用。Completion QueueCQ用来接收操作完成通知避免轮询等待。下面是一个最小的 RC 连接建立骨架展示对象之间的关系// 打开设备获取上下文 struct ibv_context *ctx ibv_open_device(dev); // 分配保护域 struct ibv_pd *pd ibv_alloc_pd(ctx); // 创建完成队列容量 16 struct ibv_cq *cq ibv_create_cq(ctx, 16, NULL, NULL, 0); // 创建队列对RC 类型发送和接收队列深度各 16 struct ibv_qp_init_attr qp_attr { .send_cq cq, .recv_cq cq, .qp_type IBV_QPT_RC, .cap { .max_send_wr 16, .max_recv_wr 16 } }; struct ibv_qp *qp ibv_create_qp(pd, qp_attr);ibv_open_device拿到设备上下文是所有操作的起点。ibv_alloc_pd建立保护域注册内存时必须绑定 PD。ibv_create_cq的容量参数决定能挂起多少个未完成操作太小会导致send queue full。ibv_create_qp的max_send_wr和max_recv_wr是队列深度直接影响能并发多少请求。这些参数设小了会限流设大了浪费内存需要按业务并发量调。4.2 内存注册为什么是性能关键RDMA 要求所有参与传输的内存必须提前注册register注册过程会把内存页锁定pin在物理内存并建立网卡可访问的地址映射。这一步开销不小所以不能每次传输都注册。// 注册内存获取 lkey 和 rkey struct ibv_mr *mr ibv_reg_mr(pd, buf, size, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ);IBV_ACCESS_LOCAL_WRITE允许本地写IBV_ACCESS_REMOTE_WRITE和IBV_ACCESS_REMOTE_READ允许远端读写。注册返回的lkey用于本地操作rkey要传给对端用于远端访问。常见做法是预注册一块大内存池业务从中分配避免频繁注册带来的延迟抖动。4.3 Go-Back-N 重传机制与丢包敏感性RDMA 的 RC 队列对提供可靠传输底层用类似 Go-Back-N 的重传机制保证可靠性。发送方维护一个窗口按序发送请求接收方按序确认。一旦某个请求丢失或超时发送方从丢失点开始重传整个窗口内的后续请求。这个机制解释了为什么 RDMA 对丢包如此敏感。普通 TCP 有选择性确认SACK只重传丢失的段而 Go-Back-N 一旦丢包窗口内已发但未确认的请求全部重传带宽利用率骤降。在 RoCEv2 环境下一次 PFC 配置不当导致的丢包就可能让吞吐从 90Gbps 掉到 10Gbps 以下。所以 RoCEv2 部署里PFC 和 ECN 不是可选项是必选项。PFC 保证不丢包ECN 在拥塞时提前标记、让发送方降速两者配合才能让 Go-Back-N 重传尽量不触发。调研阶段如果发现性能不稳定先查 PFC 计数器和 ECN 标记统计而不是怀疑应用代码。# 查看 PFC 统计关注 pause 帧数量 ethtool -S eth0 | grep -i pfc # 查看 ECN 标记统计 ethtool -S eth0 | grep -i ecnPFC pause 帧持续增长说明链路在频繁流控可能是带宽不匹配或配置问题。ECN 标记增长说明拥塞在发生需要调整 ECN 阈值。这两个计数器是 RoCEv2 排错的第一现场。5. RDMA 部署避坑五条血泪经验RDMA 技术调研最容易踩的坑往往不在代码里而在环境配置和认知偏差上。下面五条是我实际部署中反复遇到的每条按现象、原因、解决写清楚。5.1 现象perftest 跑出来带宽只有几 Gbps原因数据通路回退到了 TCP socket根本没走 RDMA。常见触发是客户端连接时用了错误地址或者-d指定的设备不存在perftest 静默回退。解决先用ibv_devices确认设备名用-d明确指定。跑测试时用ibv_devinfo -v看端口计数器是否增长不增长就是没走 RDMA。检查客户端 IP 是否是服务端可达的业务 IP。5.2 现象延迟忽高忽低抖动严重原因PFC 未配置或配置不一致导致链路偶发丢包触发 Go-Back-N 重传。也可能是 ECN 阈值设置不当拥塞控制频繁介入。解决两端交换机和网卡的 PFC 优先级配置必须一致通常用优先级 3 承载 RoCE 流量。ECN 阈值按链路带宽和缓冲调一般从较低值开始试。用ethtool -S持续观察 pause 和 ECN 计数。5.3 现象内存注册失败报 Cannot allocate memory原因注册内存时锁定的物理页超过系统限制或者内存碎片严重导致大页分配失败。解决检查ulimit -l是否足够大RDMA 注册的内存会计入锁定内存限制。用大页hugepage替代普通页减少页表开销和碎片。预注册内存池避免运行时频繁注册。5.4 现象多进程并发时性能反而下降原因多个进程共享同一个 RDMA 设备队列对和完成队列竞争或者内存注册重复导致锁竞争。解决每个进程用独立的 PD 和 QP避免共享。内存池按进程隔离或者用共享内存加引用计数管理。监控ibv_devinfo的队列对数量避免超过网卡上限。5.5 现象跨机通信正常跨交换机就不通原因RoCEv2 虽然可路由但 PFC 是逐跳的中间交换机如果不支持或没配 PFC无损链路就断了。也可能是 MTU 不一致导致分片。解决确认路径上所有交换机都支持并配置了 PFC。统一 MTURoCEv2 通常用 4096 或 9000。用ib_send_bw跨交换机测试逐跳排查。6. 用 ibv_devinfo 计数器做 RDMA 性能回归验证跑通和避坑之后最后一个实用技巧是建立性能回归验证习惯。RDMA 环境一旦配置好平时很稳定但任何网络变更、驱动升级、交换机调整都可能悄悄影响性能。与其等业务出问题不如定期用计数器做回归。核心方法是把ibv_devinfo -v的关键计数器采集下来和基线对比。重点看四个port_xmit_data、port_rcv_data反映吞吐port_xmit_packets、port_rcv_packets反映包量。正常情况下吞吐和包量的比值应该稳定如果包量涨了但吞吐没涨说明小包变多或重传增加。# 采集基线每 5 秒一次共 12 次 for i in $(seq 1 12); do echo $(date) ibv_devinfo -d mlx5_0 -v | grep -E port_xmit_data|port_rcv_data|port_xmit_packets|port_rcv_packets sleep 5 done这个脚本跑一分钟能看出计数器增长是否线性。如果某段时间增长停滞说明链路有问题。把输出存成基线文件每次网络变更后重跑对比差异超过 10% 就深入排查。另一个技巧是结合perfquery看错误计数器。perfquery能读出网卡的各种错误统计比如symbol_error、link_error_recovery、port_rcv_errors。这些计数器平时应该是零或极低一旦增长就说明物理层或链路层有问题。# 查看端口错误计数器 perfquery -x mlx5_0 1-x输出十六进制1是端口号。重点看PortRcvErrors和PortXmitDiscards前者是接收错误后者是发送丢弃。这两个增长通常意味着 PFC 或链路配置有问题。我自己的习惯是每次 RDMA 环境有任何变更先跑一遍 perftest 基线再采集计数器两者都正常才认为变更安全。这个习惯帮我提前发现过好几次交换机 PFC 配置被误改的问题避免了业务侧的性能事故。RDMA 这东西配置对了很省心配置错了很隐蔽回归验证是唯一的后悔药。希望帮到你。本文还有配套的精品资源点击获取