RDMA核心要素解析：从QP、内存注册到三种网络形态

1.1 TCP/IP路径的开销到底在哪

先说结论：延迟高、CPU开销大，锅并不全在网卡物理传输上。一次传统TCP收发的完整路径大概是这样的：应用调用send()把用户态缓冲区的数据拷贝到内核态socket缓冲区，然后TCP/IP协议栈从上到下逐层处理，包过滤、校验和计算、分段、路由查找，再交给网卡驱动，驱动把数据写入DMA环，网卡发出中断。接收方向更繁琐——网卡收到报文触发中断或轮询，数据从驱动进入协议栈，经过校验、去重、重组，再从内核缓冲区拷贝到用户态缓冲区，最后应用才能拿到数据。

这条路径里至少有两个“拷贝”是硬开销：用户态到内核态，内核态到网卡。每次拷贝都涉及CPU参与，哪怕有DMA了，内存拷贝本身依然要占用总线带宽和CPU周期。这还没算上下文切换——应用每次收发都可能陷入内核，多次切换对低时延场景是致命的。再加上协议栈本身的状态维护、定时器、拥塞控制，发一个几KB的包，CPU要干的事可太多了。

RDMA的思路不是把TCP/IP调快，而是干脆换一条路。它把协议栈下沉到网卡硬件，应用直接和网卡对话。数据从用户态缓冲区到网卡之间尽量减少拷贝，接收方向则是网卡直接把数据放到应用指定的内存区域，跨越内核环节。这就是“内核旁路”和“零拷贝”两个口号的由来。所以很多第一次接触的人会误以为RDMA只是“换一张好网卡”，完全不是。它从软件接口到数据传输模型都跟socket截然不同。

1.2 RDMA解决的是“CPU忙不过来”的问题，不只是一个延迟数字

对RDMA价值，很多人只盯着“时延低”一个指标。没错，在理想环境下，RoCEv2的单向延迟能做到1微秒左右，InfiniBand更低，和传统TCP/IP动辄几十上百微秒相比优势巨大。但真正让存储集群、分布式训练、高性能计算大量部署RDMA的原因，还有更实际的收益：

• 吞吐和CPU解耦：传统TCP在高带宽场景下，为了喂满网卡，CPU占用率会拉得很高。RDMA网卡自己承担数据搬移、重传、报文处理，CPU可以腾出来跑应用逻辑。在数据库、对象存储这类场景，释放的CPU核心能直接摊薄成本。
• 动态队列机制：应用可以发出大量异步请求，不需要每个请求都被内核调度一次。网卡按队列顺序把任务干完，完成后通过完成事件通知应用。
• 数据直接放置：接收端预先指定数据落到哪块内存，网卡写进去就行。对消息分发、键值存储这类“频繁小数据包”场景尤其关键，内核根本不参与。

从这些角度看，RDMA的“基本元素”就不只是几个API，而是整套“应用——网卡——对端”之间的信任模型和工作流程。下面前几个部分，我会把硬件、队列、内存、操作类型这些元素挨个拆开讲，尽量用做过项目的人的行话，同时把新手容易卡住的地方标出来。

2. 第一组基础元素：网卡、协议与三种落地形态

2.1 网卡的角色分三种：HCA、RNIC、通用NIC

搞清楚RDMA，先得明确网卡在系统里的地位。传统以太网卡只是把数据从内存搬到链路上，协议栈跑在CPU里。而RDMA网卡本身就是一台小电脑：它有自己的处理引擎、队列管理模块、缓存和DMA能力，直接在硬件里完成报文封装、解封装、路由、重传、完成通知。

其中InfiniBand网络使用的网卡叫HCA（Host Channel Adapter），它是IB生态的原生网卡，协议栈全都跑在这里。RoCE使用的网卡通常叫RNIC（RDMA-capable NIC），它内部实现了RoCE协议需要的封装和解封装功能，但物理上跑的仍是以太网链路。iWARP同样也是RNIC，只是协议栈基于TCP封装。

区分它们有个实用意义：你从软件层看到的接口都是verbs接口，也就是同一套libibverbs API，但底层行为不一样。比如RoCEv2依赖IP路由和交换机PFC/ECN机制来保证无损，IB则直接用链路级流控和信用机制，两者对网络设备的要求完全不同。我见过不少团队选用RoCE后没在网络侧做配置，结果性能时好时坏，跑大流量时频繁丢包，重传堆起来之后延迟反而比TCP还差。这不是RDMA不行，是硬件形态对应的部署前提被忽略了。

2.2 InfiniBand、RoCE、iWARP三种路线怎么选

RDMA目前有三种主流实现，本质上是同一套“远程内存访问”思想落在了不同链路上。对比如下：

选型建议很直接：如果你的网络是新规划，预算允许，而且对延迟有极致要求，直接InfiniBand。如果是要在已有以太网体系里插上RDMA能力，RoCEv2是当前绝对主流，几乎所以大厂网络和存储都在往这个方向走，NVIDIA、Mellanox、Broadcom这些厂商的网卡都对它做了大量优化。iWARP现在明显边缘化，主要留在老设备兼容或跨IP网络场景，新项目一般不求它。

2.3 协议栈要点：IB BTH与RoCEv2报文封装

这一层如果略过不聊，后面看协议字段或者抓包时会懵。IB网络里数据在链路上传输时，报文由本地路由头（LRH）、全局路由头（GRH）、基础传输头（BTH）等组成。BTH是传输层头，携带目的QP号、操作码、分组序号（PSN），这是接收端判断数据顺序和是否需要重传的关键字段。IB网卡硬件会根据这些字段完成报文路由和分发，所以CPU根本不需要看到这些头。

RoCEv2的报文结构可以粗暴地理解成：以太网头 + IP头 + UDP头 + IB BTH + 实际载荷。为什么要塞到UDP里？因为传统以太网交换机会基于IP和UDP端口做转发、ECMP负载均衡。RoCEv2用UDP目的端口号4791来标识RoCE流量，交换机可以通过这个端口识别它并应用PFC、ECN等拥塞控制策略。我建议你抓一次RoCEv2的包看看，哪怕只是跑个perftest，眼见为实之后比看十篇文章都有用。

3. 第二组基础元素：QP、CQ与Verbs，软件侧的主要骨架

3.1 Verbs只是操作RDMA网卡的“系统调用”

很多新手一看到“Verbs”这个词就发怵，其实它没那么玄。可以把Verbs理解成一套统一的API规范，定义“应用怎么向网卡提交任务、怎么感知任务完成”。Linux下有libibverbs，上游项目是rdma-core，里面包含libibverbs、librdmacm、相关工具和内核模块，是当前RDMA编程的事实标准。

使用这套API的基本流程永远是固定的：获取设备列表、打开设备、创建QP、修改QP状态、提交WQE、轮询或等待CQE、销毁QP。不管底层是IB还是RoCE，这套流程都一致，这也是为什么很多代码可以在不同网卡上直接跑通。你开发时只需要链接-libverbs和-lrdmacm，写起来并不比socket复杂太多，但思维模型要从“流式读写”切换成“队列任务”。

3.2 QP是通信的基本单元，一个QP就是一条逻辑连接

QP（Queue Pair）是RDMA里最核心的对象，它由一对队列组成：发送队列（SQ）和接收队列（RQ）。数据发送走SQ，数据接收走RQ，还有关联的完成队列（CQ）负责存放完成事件。用一个不一定精确但很形象的例子：QP就像两个人之间拉了一条专用管道，管道两端各有一个入口和出口，发送方的SQ出口接到对端RQ入口，数据不需要中间人转交。

QP有类型，最常用的是RC（Reliable Connection，可靠连接）。RC是面向连接的，提供可靠传输、按序投递、重传、流控，绝大多数RDMA读写在RC上跑。UC（Unreliable Connection）适合可容忍少量丢包的低延迟场景，但实际部署用得少。UD（Unreliable Datagram）是一种不可靠的报文模式，类似UDP，适合多对一的广播或服务发现场景。XRC（Extended Reliable Connection）主要用于HPC里的多对多通信优化，普通业务先不用管。

创建QP的过程有一堆参数但不难。简单说需要：设备上下文、完成通道、PD保护域、发送和接收队列深度、支持的QP类型、以及初始状态。之后通过ibv_modify_qp把QP状态从RESET推到INIT，再推到RTR（Ready to Receive），最后推到RTS（Ready to Send）。这个状态推进过程很关键，每一段都要填对应的属性，很多人第一次写代码就卡在这里。报错通常是invalid QP state或invalid modify QP attribute，那是因为状态迁移时少填了qp_attr_mask对应的字段，比如RTR之前必须先设置对端QP号、本端PSN、对端GID等。

3.3 CQ与完成事件：异步收发的“邮箱”在哪

QP决定数据怎么收发，CQ决定怎么知道“收完/发完了”。完成队列（Completion Queue）里存着完成事件（CQE），一个CQE对应一个已经完成的WQE，无论是成功还是失败，网卡都会往CQ里放一条记录。应用要主动去轮询CQ，调用ibv_poll_cq取CQE。CQE里包含状态、QP号、操作类型、字节数、用到的WC字段，这些是判断收发结果的主要依据。

这跟libevent、epoll这类异步模型的核心差别在于：RDMA不依赖内核帮你回调，而是网卡硬件直接通知。你可以通过ibv_create_comp_channel创建一个完成通道，然后让CQ与通道绑定，再通过ibv_get_cq_event等待事件；也可以简单点，直接轮询ibv_poll_cq。我在生产项目里两种模式都试过，纯粹的轮询在高频场景下CPU开销低且代码简单，事件通知模式在空闲场景下更省CPU。选哪种取决于你业务的空闲比例。

这里要特别提醒：CQ与QP是多对多关系，一个CQ可以服务于多个QP的完成事件。QP深度和CQ深度要配好，如果CQ太浅，事件堆积时队列满了网卡会报错误，常见的表现是CQ overrun错误，数据明明已经到达但应用感知不到，排查起来很隐蔽。

4. 第三组基础元素：内存注册、PD、AH与GID/LID，让网卡能碰你内存的关键

4.1 为什么要先注册内存：让网卡知道“物理内存到底在哪儿”

熟悉传统socket编程的人刚接触RDMA，最容易犯的第一个错误就是：直接拿一个malloc出来的内存缓冲区去ibv_post_send。结果大概率是网卡报错，数据没发出去。原因在于：网卡要做DMA，但它看到的是物理地址，不是虚拟地址。而操作系统的虚拟内存是随时可能被换页、迁移的——用户的buffer页被换出内存，网卡去访问时就拿到错误的物理页甚至访问违规。

所以RDMA要求应用先向网卡“登记”一块内存，叫内存注册。注册时系统会做两件事：一是把这块虚拟内存对应的物理页面固定住（可以理解为pin在内存里，不允许换出）；二是生成一个映射关系，让网卡知道在这块内存上DMA应该瞄哪些物理地址。注册完成后，你会得到两个关键值：lkey（本地key）和rkey（远程key）。这两个key相当于“通行证”，硬件在访问这块内存时要校验它们。

4.2 MR、lkey/rkey与PD保护域，它们组成了一套防护体系

内存注册后得到的对象叫MR（Memory Region）。MR可以在创建时指定权限：本地写、远程读、远程写、原子操作等。远程访问权限尤其要小心——如果给远端开了远程写权限，远端就可以直接写你本地的这块内存，一旦对方程序有bug或恶意代码，后果远比普通网络协议严格。所以生产环境里，MR权限要按最小化原则给，跨租户场景务必通过PD隔离。

PD（Protection Domain）是进一步隔离用的。简单说，不同PD之间不允许交互，QP、MR、AH都必须属于同一个PD才能相互使用。比如你有两个租户都跑在同一个物理机上，让他们的QP各自用不同PD，MR也分别创建在不同的PD里，硬件层面就不会互相访问到对方的资源。很多人在学习阶段没感受到PD的存在感，但做多租户服务时，这个字段就是你安全边界的一部分。

4.3 AH地址句柄与GID/LID：怎么描述“对端是谁”

数据从本端发出去之后，网卡得知道要把报文投递到哪个端口、哪个设备。这部分靠的是AH（Address Handle）和GID/LID。AH描述的是“从本端到对端的一条单跳或多跳路径”，里面包含远端GID、本地端口等信息。在UD（不可靠数据报）模式下发送数据前需要先创建AH；在RC模式下，AH更多地用于ibv_modify_qp时的路径设置和连接属性中。实际开发中，只要建立RDMA连接，你几乎必然要和GID打交道。

GID（Global ID）本质上是IB/ RoCE节点的128位全局地址，类似IPv6的格式。RoCEv2里，GID实际就是从网卡拿到的IPv6地址或基于GID索引的设备标识。LID（Local ID）是16位的本地标识，只在IB子网内有效。为什么要分两个？因为IB生态里既有子网内短地址路由，又有跨子网全局路由。在RoCE场景里GID更重要，因为RoCE本来就是在以太网基础设施上跑的，GID和IP紧密相关，交换机和网卡都靠它来路由。RDMACm建链时，双方交换的信息里就包含GID和QP号，对端拿这些信息填写自己的AH和QP属性。

4.4 这块最容易踩到的实战坑：不注册、乱注册、注册了不释放

我见过的坑主要就三类。第一类是不注册直接用普通buffer，这个上面说过了，会直接失败或数据错乱。第二类是注册粒度不对：有些人图省事，把整个程序的大内存池一次性注册成一个巨型MR，看起来方便，但每次更新数据都要靠sync操作，还可能触发大量页表开销；有的则每次小消息都注册一块新MR，注册操作本身是同步的，锁页和分配key的开销在小报文高频场景会被放大。比较稳妥的做法是：预分配一块足够大的内存池，在上面做多次内存注册，或者只注册一次，配合偏移量复用同一MR。第三类是忘了释放MR或销毁QP时没有先释放状态依赖，导致资源泄漏和后续分配失败。这类问题难查，因为现象一般出现在很久以后——应用莫名其妙创建不出新的QP或注册不了内存。

5. RDMA操作的四种基本形态：Send、Write、Read与原子操作

5.1 Send/Recv：最传统、最保险的“消息传递”模型

RDMA并不只有远程读写，最基本的操作其实是Send和Recv。Send的操作模型是：发送端把WQE投到SQ，指定要发送的本地缓冲；接收端提前把一个Recv WQE投到RQ，并且指定一块接收缓冲。发送端网卡发出数据，接收端网卡把数据放进预先部署好的缓冲里，然后两端各自产生一个完成事件。这个模型跟传统消息队列很像，最大优点是对端内存管理非常简单：接收方完全掌控什么数据落到哪里。Send/Recv是唯一在不可靠QP上也能用的操作方式，也是所有RDMA编程的入门必修课，因为只有理解“投递WQE-完成CQE”的循环，才能理解后面单边操作的差异。

5.2 RDMA Write：单边写，把数据推给远端，不需要远端排队接收

RDMA Write是单边操作，意味着接收端完全不需要预先提交Recv WQE，也不需要在数据到达时介入。发送端只要知道对方的rkey和远端内存地址，就可以直接把本地数据写到对方指定的地址。接收端拿到数据后，能不能知道自己被写了，取决于发送端是否额外带了一个名为“立即数”的字段、或者接收端事先在CQ上做了处理，否则接收端的应用可能完全感知不到数据变化。

这个特性在分布式存储场景特别有用。比如SLOG（分布式日志）节点可以用RDMA Write把日志写入远端内存，写完之后远端应用直接读自己内存就行，省掉了传统“请求-响应”模式里接收端频繁进入内核和拷贝数据的开销。代价是接收端必须明确信任发送端——既然对方可以直接写你的内存，内存权限和PD隔离就变得尤其重要。另外RDMA Write完成事件只发生在发送端，不会自动通知接收端，如果需要接收端感知写入完成，还得额外补一个Send消息或者用带立即数的方式触发完成通知。

5.3 RDMA Read：单边读，把远端数据拉回本地

RDMA Read刚好和Write相反：本地主动发出一个Read WQE，远端网卡直接读取对端内存里的数据，通过网络返回给本端。这个过程接收端同样不需要投递Recv WQE，对端CPU也感知不到。和RDMA Write一样，Read也需要知道对方的rkey和虚拟地址。对应到具体场景，分布式锁服务可以用Read去轮询一个共享内存状态位，避免每次都经过应用协议栈；数据库集群里刷脏页时，也可以从对端内存中直接拉取数据，省去全套RPC编解码开销。

需要提一句：RDMA Read的完成语义比Write更严格，它必须确认数据已经完整拉到本地才产生完成事件。所以在某些距离远、丢包率高的链路上，大量Read操作遇上需要重传时会占用较多中间缓冲区，配置不当可能影响QP队列深度和性能。生产环境建议在基准测试阶段就用perftest里的ib_read_lat、ib_read_bw单独压一下读写场景的差异。

5.4 原子操作：精确到“比较并交换”的远程内存操作

RDMA的原子操作有两条：Fetch-and-Add（原子加）和Compare-and-Swap（比较并交换），它们可以直接在远端网卡上对远端内存执行读改写，而且整个过程对远端CPU透明。这个东西在分布式锁、计数器、全局序号分配这些场景非常实用，因为你可以直接用硬件在单条链路上完成“我需要在远端计数器上+1并拿到旧值”这个逻辑，不用做两轮消息交互。但也有限制：只有一小部分网卡型号和QP配置里开了原子操作权限的MR才允许。很多网卡要求原子操作的目标地址按8字节对齐，未对齐会直接报错，这是个很隐蔽的坑。另外，原子操作对网络质量和远端网卡实现依赖高，跨机房有损链路下性能可能并不理想，不要为了炫技把它用在跨数据中心的场景里。

5.5 四种操作的场景选型：一张表格帮你做决定

选型逻辑并不复杂：如果消息很短、需要对方感知并且顺序敏感，用Send；如果是持续大数据块、接收端不希望被打扰，用Write；如果需要拉取远端数据并校验完整性，用Read；需要原子更新共享状态时，再考虑原子操作。

6. 一个连接的前世今生：从建链到收发结束，完整生命周期走读

6.1 连接建立：不想造轮子就选RDMA CM，想偷性能可以手动管状态机

RDMA连接建立有两种方式。最简单的是用CM（Connection Manager），也就是librdmacm库。rdma_create_id、rdma_listen、rdma_connect、rdma_accept这套流程和socket编程几乎一一对应，底层自动处理了地址解析、QP状态迁移和连接属性交换，推荐所有新手先从这个入手上手。在高吞吐服务端，有人为了省掉CM层额外的开销会手动创建QP、手动交换QP号和GID信息，但代码量和复杂度明显上升，除非你确实遇到连接建立性能瓶颈，否则不建议一上来就手动管理。

以CM方式建连举例，链路建立后两侧分别拿到了对方的QP号、GID、PSN等信息。RC模式下，把这些信息填进ibv_modify_qp，把QP状态推到RTR，再推到RTS之后，双方就可以开始收发。建链阶段常见的报错是connection timed out或qp setup failed，多半是防火墙或交换机禁用了CM用的端口，或者GID配置不对。

6.2 数据收发：填WQE、敲响门铃、等CQE，这个循环就是RDMA的日常

连接建好后，发送数据的操作序列大致是：先从内存池里挑一块注册过的buffer填上要发的数据，然后构造ibv_send_wr结构体，指定QP号、操作类型（IBV_WR_SEND或IBV_WR_RDMA_WRITE）、SGE列表、以及本端lkey；再用ibv_post_send把它投递到SQ。这里有个叫“doorbell”的机制值得留意——你提交完WQE之后，应用向网卡写一个寄存器值，通知它“SQ里有新任务”，这个写寄存器的动作就是doorbell。网卡收到doorbell才会扫描WQE并执行。所以post_send的语义是“把任务挂到队列并按门铃”，不是“立即发送”。

接收方向类似：应用先准备接收缓冲，用ibv_post_recv投递Recv WQE到RQ。数据到达时网卡自动把载荷放入对应的SGE里，然后往CQ放一个CQE。应用侧通过ibv_poll_cq拿CQE，检查状态字段里的IBV_WC_SUCCESS，再根据里面的字节数决定怎么处理数据。如果状态是错误码，一定要打印CQE里的vendor_err字段，很多硬件特有错误靠它才能定位，通用错误码往往太模糊。

6.3 断开与资源回收：销毁QP不等于放过内存，顺序和异步都要注意

连接结束或异常时，释放资源的顺序很有讲究。推荐顺序是：调用CM断开连接（或手动修改QP状态到ERROR），然后轮询CQ把残留CQE处理掉；再销毁QP、销毁CQ、注销MR、释放内存池；最后关闭设备。这一步很多人会忘掉“轮询残留CQE”，导致销毁QP时内核报device busy或者CQ上还有pending完成事件。原因很简单：QP在销毁前如果还有未确认的WQE，网卡可能在等你的应用来处理完成事件。先清CQ再销毁QP，能省掉很多你看不懂的报错。

另一个容易忽略的是“异步错误事件”。QP在链路上遇到对端重启、链路切换等异常时，网卡会触发异步事件，应用需要注册ibv_async_event的处理函数。如果没监听异常事件，一旦远端网络抖动，你的QP可能已经进入ERROR状态，而应用还在傻等CQ里的数据完事件。生产级代码必须把连接状态监控事件队列这条路径补上，不能只依赖CQ轮询。

7. 新手入坑实操建议：perftest起手、常见报错排掉、社区资源怎么看

7.1 先跑通loopback和本机双端，perftest是验证环境的最好工具

无论你以后是开发自研存储还是只做运维，第一件事应该是把环境验证跑通。找一个装好rdma-core和网卡驱动的机器，先用ibv_devinfo查看设备状态，确认端口link层、端口状态、gid数量都正常。然后跑perftest，自带的一堆工具能帮你快速验证基础能力：

• ib_send_bw / ib_send_lat：Send操作带宽和延迟基准
• ib_write_bw / ib_write_lat：RDMA Write基准
• ib_read_bw / ib_read_lat：RDMA Read基准
• ibv_asyncwatch：监控异步事件，查问题利器

两台机器之间测试时，注意server端先起，client端再连。如果跑在RoCE环境，千万别忘了在交换机的出口端口上配置PFC和无损队列，同时网卡和交换机都打开ECN。这一步不做，测试数据可能一开始还好，一旦带宽上去立刻出现大量重传，延迟曲线像心电图一样上下跳。这不是代码问题，是网络质量问题。

7.2 常见报错和排查思路：把每次警告信息当线索，不要只盯着内核日志

RDMA调试初期，报错主要集中在三处。

第一是ibv_post_send返回非零，最常见的错误码是ENOMEM，说明WQE队列满或者CQ空间不足。检查代码是不是没有及时poll CQ回放WQE槽位，或者QP/CQ的深度配得太小。

第二是CQE的状态是IBV_WC_REMOTE_INVALID_REQ_ERROR，这个很典型，说明远端收到的请求里携带了非法的rkey或者远端地址不可访问。最常见原因是服务端只注册了MR但没有给客户端传正确的rkey，或者MR权限没开远程写/读。先检查双方交换的rkey和地址是否和你注册时的输出一致，再检查PD是否匹配。

第三是连接建立阶段报ENODEV或ETIMEDOUT。优先检查IP和路由可达性，看GID index是否和当前网卡IP匹配。RoCEv2尤其要确认ibv_devinfo里的GID编号和ip addr里的IP网段对应，很多环境配置了多个IP和多个GID，索引取错了就不通。再检查两端是否在同一个子网，或至少三层可达。

调试窗口别只盯着dmesg，ibv_devinfo、iblinkinfo、ibv_asyncwatch和perftest -d组合起来信息更完整。我还建议在代码里对所有verbs调用做一次封装，统一打印返回值和对端的rkey地址，定位起来会快得多。

7.3 社区与学习资料：该看哪些地方获取内容

RDMA的资料相比普通网络编程少，但集中起来也就几个优质源，值得长期跟进。

一个是OpenFabrics Alliance，它是RDMA技术背后的行业协会，主导了verbs规范和rdma-core的演进方向，很多规范和邮件列表都值得订阅。另一个是Linux内核的RDMA子系统邮件列表linux-rdma，内核本身的RDMA驱动和核心模块讨论都在那里，想追踪新驱动或踩到内核级bug时非常有用。rdma-core的GitHub仓库和issue区也值得翻，很多开发者在里面讨论API细节和踩坑经验，比一般的stack overflow回答更贴近实际。

设备厂商的文档也很重要，Mellanox/NVIDIA的官方文档和开发者博客对RoCE、InfiniBand、性能调优写得非常系统，尤其是他们的性能调优手册和RoCE配置指南，几乎可以当作部署手册用。如果愿意啃英文资料，IB规范（InfiniBand Architecture Specification）和RoCEv2协议规范（IBTA RoCEv2 Specification）是终极权威，虽然篇幅大，但对“为什么会有这个字段”的疑问能给出最底层的回答。中文社区里，Linux存储和网络方向的大会分享、各家云厂商的RDMA实践文章也值得看，不过建议带着自己的问题去检索，因为不少文章互相抄，细节可能有出入。

我自己刚开始学RDMA那会儿，走了一段弯路：先扎进协议规范和源码，看得云里雾里，后来才发现应该以实际跑通一套收发和读写为目标，再回头补原理，效率高很多。所以建议你也务实一些，先把perftest跑起来，把libibverbs的示例代码改一版属于自己的send/recv通信，再去研究状态机、内存注册这些基础元素，最后深入协议和社区讨论。这套“元素拆解——跑通基础——深入细节”的学习路径，目前来看是投入产出比最高的走法。