1 RDMA 原理要回答什么
机架里有 2 台服务器，每台装有 CPU、256 GiB 内存、若干 NVMe SSD，以及 1 张 100 Gb/s 网卡。现在，服务器 A 上的计算进程需要读取服务器 B 内存中的 64 KiB 数据。数据已经在 B 的内存里，SSD 此时不参与传输。问题是：这些字节经过哪些硬件，谁负责搬运，CPU 需要做多少工作，应用又凭什么知道数据已经可用？RDMA，也就是远程直接内存访问，围绕这些问题重新安排了职责。
常见的套接字通信路径中，应用通过操作系统提供的接口收发数据。内核协议栈负责连接、缓冲和协议处理，网卡通过 DMA 在主机内存与设备之间搬运数据。具体实现可能采用批处理、卸载或减少拷贝的优化，因此不能把所有普通网络通信都描述成相同的固定拷贝次数。RDMA 的特点是：应用预先建立受保护的内存与队列，之后由具备 RDMA 能力的网卡执行数据传输，让每次传输的数据路径减少对内核协议栈和远端 CPU 的依赖。
这里的“直接”有明确边界。数据仍要穿过主机内存系统、PCIe、网卡、线缆和交换机；它没有绕开物理硬件，也没有把远端内存变成本机内存条。A 的 CPU 不能因为启用了 RDMA，就对 B 的普通地址执行任意加载指令。应用提交的是带地址、长度和权限信息的操作，网卡根据已经建立的资源执行它，访问范围受限制。错误的权限、过期的资源或断开的链路仍然会使操作失败。
把机箱打开看，网卡通常通过 PCIe 插槽或板载连接接入 CPU 所在的平台。网卡到哪颗 CPU 更近、缓冲区分配在哪个 NUMA 节点、PCIe 链路实际协商成多少通道，都会影响结果。例如，标称支持 PCIe 4.0 x16 的网卡如果实际运行在 x4，主机侧可用带宽就可能先于网络端口耗尽。2 个端口共享同一 PCIe 连接时，还要核算它们同时工作的总流量。
因此，本课既要说明“如何少搬几次、少打扰几次 CPU”，也要说明代价转移到了哪里。内存需要预先准备，应用需要管理缓冲区生命周期，网络需要满足所选传输方案的前提，运维需要能看见队列和拥塞。RDMA 可以帮助计算集群交换张量、帮助存储系统传送数据，也可以用于其他低延迟通信；它不是插上新网卡就自动生效的服务器加速开关。
读完本课，应当能够沿着数据路径指出 CPU、内存和网卡的职责，区分发送完成与业务处理完成，并用测试证据判断瓶颈出在主机还是网络。对更深的协议状态机和芯片内部实现，我们只保留理解现象所需的边界。
2 旁路、队列对与完成
“内核旁路”首先描述正常数据传输时走哪条路径。应用仍要借助操作系统和驱动打开设备、申请资源、注册内存、配置权限，并处理资源释放等工作。在这些准备完成后，应用通常可以通过用户态接口向网卡的工作队列提交请求，避免每个请求都经过传统内核网络协议栈。旁路减少了路径上的处理环节，并不意味着应用失去操作系统的保护，或者设备能随意访问整台机器的内存。
准备缓冲区时，应用会把一段内存注册成内存区域，通常称为 MR。常见方式会固定相关内存页，并建立设备可用的地址转换与访问权限；某些平台也支持不同的按需机制，本课不展开。注册可能涉及较高的初始化成本，因此经常复用已经注册的缓冲池。申请了 256 GiB 内存的服务器，并不代表应用可以不加限制地注册其中所有空间，还要考虑系统可锁定内存限额和设备资源。
内存区域会关联访问键。应用用本地键说明本地缓冲区可由设备访问；需要远端访问时，还要通过受控渠道提供远端地址、远端键和长度等信息。远端地址是约定上下文里的访问标识，不是可以在其他机器任意使用的万能地址。远端写权限也不应随意开放给整个内存池。资源释放或重新注册后，旧信息必须退出使用，不能假设数值相同就代表对象仍然有效。
队列对，简称 QP，把发送队列和接收队列组织在一起。应用提交工作请求，由网卡消费并执行。发送队列可承载发送、RDMA 写、RDMA 读等操作，具体能力取决于传输类型。接收队列提供用来承接消息的缓冲区。普通 Send 必须有匹配的接收资源；普通 RDMA Write 则根据远端授权地址直接放置数据，通常不消耗远端接收请求。不能把这 2 条路径混为一谈。
完成队列，简称 CQ，用来交付完成记录。应用可以轮询完成队列，也可以在合适的模式下使用事件通知。轮询有机会减少唤醒延迟，但可能让 CPU 核持续忙碌；事件方式节省空闲时的 CPU，却可能增加等待和调度开销。队列里的完成状态还可能是错误，例如远端访问权限错误。应用必须检查状态，不能只统计“取到了多少条记录”。
完成的含义尤其值得停下来辨认。成功的本地发送完成通常允许应用按接口规则回收相应的本地资源，但不能据此声称远端业务已经处理了数据。普通 RDMA 写也不会自动向远端应用交付常规接收完成；远端如何得知新数据可读，需要额外设计通知和同步。RDMA 读成功完成后，本地应用才能按相应规则使用读回的数据。不同操作、传输类型和通知方式的保证不同，应按接口约定理解。
把缓冲区想成贴有用途标签的工作台会更清楚：提交请求后，在设备仍可能访问这块空间期间，应用不能提前覆盖或释放它。等到允许回收的完成到达，再交还给缓冲池。为了减少完成记录，某些请求可以不单独报告成功完成，但这要求应用有正确的批量回收规则。入门实验先让每个请求报告完成，更容易看清生命周期。
3 可靠连接与不可靠数据报
RDMA 是访问与通信能力的统称，具体传输类型决定了请求能做什么、出现丢包后由谁处理。本课先认识可靠连接 RC 和不可靠数据报 UD。它们都涉及队列与完成，但提供的服务不同；不能因为名称里都有 RDMA，就认为任意队列都能执行远端读写，也不能把“可靠”理解成服务器永远不会出故障。
RC 为通信端点建立连接关系，提供有序、可靠的传输服务，常见的 Send、RDMA Read 和 RDMA Write 都可以在这种类型上使用。链路上偶发丢包时，底层传输机制会依据协议处理确认和重试，应用通常不必为每个包自行实现重传。不过重试有上限，设备故障、持续断链或远端进程退出仍会导致错误。应用需要检查完成状态，并把传输失败交给自己的恢复流程。
UD 面向数据报，不建立 RC 那样的端点连接关系，通常用于 Send/Receive 消息传递，不支持普通 RC 式的远端读写能力。它不保证消息可靠到达，也不提供 RC 那样的有序交付保证；消息大小还受路径 MTU 等条件限制。若业务需要可靠消息，就必须在上层补充编号、确认、重试或其他机制。UD 适合某些可以接受丢失的小消息场景，不能只因连接管理看起来轻，就直接替换现有可靠数据通道。
“连接”也会消耗资源。假设 64 台机器上的某个服务让每台机器与其余 63 台各建立 1 条 RC 通信关系，那么每台都要维护相应端点及状态。实际进程数量、线程模型和通信拓扑还会继续放大或改变资源需求。这个例子不是在推荐固定连接数，而是在提醒：带宽之外，网卡上下文容量、队列数量和应用的管理成本也会影响扩容。
还要把传输类型与网络承载分开。InfiniBand、RoCE 和 iWARP 是理解 RDMA 部署时常见的名称。RoCE 把 RDMA 放在以太网上，其中 RoCEv2 使用 UDP/IP 封装，便于在相应网络中转发；这里出现 UDP，不意味着上层选择的 RC 服务变成 UD。iWARP 则以 TCP 为承载基础。这些方案在设备、协议和网络要求上不同，不能共用一张未经核对的配置表。
后面讨论 PFC 的案例针对采用相关配置的 RoCE 网络。不能由此推出所有 RDMA 都必须开启 PFC，也不能由 RC 的可靠性推出以太网可以任意丢包而不影响性能。可靠传输解决的是交付语义，重试造成的延迟、拥塞扩大和队列积压仍然要付出成本。选型时，先列业务需要的操作和失败处理方式，再核对传输类型与承载网络，顺序比记缩写更有用。
4 动手：追踪一次 RDMA 读写路径
准备 2 台有 RDMA 能力的服务器 A、B，连接到支持目标配置的网络。为便于观察，使用 100 Gb/s 端口、PCIe 4.0 x16 网卡连接，以及每端 1 个固定大小的注册缓冲池。记录 CPU 插槽与网卡的相对位置、链路实际速率和 MTU。实验程序采用 RC，并允许显式选择读、写、Send、消息大小和队列深度。具体工具名和参数因环境而异，这里以行为和记录项为准。
先走控制路径。A、B 各自申请缓冲区、注册内存、建立 QP 和 CQ，再通过受控的控制连接交换必要的连接信息。B 如果允许 A 远端访问，就向 A 提供约定缓冲区的地址、长度和权限凭据。把缓冲区划成 64 个槽，每槽 64 KiB，并为每个槽记录编号和使用状态。这样可以观察何时复用空间，也能发现并发请求是否写到了同一个位置。
先做 RDMA 写。A 的 CPU 在本地注册缓冲区中填入数据，内容包含槽编号、递增序号和校验值。随后 A 提交写请求，指定本地地址、B 的目标地址、长度及所需访问键。A 的网卡经 PCIe 从 A 的内存取走数据，将其封装后发往网络；B 的网卡检查访问条件，再把数据放进 B 的指定内存。正常数据放置不需要 B 的 CPU 为每个包执行收取和复制。
接下来观察完成与通知。A 等待成功的写完成，再按设计发送通知；B 在满足该通知方案规定的可见性与同步条件后检查内容，并返回应用确认。为了让入门实验清楚，可以让这套协议每次只处理 1 个槽，收到确认后才复用它。不能把“看到了一个标志值”自行等同于任意平台上的正确同步；正式实现必须采用通信库与平台明确支持的顺序和同步方式。
再做 RDMA 读。先让 B 把测试数据填入已授权的源区域，并通过控制消息说明数据已经准备好。A 提交读请求，指定 B 的源位置和 A 的目标缓冲区。B 的网卡读取 B 的内存并返回数据，A 的网卡把结果写入 A 的目标区域。A 等到成功的读完成后，校验序号和内容。读到的只是一段字节，若 B 同时修改它，RDMA 本身不会自动替应用构造一致的业务快照。
把消息大小依次设为 64 B、4 KiB、64 KiB 和 1 MiB，先固定队列深度为 1，再提高并发请求数量。分别记录吞吐量、平均延迟、p99 延迟、CPU 利用率与校验错误。小消息更容易暴露固定处理开销，大消息更容易接近某段链路的带宽上限。队列深度增大通常有助于填满路径，但过深也会增加等待，不能只保留吞吐最高的那组结果。
测量名称也要写准确。A 从提交读请求到读完成的时间，是该实验定义下的读操作延迟；A 写完再等待 B 应用确认的时间，又包含通知、远端检查和回程。后者更接近一次应用交互，但不应冒充纯写传输延迟。不要在缺少时钟同步和明确测量点时，把 2 台服务器的时间戳直接相减，当成可信的单向延迟。
最后把同一程序改成 Send/Receive 模式，先在 B 提交接收缓冲区，再从 A 发送。比较远端如何被通知、接收资源如何耗尽，以及缓冲区怎样回收。到这里，应当能够画出每段字节在哪里停留，并解释每个完成究竟证明了什么。实验只使用专用测试缓冲区，避免把未完成的访问指向已经释放或承担其他业务的数据。
5 低延迟与部署复杂度取舍
RDMA 的收益常来自减少每次操作的固定开销、减少中间拷贝，以及由网卡承担部分协议处理。对频繁交换小块数据的进程，减少固定开销可能比提高端口速率更有价值；对大块数据搬运，减少 CPU 占用可能使 CPU 留出更多时间做计算。但收益必须相对于实际基线测量：如果原程序的主要时间花在压缩、序列化或等待 SSD 上，换通信接口未必解决主要瓶颈。
先做带宽预算。100 Gb/s 除以 8，对应 12.5 GB/s 的理想线速字节率，实际应用有效载荷吞吐会因协议开销和实现条件降低。64 KiB 纯数据按该理想速率发送约需 5.24 μs，这还不包含软件提交、排队、交换转发和完成处理。因此，这个数只能用来理解量级，不能写成一次 64 KiB 远端读取的实测总延迟。
PCIe 也有独立预算。PCIe 4.0 每通道为 16 GT/s，采用 128b/130b 编码，x16 的单方向编码后理论速率约为 31.5 GB/s，事务开销还会降低实际可用值。单个 100 Gb/s 端口可能尚未占满它，但多端口、双向传输、共享上行与其他设备会改变情况。网卡标称值、插槽机械长度、实际协商宽度和主板内部连接是不同信息，方案要使用实际状态。
内存系统同样可能成为限制。应用填充发送区需要写内存，网卡读取发送区也需要内存访问；接收侧的数据落地与后续计算还会继续消耗带宽。双路服务器中，如果网卡靠近 CPU 0，而缓冲区和轮询线程都放在 CPU 1 一侧，访问可能经过跨插槽互连。把线程、网卡和缓冲区放近通常值得测试，但不能把某次亲和性优化概括为所有主板上相同的固定收益。
延迟与吞吐还会互相牵制。更多在途请求可以让链路不因等待完成而闲置，但它们也可能堆积在网卡或交换机。以理想模型估算，在目标有效速率 10 GB/s、操作往返时间 10 μs 时，需要约 100 KB 在途数据才能覆盖这段等待。这个数仅用于理解带宽时延积，真实读写请求受协议、方向和设备能力影响，不能直接当作通用队列深度配方。
部署复杂度包括应用改造、资源管理、网络配置、升级兼容和故障定位。轮询消耗专用 CPU 核，注册池占用可用内存，连接数量增加设备状态，监控则要覆盖主机和交换机。评价 RDMA 时，应同时列出目标负载下的 p99 延迟、每秒有效数据量、CPU 成本和失败恢复时间。若普通网络方案已经满足目标，而 RDMA 只在脱离实际负载的微基准上领先，就还缺少采用它的证据。
6 常见坑：应用未对齐仍走拷贝
这里的“未对齐”有 2 层含义。第 1 层是地址、长度没有满足某个接口或设备的具体要求；第 2 层是应用的数据组织方式没有对齐 RDMA 的缓冲区与生命周期要求。不能把所有拷贝都归因于地址未按 4 KiB 对齐，也不能声称 RDMA 普遍要求消息长度必须是某个固定倍数。真正限制要查当前接口、设备和所用功能的说明，并用实际路径确认。
例如，应用每次从普通堆内存生成 4 KiB 消息，通信库却只允许从长期注册的缓冲池提交请求。库可能先把消息复制进注册池，再让网卡发送。此时网络传输确实使用了 RDMA，应用路径仍然有这次复制。如果接收侧先把数据落进公共接收池，再复制给计算模块，接收端也有额外搬运。网卡计数器显示 RDMA 流量，并不能证明整个应用实现了零拷贝。
另一种情况出现在消息头和正文分散时。应用为了拼接头部、压缩正文或转换格式，可能临时生成连续缓冲区。某些接口支持分散聚集，但支持的段数、段的注册状态和使用限制都要核对，不能假设可以提交任意碎片。如果后续算法必须把网络格式转换成另一种内存布局，那么这次数据整理可能有其必要性；目标应是识别和量化它，而不是只追求宣传式的“零”。
生命周期错误更危险。若应用提交写请求后立即把发送缓冲区交给另一个线程使用，网卡取数时可能读到新内容，形成间歇性校验失败。若远端释放了区域，发送方仍保存旧远端键，就可能得到访问错误。若接收端没有及时补充接收请求，Send 路径可能遇到接收资源不足并触发相应等待、重试或错误。这些现象需要分别定位，不能统一命名为“网络不稳定”。
还有一种容易误判的短消息优化：某些发送路径允许把少量数据随工作请求内联提交，从而避免网卡再去读取独立的发送缓冲区。这里通常包含 CPU 将数据放入请求的动作，但整体延迟可能更低。因此，少一次 DMA 读取和少一次 CPU 拷贝并不总是同一个目标。要看数据大小、路径与业务指标，不能只数动词里的“复制”。
排查先保存可复现条件：消息大小、队列深度、并发线程、缓冲池大小与亲和性。再用应用统计和 CPU 性能分析找出序列化、内存复制、注册与轮询各占多少时间，并核对实际采用的传输后端。某些库在设备不可用时可能退回其他通信路径，也有些会直接报错；必须确认当前行为。接着查看实际 PCIe 链路、内存访问位置和设备错误计数，最后与网络拥塞证据对照。
修正方式通常是让生产数据的模块尽量直接使用合适的注册缓冲区，明确每个槽的所有者与回收条件，并在需要转换格式时保留可解释的搬运步骤。不要每发一条消息就临时注册和注销，也不要为省初始化时间而永久保留失去权限边界的巨大共享区域。完成修正后，应比较同一负载的 CPU 时间与尾延迟，而不只是确认接口名称发生了变化。
7 案例：PFC 风暴导致整网停顿
考虑一个教学案例：1 个机架内有 16 台双路服务器，通过 100 Gb/s RoCEv2 网络交换计算中间结果，业务流量映射到启用了 PFC 的优先级。PFC 是基于优先级的流量控制，交换机或网卡在某类接收缓冲接近阈值时，可以要求直接相邻的发送端暂停该优先级的发送。暂停针对链路上的优先级，不会精确识别哪个业务请求应该让路。
某次同步计算结束后，15 台服务器几乎同时向 1 台接收服务器发送数据，形成多对一汇聚。接收端出口的服务能力有限，交换机缓冲开始增长。如果拥塞通知与发送端降速未及时抑制流量，相关设备可能触发 PFC。上游暂停发送后，其自身队列又可能积压，进而向更上游传播暂停。结果是许多本来不访问这个接收端的流，也因共享相同优先级与队列资源而受到影响。
用户首先看到的可能不是端口断开，而是任务进度停住、延迟突然拉长、操作超时。链路状态仍为在线，服务器 CPU 甚至并不繁忙。若只看端口是否正常，就容易得出“网络没问题”的错误判断。继续增加请求并发还可能把更多数据留在队列中，让恢复更慢；不停重启业务也会破坏原本可用于定位的时间线。
PFC 风暴不是任意 PFC 帧出现就算故障。少量短时暂停与持续大面积阻塞，需要用持续时间、影响范围及业务指标区分。在这个案例中，应同时观察各端口各优先级的暂停帧与暂停时长、队列占用、吞吐、ECN 标记、端点拥塞反馈和重试等指标。具体计数名称随设备而异，使用前要确认单位以及计数表示发送还是接收。单个累计值很大，也可能只是设备运行时间很长。
证据时间线可以这样组织：在同步发送开始后，目标出口队列先增长；随后相关优先级的暂停时长上升；接着上游多个端口吞吐下降，应用 p99 延迟升高。若这种先后关系能重复出现，就比“换一根线后暂时恢复”更能支持拥塞传播的解释。还要排除接收进程停顿、网卡错误和主机资源耗尽，因为这些问题也可能先降低接收能力，再诱发网络侧积压。
更严重的网络可能形成循环等待，出现 PFC 死锁：不同队列各自等待下游释放空间，却同时阻止了对方继续前进。不过，多对一汇聚并不必然产生死锁，也不应把所有长暂停都标记为死锁。确认死锁需要拓扑、队列依赖和持续不前进的证据。完整分析留给后续课程，本课先掌握“局部拥塞可能沿暂停关系传播”这条因果链。
处置应按照经过演练的网络运行方案限制影响，例如暂停新一轮批量发送、降低发送并发，并定位首先积压的出口。有些网络采用 PFC 看门狗等机制打断长期阻塞，但可能引入丢包，需要应用能够恢复。不能在生产网络里盲目关闭全部 PFC，或把所有流量都塞进同一优先级。长期修正要联动拥塞控制、缓冲阈值、流量分类与容量设计，并在受控环境中重放汇聚场景验证。
8 把 RDMA 前提写进网络方案
一份可执行的方案应先写清目标：服务交换什么数据、典型和最大消息多大、峰值并发怎样出现、允许多少尾延迟、失败后能等待多久。比如“16 台服务器交换 64 KiB 到 1 MiB 的块，存在同步汇聚”，就比“需要低延迟网络”更能指导测试。目标数值来自业务需求与测量，本课的教学规格不能直接变成生产承诺。
主机清单要覆盖服务器形态。单路机、双路机、刀片与高密度节点的网卡接入方式可能不同；有的多个设备共享 PCIe 上行，有的网卡紧邻某个 CPU 插槽。记录 CPU 与内存配置、网卡数量和端口速率、PCIe 代际与实际宽度、NUMA 位置，以及 NVMe SSD 是否共享关键通路。如果数据源最终是存储，还要单独测量存储与预处理，不能用内存到内存测试代表完整的数据链路。
软件与资源前提也必须具体。列明操作系统、驱动、设备固件及通信库的兼容范围，内存注册额度、缓冲池容量、QP 与 CQ 预算，以及轮询线程需要的 CPU 资源。写清进程退出后怎样清理资源，远端权限怎样撤销，连接断开后如何重建。恢复后仍需由业务核对哪些数据有效；重新连上网卡不等于先前的计算状态自动恢复。
网络清单则按实际承载编写。以 RoCEv2 为例，核对路径 MTU、优先级映射、相关队列配置、拥塞通知与端点响应、PFC 的使用范围，以及跨交换机和路由路径的一致性。不同交换机上的分类规则若不一致，业务包可能进入意料之外的队列。MTU 也要沿完整路径检查，不能只看 2 台服务器接口上的数值；路径上的不一致会带来丢包或通信异常。
验收至少包括空载基线、稳定并发、多对一汇聚与受控故障。基线确认设备和程序能工作，并发测试检查容量，汇聚测试暴露共享瓶颈，故障测试检查恢复。结果应把有效吞吐、p99 延迟、CPU 与内存占用、错误和重试放在同一份记录里。链路恢复耗时与业务恢复耗时分别计量，避免把端口重新上线当成业务已经恢复。
权限边界不能留空。远端键应只交给需要访问的对端，授权范围应对应实际缓冲区，控制连接应验证通信对象。RDMA 访问凭据不应被当作传输加密，也不能代替租户隔离。多人共享设备或服务器时，要明确谁能申请资源、谁能看到控制信息、何时使旧权限失效。这是把内存交给外设和远端访问时必须承担的资源管理责任。
最后在方案里写下回退条件：何种延迟恶化、错误频率或持续暂停会触发限流、停止任务或切换已验证的备用路径，切换后怎样保持数据正确。备用路径是否存在、是否支持相同语义，应先验证。方案的价值不在于承诺永不失败，而在于让硬件、网络、应用与值班人员对失败后的行为有共同预期。
9 从RDMA 原理走向无损以太网（H43）
到这里，可以把 RDMA 看成建立在受控资源上的设备协作：CPU 准备数据和请求，注册内存界定可访问区域，队列组织待执行工作，网卡跨网络搬运字节，完成记录与应用协议共同界定何时可以继续。它缩短了某些常见通信路径，却没有取消带宽、排队、权限与生命周期这些基础约束。远端 CPU 可以不参与每次数据放置，仍然需要负责应用逻辑和正确的状态交接。
这也解释了为什么低延迟应用对网络条件敏感。一次重试的时间可能超过原本节省的处理时间；一个共享队列的积压可能影响许多连接；一次错误的优先级映射会让相同程序在不同路径上呈现完全不同的表现。主机微基准很好看，只能证明特定条件下的一段路径，不能证明整座机架在汇聚或故障时也符合目标。
H43 将继续讨论无损以太网。这里的“无损”不是任何故障下都绝不丢包的物理承诺，而是针对特定业务类别、配置与运行条件，通过缓冲和流量控制等机制减少拥塞丢包的工程目标。链路中断、设备故障和配置错误仍然可能造成失败；过度依赖暂停还可能把丢包问题转化为长时间等待。评价网络必须同时看丢包、延迟、吞吐和恢复。
接下来要追问的是：交换机什么时候通知发送端减速，什么时候暂停相邻链路，缓冲空间如何给控制动作留下时间，以及多个控制机制如何协同。ECN 用标记传递拥塞信息，发送端需要相应机制降低注入速率；PFC 则对相邻链路的特定优先级实施暂停。两者的控制范围和作用不同，不能因为都与拥塞有关就互相替代。阈值、时序和拓扑分析将在 H43 展开。
带着本课的因果链进入下一课，会更容易判断配置的目的：注册内存解决访问准备，队列解决请求组织，完成解决操作状态，而网络控制解决拥塞时数据如何继续前进。遇到异常时，先指出哪条保证没有成立，再寻找对应证据。这样既不会把所有故障都归咎于网卡，也不会把“开启无损”当成无需容量规划和应用恢复的理由。
放进方案里
把 RDMA 写进方案时，先给出真实负载与边界：服务器数量、消息大小分布、读写比例、并发峰值、汇聚方式，以及业务允许的 p99 延迟和恢复时间。说明数据是在内存中生成，还是必须先从 NVMe SSD 读取，分别给出通信路径与完整业务路径的测量。微基准成绩只能作为通信能力的证据，不能替代业务验收。
硬件部分列明 CPU 插槽、内存容量与位置、网卡端口、实际 PCIe 代际和通道宽度，并标注共享上行。应用部分写清注册池大小、缓冲区所有权、完成检查、远端通知与权限撤销。说明何时允许复用发送区，接收端何时确认数据有效，进程重启后如何拒绝旧访问凭据。任何必要的格式转换与内存拷贝都应计入成本。
网络部分明确采用的承载和传输类型，并给出路径 MTU、优先级映射、拥塞控制及 PFC 使用范围。为汇聚和持续暂停设置监测项，记录队列占用、暂停时长、吞吐、错误与应用延迟之间的时间关系。若选择备用通信路径，写明它的性能、语义与切换条件，避免故障发生后才发现无法承接现有请求。
验收使用正常负载、多对一汇聚和受控链路中断，分别检查有效吞吐、尾延迟、CPU 成本与数据正确性。每个测试槽携带序号与校验值，验收要求已确认数据无错写、无提前复用；断链时未确认的请求列为待核对，不能仅凭本地完成认定业务成功。在专用测试区域撤销远端访问权限后，验证旧键访问被拒绝，并保存完成状态和目标区内容作为证据。回退步骤明确到限流、停止新请求、确认在途数据和恢复服务的责任人。最终采用依据应是目标负载下的收益足以覆盖应用改造和运维成本，而不是单独的端口标称速率，或无法说明测量边界的低延迟数字。
10 小结：下一步无损以太网（H43）
RDMA 用注册内存、工作队列和设备执行缩短数据路径。理解它要同时检查 3 件事：字节经过哪些硬件，操作完成提供什么保证，应用怎样交接缓冲区。可靠传输、内核旁路与零拷贝分别回答不同问题，不能互相代替。
自测时试着解释：为什么写完成后还需要应用通知？为什么使用了 RDMA 仍可能出现内存复制？为什么端口在线而任务没有进度？若能分别指出完成语义、缓冲区路径和拥塞证据，就已经具备进入 H43 的基础。
下一步将围绕 ECN、PFC、交换机缓冲与拥塞传播，讨论无损以太网如何建立运行前提，以及怎样避免把局部拥塞扩大成更大范围的等待。