在微软的 Azure Local和 Storage Spaces Direct (S2D) 官方架构指南中，针对全 NVMe（All-NVMe）的极高性能场景，微软确实强烈建议使用 RoCE v2 (RDMA over Converged Ethernet) 来替代 iWARP。
虽然微软在过去的技术推广中（如万兆 10GbE 或混合存储时代）因为"易部署性"而频繁推荐过 iWARP，但在进入全 NVMe 时代后，天平明显向 RoCE v2 倾斜。
主要原因有以下几点：
1. 极致的吞吐与延迟表现（匹配 NVMe 的性能）
全 NVMe 阵列的单盘 IOPS 和带宽极其恐怖，这时候网络成为了第一瓶颈。
-
RoCE v2 是基于内核旁路（Kernel Bypass）并直接封装在 UDP/IP 上的，由网卡硬件层直接处理，时延通常在 1-5微秒 级别。
-
iWARP 运行在标准的 TCP/IP 协议栈上。为了保证数据包顺序和可靠性，它的架构包含了 DDP、MPA 等较复杂的层级。这使得其延迟通常在 10-15微秒。 在全 NVMe 场景下，iWARP 较高的网络延迟会直接"拖累" NVMe 的极速响应优势。
2. 硬件卸载与 CPU 开销
公有云（如微软 Azure 自身）的大规模实践表明，RoCE v2 的硬件卸载（Offload）更彻底。
-
RoCE v2 能够实现近乎零的 CPU 占用率。
-
iWARP 由于要在网卡上维护复杂的 TCP 状态机（State Machine），在大规模高并发吞吐时，网卡自身的处理芯片很容易遇到瓶颈，或者对主机 CPU 的释放不如 RoCE v2 彻底。微软在自家 Azure 存储后端的 RDMA 流量中，绝大多数也都是基于 RoCE 架构。
3. 生态系统与高带宽（25G / 100G+）支持
随着 HCI 步入 25GbE、50GbE 甚至 100GbE 时代，主流的高性能网卡厂商（如 NVIDIA/Mellanox ConnectX 系列，以及 Intel 最新的高性能网卡）都将 RoCE v2 作为其主打的超高性能传输协议。在全 NVMe 的超高带宽需求下，RoCE v2 的硬件选择和成熟度都更具优势。
⚠️ 微软全 NVMe 选 RoCE v2 的硬性前提：
虽然 RoCE v2 性能无敌，但它对网络环境极其挑剔 。 如果你决定听从微软的建议在全 NVMe HCI 中采用 RoCE v2，你的物理交换机必须 配置并支持 DCB（数据中心桥接） 、PFC（优先流量控制） 和 ECN（显式拥塞通知）。必须保证整个存储网络是**无损（Lossless）**的。如果交换机配置不当导致丢包，RoCE v2 的性能会发生断崖式下跌。
如果你的团队有足够强的网络运维能力、交换机支持 DCB，全 NVMe HCI 选择 RoCE v2 能够压榨出硬件的最大潜能；如果网络是普通传统交换机，且完全不想折腾网络配置，才退而求其次选择免交换机配置的 iWARP（但会牺牲一部分全 NVMe 的极致性能）。