3. 无损以太网核心概念

RoCEv2（RDMA over Converged Ethernet version 2）之所以能够将传统以太网的“尽力而为”传输提升为无损、低时延、高吞吐的RDMA承载网络，其根本在于引入了一整套由IEEE 802.1Qbb（PFC）、802.1Qau（ECN）、802.1Qaz（ETS/DCBX）以及LLDP（802.1AB）构成的协同机制。这四项技术并非孤立存在，而是分别从链路层背压、端到端拥塞反馈、带宽资源分配和参数自动协商四个维度构建了无损以太网的完整闭环。理解它们之间的依赖关系与调优边界，是部署RoCEv2网络的前提。

无损以太网协同机制总览 PFC 优先级流控 IEEE 802.1Qbb 链路级逐跳背压 8个优先级队列 XON/XOFF 机制 ECN 显式拥塞通知 IEEE 802.1Qau 端到端拥塞标记 CE / ECT 标记 配合DCQCN降速 ETS 带宽管理 IEEE 802.1Qaz 优先级组调度 CBS 信用令牌 带宽百分比分配 DCBX + LLDP IEEE 802.1AB 参数自动协商 TLS 类型长度值 一致性校验 协同工作流程 DCBX通过LLDP下发PFC/ETS/ECN参数 → 交换机与网卡统一配置 → PFC消除链路丢包 → ECN反馈拥塞 → 发送端降速 RoCEv2 数据面与控制面交互 发送端 NIC 无损交换机 接收端 NIC 数据包 (PFC/ECN标记) 数据包 CNP 拥塞通知包

上图展示了RoCEv2无损网络的整体协同框架。PFC在链路层提供逐跳的优先级流控，确保队列不丢包；ECN在IP层提供端到端的拥塞标记，使发送端能够主动降速；ETS负责在多个优先级之间分配带宽资源；而DCBX则通过LLDP协议自动协商和验证上述参数的一致性。四者环环相扣，任何一项配置不当都可能导致网络性能急剧下降。

3.1 PFC优先级流控：链路层无损的基石

3.1.1 核心原理

PFC（Priority-based Flow Control）是对传统802.3x流控的增强。传统流控作用于整个物理链路，一旦触发就会暂停所有流量，容易导致队头阻塞（HOL Blocking）。PFC将链路划分为8个优先级队列（Priority 0-7），每个队列独立进行流控。当某个队列的接收缓冲区超过阈值（XOFF）时，接收方向发送方发送PFC暂停帧，发送方收到后暂停该优先级的发送；当缓冲区水位回落到XON阈值以下时，再发送恢复帧。

在RoCEv2场景中，通常将RoCE流量映射到高优先级队列（如Priority 3），而将普通TCP/IP流量映射到低优先级队列。这样即使TCP流量突发，也不会影响RoCE流量的无损特性。PFC的粒度是优先级而非单个流，因此需要配合ECN使用，避免PFC风暴。

3.1.2 配置与判断方法

PFC的配置涉及交换机端口和网卡两侧。关键参数包括：

  • 使能队列：确定哪些优先级队列启用PFC（通常为3或4）
  • XOFF阈值：触发暂停帧的缓冲区水位（建议设置为端口缓冲区的60%-70%）
  • XON阈值：恢复发送的水位（建议为XOFF的80%）
  • 暂停帧计时器：发送暂停帧后等待恢复的时间（默认65535个时隙）

判断PFC是否生效，可以通过以下命令检查：

# 交换机侧查看PFC统计（以NVIDIA Spectrum交换机为例）
show interface ethernet 1/1 priority-flow-control
# 输出中关注 RxPause / TxPause 计数是否持续增长

# 网卡侧查看PFC计数（Mellanox网卡）
ethtool -S eth0 | grep -i pfc
# 关注 rx_pause / tx_pause 计数

如果RxPause和TxPause计数持续快速增长，说明网络中存在严重的拥塞，需要结合ECN进行端到端调优。

3.1.3 案例拆解：PFC死锁的排查

背景：某数据中心部署RoCEv2用于分布式存储，使用100Gbps以太网。业务运行两周后，存储集群出现周期性IO延迟抖动，峰值延迟从正常的50μs飙升至5ms。

初始现象：交换机端口RxPause计数每分钟增长约10万次，但TxPause几乎为零。网卡侧rx_pause计数同样快速增长。

分析过程：

  1. RxPause高而TxPause低，说明交换机接收方向持续向发送端发送暂停帧，但发送端并未向交换机发送暂停帧。
  2. 进一步检查发现，存储节点A的发送队列深度持续处于高位，且该节点的ECN标记率超过5%。
  3. 通过流量镜像抓包，发现存储节点A发送的RoCEv2数据包中，ECN标记为CE（Congestion Experienced）的比例高达8%，但发送端并未有效降速。

根因：存储节点A的RoCEv2驱动未正确启用ECN响应机制（DCQCN），导致交换机持续标记ECN，但发送端不降速，最终交换机缓冲区溢出，触发PFC暂停帧。

解决步骤：

  1. 在存储节点A上启用DCQCN：echo 1 > /sys/class/infiniband/mlx5_0/ecn_enable
  2. 调整交换机ECN阈值：将ECN标记阈值从默认的100KB降低到50KB，使拥塞反馈更早触发。
  3. 重启存储节点A的RoCEv2服务，观察PFC计数。

结果对比：调整后，RxPause计数从每分钟10万次降至每分钟200次以下，IO延迟抖动恢复至正常水平（50-80μs）。

风险提示：PFC是一把双刃剑。过度依赖PFC会导致“PFC风暴”——当多个交换机端口同时触发暂停时，拥塞会向上游扩散，形成树状阻塞。务必配合ECN使用，让发送端主动降速，PFC仅作为最后防线。

3.2 ECN显式拥塞通知：端到端的拥塞反馈

3.2.1 核心原理

ECN（Explicit Congestion Notification）在IP头部的TOS字段中使用2个比特：ECT（ECN-Capable Transport）和CE（Congestion Experienced）。发送端在数据包中设置ECT标记，表示支持ECN；交换机在检测到队列深度超过阈值时，将数据包的CE位置1；接收端收到CE标记后，生成CNP（Congestion Notification Packet）反馈给发送端，发送端据此降低发送速率。

在RoCEv2中，ECN通常与DCQCN（Data Center Quantized Congestion Notification）算法配合。DCQCN通过概率降速和快速恢复机制，实现微秒级的拥塞响应。关键参数包括：

参数默认值推荐值说明
Kmin100KB50-80KB开始标记ECN的队列深度
Kmax200KB150-200KB100%标记ECN的队列深度
Pmax10%5-15%最大标记概率
α1/161/8-1/32速率下降因子
β1/5121/256-1/1024速率恢复因子

3.2.2 配置与验证方法

ECN配置需要同时设置交换机的WRED（Weighted Random Early Detection）阈值和网卡的DCQCN参数。交换机侧配置示例：

# 华为CloudEngine交换机配置ECN
interface 10GE1/0/1
  qos ecn-profile ecn-1
    ecn buffer-size 50
    ecn max-threshold 150
    ecn mark-probability 10
  qos queue 3 ecn-profile ecn-1

验证ECN是否生效，可以通过以下方式：

  • 查看交换机ECN标记计数：display qos ecn statistics interface 10GE1/0/1
  • 在接收端抓包，统计CE标记的数据包比例
  • 使用ethtool -S eth0 | grep ecn查看网卡ECN计数

3.2.3 案例拆解：ECN阈值调优

背景：某AI训练集群使用RoCEv2，GPU服务器通过100Gbps网络互联。训练任务运行后，AllReduce通信耗时占总训练时间的40%，远高于预期的20%。

初始现象：交换机ECN标记率仅为0.5%，但PFC暂停帧频繁触发。这说明拥塞发生在交换机缓冲区深处，ECN未能提前预警。

分析过程：

  1. 检查交换机ECN配置，发现Kmin设置为200KB，Kmax为400KB，而交换机端口缓冲区总量为8MB。
  2. 由于AI训练流量具有突发性，队列深度在微秒级内从0飙升至300KB，ECN还没来得及标记，缓冲区已溢出触发PFC。
  3. 通过调整Kmin至50KB，Kmax至150KB，使ECN在队列深度达到50KB时即开始标记。

操作步骤：

  1. 修改交换机ECN profile：ecn buffer-size 50，ecn max-threshold 150
  2. 调整网卡DCQCN参数：将α从1/16调整为1/8，加快降速响应。
  3. 重启训练任务，观察ECN标记率和PFC计数。

结果对比：调整后，ECN标记率从0.5%升至2.3%，PFC暂停帧减少90%，AllReduce通信耗时从40%降至25%。

经验总结：ECN阈值并非越小越好。过小的Kmin会导致正常突发流量也被标记，造成不必要的降速；过大的Kmin则无法及时反馈拥塞。建议根据实际流量模型，通过A/B测试逐步调整。

3.3 ETS带宽管理：多优先级流量的公平调度

3.3.1 核心原理

ETS（Enhanced Transmission Selection）定义了如何在不同优先级之间分配带宽。它使用优先级组（Priority Group）的概念，将8个优先级划分为多个组，每个组分配一个带宽百分比。ETS采用CBS（Credit-Based Shaper）算法，确保每个优先级组获得其承诺的最小带宽，同时允许空闲带宽被其他组借用。

在RoCEv2部署中，典型的ETS配置是将RoCE流量（Priority 3）分配70%带宽，管理流量（Priority 0）分配10%，存储流量（Priority 1）分配20%。这样即使RoCE流量突发，也不会完全挤占管理流量的带宽。

3.3.2 配置与验证

ETS配置在交换机端口上完成，需要指定每个优先级组的带宽百分比和调度算法：

# 思科Nexus交换机ETS配置
interface Ethernet1/1
  priority-flow-control mode on
  priority-group 1 bandwidth 70
  priority-group 2 bandwidth 20
  priority-group 3 bandwidth 10
  priority-queue 3 priority-group 1
  priority-queue 1 priority-group 2
  priority-queue 0 priority-group 3

验证ETS是否生效，可以通过以下方法：

  • 使用show interface ethernet 1/1 priority-group查看各优先级组的实际带宽使用
  • 使用iperf3或自研工具生成不同优先级的流量，观察带宽分配是否符合配置

3.3.3 常见误区

误区1：ETS带宽百分比是硬性限制。实际上，ETS保证的是最小带宽，当某个优先级组空闲时，其他组可以借用其带宽。
误区2：所有交换机厂商的ETS实现完全一致。不同厂商的调度算法（如严格优先级+加权轮询）可能存在细微差异，跨厂商组网时需仔细验证。
误区3：ETS配置后无需调整。当业务模型变化时（如增加存储流量），需要重新评估带宽分配比例。

3.4 DCBX协议与LLDP：参数自动协商与一致性校验

3.4.1 核心原理

DCBX（Data Center Bridging eXchange）是LLDP（Link Layer Discovery Protocol）的扩展，用于在相邻设备之间交换PFC、ETS、ECN等无损以太网参数。DCBX定义了多种TLV（Type-Length-Value）类型，包括：

TLV类型用途关键字段
Priority-based Flow Control TLV协商PFC使能队列Willing、PFC Enable Bitmap
ETS Configuration TLV协商带宽分配Priority Group Table、Bandwidth Table
ETS Recommendation TLV建议带宽分配推荐配置（非强制）
Application Priority TLV映射应用到优先级App Priority Table

DCBX有两种协商模式：Willing模式（设备接受对端参数）和Non-Willing模式（设备强制本端参数）。在数据中心中，通常将交换机配置为Non-Willing，网卡配置为Willing，由交换机统一下发参数。

3.4.2 配置与排障

DCBX配置的核心是确保两端参数一致。以下是一个典型的配置流程：

  1. 在交换机上启用DCBX：dcbx enable
  2. 配置PFC和ETS参数（见前文）
  3. 在网卡上启用DCBX：mlxconfig -d /dev/mst/mt4123_pciconf0 set DCBX_MODE=1
  4. 重启网卡驱动，使配置生效

排障时，可以使用以下命令检查DCBX协商状态：

# 交换机侧
show dcbx status interface ethernet 1/1
# 关注协商状态是否为 "Agreement" 或 "Mismatch"

# 网卡侧
mlxlink -d /dev/mst/mt4123_pciconf0 | grep -i dcbx

3.4.3 案例拆解：DCBX参数不一致导致的性能问题

背景：某企业数据中心采购了新的国产交换机，与原有Mellanox网卡混合组网。部署RoCEv2后，部分服务器间通信带宽仅为预期的50%。

初始现象：使用ib_write_bw测试带宽，部分节点对之间带宽为50Gbps（预期100Gbps），且延迟波动明显。

分析过程：

  1. 检查DCBX状态，发现交换机与网卡之间的协商状态为“Mismatch”。
  2. 进一步查看TLV内容，发现交换机发送的PFC Enable Bitmap为0x08（仅使能Priority 3），而网卡期望的Bitmap为0x18（使能Priority 3和4）。
  3. 由于PFC参数不一致，网卡将RoCE流量映射到Priority 4，但交换机未对该优先级启用PFC，导致链路层丢包。

解决步骤：

  1. 修改交换机PFC配置，使能Priority 3和4：priority-flow-control mode on priority 3,4
  2. 重启网卡驱动，重新协商DCBX参数。
  3. 验证协商状态变为“Agreement”。

结果对比：协商一致后，带宽恢复至100Gbps，延迟恢复至正常水平。

重要提醒：DCBX协商失败时，网卡通常会回退到默认配置（PFC关闭、ETS默认），此时RoCEv2流量将失去无损保障。务必在业务上线前验证DCBX协商状态，并建立监控告警。

3.5 总结与最佳实践

无损以太网的四大核心概念构成了一个完整的闭环：DCBX负责参数下发与校验，PFC提供链路层兜底，ECN实现端到端拥塞反馈，ETS保障多优先级公平调度。在实际部署中，建议遵循以下最佳实践：

  • 统一规划优先级映射：统一RoCE流量优先级（建议Priority 3），避免跨厂商不一致。
  • ECN优先于PFC：优先调整ECN阈值，让发送端主动降速，PFC仅作为最后防线。
  • 定期审查DCBX状态：建立监控，确保所有端口协商状态为“Agreement”。
  • 渐进式调优：先使用默认参数运行，再根据监控数据逐步调整ECN阈值和ETS带宽分配。
  • 跨厂商验证：不同厂商的PFC/ETS实现可能存在细微差异，混合组网时务必进行互操作性测试。
← 上一章 📖 返回目录 下一章 →