【网络工程】RDMA 与 CXL：两条不同的绕开 CPU 路线

在数据中心场景里，“绕开主机 CPU 做数据搬运”这件事被反复重新发明。RDMA 走的是网络方向：让远端节点的 DMA 引擎直接读写本机内存。CXL 走的是总线方向：让 PCIe 物理层之上承载缓存一致的内存语义，把”内存”从主板边界扩展到整个机架。两者经常被拿来对比，但工程上其实定位完全不同——RDMA 是远端访问协议，CXL 是本地一致性域的扩展。

本文不试图说”未来属于哪个”，而是把两者的语义、物理层、一致性模型、失效模式与工程边界放到同一张表里对比，让读者下次在选型会议上能说清楚”这件事 RDMA 能做但 CXL 不能”或者反过来。

参考规范：IBTA InfiniBand Architecture Specification Vol. 1 Release 1.7（2024）、IETF iWARP 相关 RFC（RFC 5040 / 5041 / 5044）、CXL Consortium Compute Express Link Specification Revision 3.1（2023-11）。

一、先看图

flowchart TB
    subgraph H1["Host A"]
        CPU1[CPU + Cache]
        MEM1[本地 DRAM]
        NIC1[RNIC / HCA]
        CPU1 --- MEM1
        CPU1 -.PCIe.- NIC1
    end
    subgraph H2["Host B"]
        CPU2[CPU + Cache]
        MEM2[本地 DRAM]
        NIC2[RNIC / HCA]
        CPU2 --- MEM2
        CPU2 -.PCIe.- NIC2
    end
    NIC1 ==RDMA: IB / RoCEv2 / iWARP==> NIC2
    NIC2 ==RDMA==> NIC1

    subgraph RACK["Rack-level CXL fabric"]
        H3[Host C<br/>CXL Root]
        CXLSW[CXL Switch<br/>CXL 2.0+]
        MEMPOOL[CXL Memory Device<br/>Type 3]
        ACC[CXL Accelerator<br/>Type 2]
        H3 ==CXL.io / .cache / .mem==> CXLSW
        CXLSW ==CXL.mem==> MEMPOOL
        CXLSW ==CXL.cache + .mem==> ACC
    end

    classDef host fill:#388bfd22,stroke:#388bfd,color:#adbac7;
    classDef link fill:#f0883e22,stroke:#f0883e,color:#adbac7;
    classDef pool fill:#3fb95022,stroke:#3fb950,color:#adbac7;
    class CPU1,MEM1,NIC1,CPU2,MEM2,NIC2,H3 host
    class CXLSW link
    class MEMPOOL,ACC pool

两个子图刻意分开画：

• 上半是 RDMA：两台机器各有独立的一致性域，RNIC（RDMA-capable NIC，IB 里也叫 HCA）通过 IB/Ethernet/IP 物理链路把”远端 DMA”传过去。CPU 几乎不参与数据搬运，但两端各自的 cache coherence 域并没有合在一起。
• 下半是 CXL：一个或多个主机通过 CXL Root + Switch，与远端的内存设备 / 加速器组成同一个或可受控扩展的一致性域。物理层仍然是 PCIe 的 PHY，但协议栈是 CXL 自己的 .io、.cache、.mem 三个子协议。

二、RDMA：远端 DMA 的三种物理体系

2.1 三种线缆，一套 verbs

RDMA 不是”一种网络”，它是”一种语义”：单边读 / 写 / 原子操作，远端 CPU 不感知。这套语义有三种主流物理 / 链路层承载：

verbs API（ibv_post_send、ibv_poll_cq）在三者之上是统一的；用户态库 libibverbs + librdmacm 是 Linux 上的标准入口。

2.2 语义层：单边、双边、原子

RDMA 操作分三类：

• 双边（SEND / RECV）：需要对端预先 post 一个 RECV，本端 SEND 触发对方收完成事件。语义最接近传统 socket。
• 单边（READ / WRITE）：对端 CPU 完全不知情，由对端 RNIC 直接执行 DMA。这是 RDMA 的关键卖点。
• 原子（FETCH_ADD / CMP_SWAP）：远端原子操作，单次往返完成”读—改—写”。

在分布式 KV、远端 page-cache、参数服务器、HPC 集合通信里，单边操作 + 注册内存（MR）+ 完成队列（CQ）这三件套是 RDMA 拉开和 TCP 性能差距的真正原因，而不仅仅是”内核旁路”。

2.3 必须正视的工程代价

RDMA 在生产里有几个回避不掉的麻烦：

1. 内存必须注册（pin）：在 verbs 体系下，参与 RDMA 的内存要先注册成 MR（Memory Region），RNIC 才能拿到 r/lkey 和物理地址。注册和注销路径都不便宜；ODP（On-Demand Paging）能缓解但有自己代价。
2. RoCEv2 对网络要求苛刻：传统部署需要 PFC（IEEE 802.1Qbb）+ ECN，避免丢包；PFC 配错会出 head-of-line 阻塞和 deadlock。近年 Microsoft 的 DCQCN 和 Google Falcon、AWS SRD 等都在尝试摆脱 lossless 假设。
3. 失效模式陌生：QP（Queue Pair）一旦进入 error state，要走 modify_qp 重新拉起；丢一个 ACK 比 TCP 难调试。
4. 多租户与安全：MR 暴露的是物理地址映射 + key，跨租户复用必须依赖 SR-IOV、PD（Protection Domain）、NVMe over Fabrics 这类隔离机制。

简言之，RDMA 是专为”两端都受控、网络可被精细配置”的环境设计的；离开这个环境，TCP / QUIC 的容错性反而更划算。

三、CXL：在 PCIe 物理层之上把内存重新定义

3.1 三个子协议各干什么

CXL 跑在 PCIe 5.0 / 6.0 / 7.0 的物理层之上，但协议栈是自己的：

• CXL.io：本质上就是 PCIe 事务层，用于设备发现、配置、IO 操作。所有 CXL 设备都必须支持。
• CXL.cache：让设备能以缓存行粒度参与主机的一致性协议（device 可缓存 host 内存）。Type 2 设备使用。
• CXL.mem：让主机 CPU 能以 load/store 指令直接访问设备暴露的内存，并把这段内存接入主机 cache coherence 域。Type 2 / Type 3 设备使用。

按用法 CXL 把设备分三类：

Type 3 是 CXL 落地最快的方向，因为它给出了一条”用 PCIe 槽插更多 DRAM”的工程路径，而且不再受单服务器主板内存通道数限制。

3.2 CXL 1.x → 2.0 → 3.x 的演进重点

• CXL 1.1（2019）：仅 host-to-device 直连，无 switch，受限于”一个 root 一组设备”。
• CXL 2.0（2020）：引入 CXL Switch、池化（pooling）和 IDE（Integrity & Data Encryption）；多个 host 可以分时占用同一段池化内存（每段同时只属于一个 host）。
• CXL 3.0 / 3.1（2022 / 2023）：进入 PCIe 6.0，引入多层 switching、Port-Based Routing、Fabric Manager、共享内存（真正的 multi-host coherent sharing）、对称一致性、HDM-DB（device-coherent shared regions）。

关键拐点是 3.0：在此之前 CXL.mem 即使在 2.0 池化里也是”分时独占”，3.0 才提供严格意义上的多主机一致性共享，并且把 fabric 扩展到机架级。

3.3 把”内存”拆成多种 HDM

CXL 引入了 Host-managed Device Memory（HDM）概念，把设备内存接入系统物理地址空间，并区分 coherence 行为：

• HDM-H：host-only coherent。设备不缓存这段内存。最简单的内存扩展。
• HDM-D：device-coherent，host 通过协议保持一致。Type 2 设备典型用法。
• HDM-DB：device-coherent，支持多 host 共享。CXL 3.0 新增，是真正构造”跨主机共享内存”的基础。

工程上理解 HDM 的三种形态，比理解”CXL 1.1 / 2.0 / 3.0”更重要：它决定了你能不能在设备侧 cache、能不能多 host 一致访问、需要什么样的 fabric。

3.4 物理与可达性约束

CXL 不是”机房级”协议，它的几个边界要写清楚：

1. 延迟范围：CXL.mem 的目标是把跨设备 load/store 延迟控制在 百 ns 级（机架内，经过 1–2 跳 switch）。这是它能称为”内存语义”的前提；越往远走、跳数越多，延迟越接近网络层级。
2. 跳数与拓扑：CXL 3.x 支持多层 switching 与 Port-Based Routing，但仍是 fabric，不是任意拓扑；fabric manager 的存在意味着 control plane 与 data plane 是分开的。
3. 不是替代以太网：跨机架、跨数据中心、跨可用区，CXL 不解决。

四、并排对比：RDMA 与 CXL 的真正分野

下面这张表是本文的核心结论：

一句话：RDMA 让远端访问像本地 DMA；CXL 让远端内存像本地内存。

这两件事不是同一件事——前者是”协议加速”，后者是”地址空间扩展 + 一致性扩展”。

五、它们之间真的有竞争吗？

只有一类场景两者会被同时考虑：机架级共享内存 / 内存池。

• 用 RDMA 做共享内存池：每个 host 通过 verbs READ/WRITE 远端注册的 MR，应用层自行维护一致性（典型做法是单写者 + 版本号 + epoch）。优点是成熟、广域可达；代价是没有硬件一致性、应用要承担同步语义。
• 用 CXL 3.0 HDM-DB 做共享内存：fabric 给出真正的硬件一致性，应用可以用普通 load/store 加 atomic 操作；代价是部署受限于机架物理边界、当前还高度依赖 fabric manager 与 OS 支持的成熟度。

更常见的现实是两者互补：

• 节点内 / 机架内：CXL Type 3 做内存扩容与池化，让单机 / 单机柜可用容量从”主板插槽数”解放；
• 节点之间 / 机架之间：RDMA（RoCEv2 居多）继续承担远端访问、参数同步、KV 跨节点访问、分布式存储复制。

对 AI / HPC 训练栈尤其如此：HBM 与 DDR 之间的容量缺口由 CXL 解决，集群梯度同步 / All-Reduce 继续靠 InfiniBand / RoCE。

六、选型判断的几个常见误区

6.1 “RoCEv2 就是普通以太网”

不对。生产 RoCEv2 仍然需要把 PFC + ECN 调对、和上层 DCQCN / 类似算法配合；网络团队要为 RDMA 流量预留单独的 traffic class，做好 BUM（Broadcast/Unknown/Multicast）和 lossless 隔离。AWS SRD、Google Falcon 等新一代协议正在挑战”必须 lossless”这个前提，但要看具体云厂商支持情况。

6.2 “CXL 出来 RDMA 就过时了”

不会。CXL 是节点内 / 机架内的协议，它不解决跨机架、跨 AZ、跨数据中心的访问问题。这些场景仍然是以太网 + RDMA 或 TCP / QUIC 的地盘。

6.3 “CXL.mem 接上就能多 host 共享”

只在 CXL 3.0 HDM-DB + 支持多 host coherent sharing 的设备上成立。CXL 2.0 的”池化”是分时独占；以为 2.0 设备插上就能跨 host 共享是常见误解。

6.4 “RDMA 程序写起来很简单”

verbs 上手很反直觉。MR 注册、QP 状态机、CQ 轮询、ack timeout、re-arm、connection manager（RDMA-CM）……任何一个不对就是 silent failure。生产建议是基于 UCX、NVIDIA Collective Communications Library（NCCL）、libfabric 等更高层封装，而不是直接写 verbs。

七、什么时候不应该用 RDMA / CXL

• 链路不可控（公网、跨 AZ、不可控丢包）：选 TCP / QUIC，不要选 RDMA。
• 请求结构高度 RPC 化、单次数据量小：gRPC / Thrift / 普通 socket 的开发与运维成本更低，RDMA 带来的吞吐收益经常不抵复杂度成本。
• 跨机房 / 跨数据中心：CXL 直接不适用；RDMA 也只在专线 + 严密工程下才可考虑。
• 节点数极少 / 单机为主：本地 NUMA、HugePage、io_uring 已经能解决大部分本地 I/O 与内存问题，不必引入 CXL；详见 HugeTLB 与 THP 与 io_uring 内核内部。

八、小结

• RDMA 和 CXL 都”绕开 CPU”，但绕开的方向相反：RDMA 绕开远端 CPU 的协议栈，CXL 绕开本地内存的总线边界。
• RDMA 是协议层抽象：verbs + RNIC + 三种线缆（IB / RoCEv2 / iWARP）。最适合”两端都受控、网络可工程化”的数据中心。
• CXL 是地址空间扩展 + 一致性扩展：跑在 PCIe 物理层之上，三个子协议 .io、.cache、.mem + 三类设备 Type 1/2/3。机架级落地仍处于早期，3.0 才有真正的多 host 共享一致性。
• 互补关系强于替代关系：节点内 / 机架内用 CXL，节点间 / 跨机架用 RDMA。
• 选型时先回答两个问题：链路可控吗？需要多 host 缓存一致吗？ 这两个问题的答案直接决定能不能用 RDMA、能不能用 CXL。

延伸阅读

• 互联与网络：NVLink、InfiniBand、RoCE、国产替代：在 AI 训练栈里把 RDMA 放到完整互联层级里看。
• 零拷贝网络：sendfile、splice 与 MSG_ZEROCOPY：内核侧”绕开 CPU”的另一条路径，与 RDMA 互补。
• XDP 与 AF_XDP：用 eBPF / 用户态环把数据拉到应用层，相比 RDMA 是更通用、更”网络化”的低开销路径。
• 网络技术展望：SmartNIC、CXL 与内核旁路的未来：把 RDMA / CXL 放在 SmartNIC 与内核旁路演进里看。
• PagedAttention 与 Continuous Batching：CXL 内存扩展对 KV cache 大小的影响是显而易见的下一个落点。
• 持久内存：CXL 之前那一代”内存级访问”路线的工程经验。

参考资料

规范

• IBTA, InfiniBand Architecture Specification, Volume 1, Release 1.7, 2024.
• IETF RFC 5040, A Remote Direct Memory Access Protocol Specification.
• IETF RFC 5041, Direct Data Placement over Reliable Transports.
• IETF RFC 5044, Marker PDU Aligned Framing for TCP Specification.
• CXL Consortium, Compute Express Link Specification, Revision 3.1, 2023-11.

论文 / 工业报告

• RDMA over Commodity Ethernet at Scale, SIGCOMM 2016.
• Revisiting Network Support for RDMA, SIGCOMM 2018.
• Tame the Tail with HBFC, OSDI 2022（CXL.mem 延迟分析背景）。
• Intel, Astera Labs, Samsung 等供应商关于 CXL Type 3 内存扩展的公开白皮书。

工具与软件栈

• libibverbs、librdmacm、rdma-core 用户态库。
• UCX、libfabric：RDMA 之上的高层抽象。
• NCCL / RCCL：集合通信里的 RDMA 客户。
• Linux 内核 drivers/cxl/ 子系统、numactl / daxctl。

上一篇：网络技术展望：SmartNIC、CXL 与内核旁路的未来 返回：网络工程索引