1. 为什么RDMA无损网络离不开DCQCN和PFC先说结论在NVIDIA CX6网卡和华为CE交换机这种组合里DCQCN和PFC不是“可选项”而是RoCEv2协议能跑起来的基本前提。很多刚接触无损网络的兄弟容易搞混一件事——RDMA本身只是一种远端内存直接访问的技术但它跑在以太网上时默认的以太网丢包重传机制会直接把RDMA的性能打回原形。RDMA的核心理念是“绕过内核、直接操作远端内存”数据通路上的绝大部分工作都交给了网卡硬件完成。但这里面有个前提网络不能丢包。传统TCP遇到丢包可以通过内核里的拥塞控制算法慢慢恢复走的是软件路径慢一点无所谓。RDMA不行它一旦丢包要么依赖重传机制比如Go-Back-N要么直接导致QPQueue Pair错误应用层就会看到令人抓狂的“Connection Reset”或者“HCA error”。也就是说传统网络的丢包率哪怕只有万分之一对RDMA来说都是不可接受的。所以无损网络要解决两件事不要让缓存溢出导致丢包这需要PFCPriority Flow Control基于优先级的流控在链路层做“刹停”不要让流量长期占满瓶颈口导致某个流的延迟无限拉高这需要DCQCNData Center Quantized Congestion Notification数据中心量化拥塞通知在端到端层面做“减速”。这两者一个管局部一个管全局配合起来才是一个完整的无损方案。前者是在交换机和网卡之间逐跳做反压后者是让发送端网卡感知拥塞并主动降速。光有PFC没有DCQCN网络里会出现一个很典型的“队头阻塞”问题——低优先级流量把高优先级流量堵死光有DCQCN没有PFC拥塞信号还没传回来交换机缓存已经爆了包照丢不误。所以生产环境里这两兄弟必须一起配。在NVIDIA CX6 华为CE交换机的组合里CX6网卡是目前RoCEv2商用网卡里支持DCQCN最完善的一代华为CE系列交换机则原生支持动态PFC和ECNExplicit Congestion Notification显式拥塞通知。这套组合只要配置思路清晰基本可以做到“零丢包、低延迟、高吞吐”。2. DCQCN和PFC的工作原理一句话讲透2.1 PFC是链路上的“红绿灯”PFC的本质是802.1Qbb它把物理链路划分为最多8个优先级队列。每一个队列都可以独立暂停/恢复互不干扰。它的工作方式很简单当接收端的某个优先级队列缓存占用超过阈值也就是水线时接收端会向对端发送一个PFC暂停帧PAUSE帧帧里面带一个优先级位图告诉对端“我这个优先级的队列已经满了你暂时别发”。对端收到后就暂停发送该优先级的报文直到收到恢复帧或者暂停计时器超时。PFC解决的是“交换机出口瞬间突发来不及转发导致丢包”的问题。但PFC有个副作用——它本质上是在链路上制造人为的“拥堵延时”如果配置不合理一个队列的暂停可能会向上游传递最终造成拥塞树扩散到整个网络。这是无损网络配置里最容易踩的坑后面我会详细说。2.2 DCQCN是端到端的“限速器”DCQCN是微软和Mellanox现在是NVIDIA联合提出的拥塞控制方案专为RoCEv2设计。它的核心思路是“交换机标记 接收端反馈 发送端降速”三个环节交换机检测到队列长度超过ECN水线后会在报文IP头里打上ECN标记CECongestion Experienced接收端网卡收到带CE标记的报文后会向发送端反馈一个CNPCongestion Notification Packet报文CNP是一个特殊的RoCE报文优先级通常与数据流相同发送端收到CNP后会按照一套算法降低自己的发送速率并通过周期性的速率恢复机制慢慢试探着提高速率。简单理解PFC是“你慢点我要不过来了”DCQCN是“你太快了给我降速”。PFC是逐跳的DCQCN是端到端的。两者作用在不同的网络层次缺一不可。2.3 为什么是CX6和CE交换机的组合NVIDIA CX6网卡全系支持RoCEv2硬件卸载DCQCN的拥塞响应、速率恢复全部由硬件执行不像早期网卡需要CPU参与这直接决定了拥塞场景下的响应时延可以做到微秒级。华为CE系列交换机针对RoCE场景做了大量优化比如动态水线、ECN的精细化配置、PFC死锁检测等在配置命令上也有比较完整的无损网络模板。这个组合在超大规模数据中心里被广泛验证过很多互联网公司和券商的分布式存储、高性能计算集群都在用照这套思路配置基本不会走偏。3. 配置前的准备与整体设计3.1 规划无损网络的几个关键决策动手配置之前你需要先回答几个问题RoCEv2跑在哪个VLAN使用哪个优先级队列承载无损流量传统的选择是优先级3或者优先级4华为CE交换机默认常用于无损业务的优先级是3和4其他流量比如SSH管理、存储管理、TCP业务放在哪些优先级上端到端的MTU是多少RDMA场景强烈建议启用巨帧MTU 9000或至少4200减少同等数据量下的报文数量降低CPU和交换机转发压力。我个人习惯是把无损业务放在VLAN 100优先级用4DSCP值映射到46EFSSH管理和监控流量用优先级0。这样在配置PFC的时候只需要把优先级4加入无损队列其他优先级全部走传统有损转发互不影响。3.2 配置前的硬件和固件检查清单再强调一次这一步别跳。很多兄弟配置了半天发现RDMA跑不起来最后发现是固件版本不匹配或者网卡没有正确识别。我建议按下面这个清单过一遍CX6网卡固件版本是否支持DCQCN动态控制推荐固件版本至少是xx.xx.2000以上的版本具体以NVIDIA官网为准华为CE交换机是否需要license支持无损网络功能动态ECN和PFC功能在CE系列里有些需要License提前确认确认交换机端口的MTU和网卡MTU一致建议统一为9000确认RoCEv2模式下网卡的DCQCN相关参数可以被ibv_devinfo查询到检查物理链路是否存在CRC错误、信号降级等问题这些会直接影响无损网络的稳定性。这些准备工作做完再开始真正配置。4. 华为CE交换机端的PFC和DCQCN配置实操4.1 全局开启无损网络相关特性华为CE交换机的配置逻辑是“端口优先级 流控模板 ECN模板”整体思路还是比较清晰的。先进入系统视图使能全局的ECN和PFC特性system-view [~HUAWEI] ecn global enable [*HUAWEI] priority-flow-control global enable这两条命令是全局层面的开关。注意CE交换机的很多特性支持全局使能和端口使能两级控制如果全局关了端口上配了也白配。4.2 配置优先级映射接下来要做的是把DSCP值映射到交换机内部的优先级。这一步的目的是让进入交换机的RoCEv2流量能自动映射到我们指定的无损队列上。以RoCEv2报文为例它的IP头里DSCP值默认是0我们需要在交换机上把DSCP 46映射到本地优先级4[~HUAWEI] diffserv domain default [~HUAWEI-ds-domain] ip-dscp-in-map 46 priority 4 [~HUAWEI-ds-domain] quit同时为了防止其他业务误入无损队列建议对非RoCE的流量做限制。比如SSH管理流量、SNMP流量都走默认优先级0不给它进无损队列的机会。4.3 配置PFC优先级流控核心步骤来了。在交换机接口下开启PFC并把优先级4加入PFC使能列表[~HUAWEI] interface 10GE1/0/1 [~HUAWEI-10GE1/0/1] priority-flow-control enable [~HUAWEI-10GE1/0/1] priority-flow-control priority 4 enable这里有个关键点priority-flow-control enable开启的是接口级PFC能力而priority-flow-control priority 4 enable才是把优先级4纳入PFC控制的开关。两个都要配缺一不可。如果只是在接口下开启了priority-flow-control enable但没指定哪个优先级那么CE交换机会认为该接口下没有需要PFC保护的流量。这时候如果突发拥塞优先级4的流量和其他普通流量一样会被丢弃。对于对接CX6网卡的服务器端口还要考虑一个buffer问题。华为CE交换机的动态buffer管理机制会根据流量模型自动调整但对于无损队列建议手动配置buffer的百分比预留足够的吸收能力。以常见的CE6857为例配置如下[~HUAWEI-10GE1/0/1] qos buffer headroom-pool 1 priority 4 size 20% [*HUAWEI-10GE1/0/1] qos buffer burst-mode enable第一行给优先级4预留了20%的headroom buffer用于吸收PFC暂停帧生效前的转发延迟第二行开启burst模式让交换机能更好地吸收微突发流量。这个百分比不是越大越好太大挤占其他队列的buffer反而影响整体吞吐。4.4 配置ECNDCQCN的交换机侧部分DCQCN依赖交换机在队列拥塞时对报文打ECN标记。华为CE交换机配置ECN的方式是创建WRED模板然后应用到端口队列上。先看一个基础配置[~HUAWEI] qos wred ecn-profile name rdma_ecn [~HUAWEI-wred-ecn-rdma_ecn] color green low-limit 1000 high-limit 2000 discard-percent 10 [~HUAWEI-wred-ecn-rdma_ecn] color green ecn-marking enable [~HUAWEI-wred-ecn-rdma_ecn] quit这里的low-limit和高低limit的单位是buffer的cell数不同型号有差异实际使用时建议根据交换机型号的buffer规格换算。ecn-marking enable是关键它决定了对绿色报文也就是正常转发优先级是否启用ECN标记。然后把这个ECN模板应用到接口的队列4上[~HUAWEI] interface 10GE1/0/1 [~HUAWEI-10GE1/0/1] qos queue 4 ecn-profile rdma_ecn这一条的作用是当队列4的长度超过low-limit后新进入的报文会被打上ECN标记当队列长度超过high-limit后报文开始被丢弃。DCQCN协议的发送端会根据ECN标记的报占比来调整速率。4.5 水线参数的确定思路这里值得多写几句。ECN水线的设置要跟你预期中的流数量、交换机buffer容量、时延要求匹配。如果水线设得太低网络稍微一波动交换机就开始疯狂打ECN标记发送端CNP报文比例偏高整体吞吐会被压下来。如果水线设得太高等到标记产生时队列已经很长了报文排队延迟变大RDMA的最核心优势——低延迟——就没了。业界一个比较稳妥的起步配置是ECN水线设置为端口buffer的30%到50%PFC水线设置为端口buffer的70%到80%。换句话说让ECN先于PFC生效PFC作为最后一道防线存在。这个逻辑一定要想清楚ECN让发送端主动降速PFC只是兜底如果PFC频繁触发说明你的ECN参数配得太迟钝了。如果你希望更精细地调节可以这么做先用交换机的端口统计确认开启PFC后有没有pause帧计数然后用display qos wred ecn-profile查看当前模板的命中情况。如果ECN标记计数增长很快但TCP等同网段业务没投诉说明水线偏保守可以适当把low-limit调高。5. NVIDIA CX6网卡端的DCQCN和RoCEv2配置实操5.1 确认网卡工作模式和固件CX6系列网卡使用mlx5_core驱动配置工具主要是ibv_devinfo和cma_roce_tos以及Mellanox的mlxconfig工具。在配置之前先确认网卡已经被正确识别ibv_devinfo -v | grep -E hca_id|fw_ver|node_type|link_layer|active_speed|active_width如果输出里link_layer是Ethernet说明网卡工作在以太网模式下这是RoCEv2的前提。接着查看RoCE的版本支持情况ibv_devinfo -d mlx5_0 | grep roce确认网卡支持RoCEv2。如果固件版本太老建议先升级固件到NVIDIA官网最新推荐版本。我遇到过几次非常诡异的问题比如CNP报文不回、DCQCN参数写入报错最后都是因为固件版本不匹配导致的。5.2 配置RoCEv2和DSCP优先级RoCEv2报文走标准的UDP/IP封装目的端口是4791。要让交换机能识别并优先处理RoCE流量需要给RoCE报文打上DSCP标记。Linux下可以通过rdma_cm模块或cma_roce_tos参数来设置echo 46 /sys/module/rdma_cm/parameters/cma_roce_tos这行命令的作用是把RoCEv2报文IP头的TOS字节设为46对应的DSCP就是46EF这与交换机端配置的ip-dscp-in-map 46 priority 4对应。但要注意这个参数只对使用rdma_cm接口创建的QP生效。如果你的应用程序直接使用ibv_qp创建QP很多自研存储就是这么干的那么需要在应用程序或者驱动层配置。Mellanox的VPI驱动提供了mlx5_ib内核模块参数roce_tos不过在CX6时代更推荐直接用rdma_cm的方式。5.3 使能硬件DCQCNCX6的DCQCN是完全硬件实现的但默认状态下网卡并不会自动把DCQCN跑起来。你需要在网卡上通过mlxconfig工具设置以下参数mlxconfig -d mlx5_0 set ROCE_CC_CTRL_TMIN4 mlxconfig -d mlx5_0 set ROCE_CC_CTRL_TMAX256 mlxconfig -d mlx5_0 set ROCE_CC_CTRL_RP_TIME256 mlxconfig -d mlx5_0 set ROCE_CC_CTRL_NP_TIME256这几个参数的作用分别说明一下ROCE_CC_CTRL_TMIN速率恢复的最小时间窗口单位是微秒。设得太小会让网卡在降速后很快反弹容易造成振荡设得太大则拥塞恢复慢。实际生产环境我常用4到8微秒。ROCE_CC_CTRL_TMAX速率恢复的最大时间窗口用于避免长时间拥塞时快速恢复。ROCE_CC_CTRL_RP_TIME速率恢复的步进周期控制网卡每次恢复的频度。ROCE_CC_CTRL_NP_TIMECNP通知帧的等待周期影响网卡对拥塞事件的敏感度。这些参数并不是越大越好要根据你的业务流量模型去调。初次部署的话可以先保持NVIDIA的默认推荐值跑通之后再看监控数据微调。改完mlxconfig之后要重启网卡或者重启机器才能生效mlxconfig -d mlx5_0 reset5.4 验证网卡侧DCQCN是否生效配置完成后可以用下面的命令验证DCQCN是否已经启用cat /sys/class/infiniband/mlx5_0/ports/1/counters/roce_congestion_control如果输出里能看到Congestion Controlled Packets或者CNP received/sent之类的计数说明DCQCN已经在正常工作。更详细的验证方式是使用rdma statisticrdma statistic show link mlx5_0/1这个命令可以看到roce_cnp_sent、roce_cnp_handled等计数。如果拥塞发生时这些计数快速增加说明DCQCN的CNP反馈通路是通的。5.5 网卡侧的PFC相关配置有人可能会问在Linux系统里网卡侧的PFC要怎么配其实PFC是链路层机制网卡侧的核心是让网卡支持接收和发送PFC暂停帧并且让对应优先级队列响应暂停帧。在Linux下可以用dcb工具配置dcb pfc set dev enp130s0f0 priority 4:on dcb pfc set dev enp130s0f0 prio-pg 0:0 4:4第一行让优先级4参与PFC流控第二行把优先级4映射到优先级组4PG4确保它与交换机的队列映射关系一致。不过实际上对于Mellanox网卡只要驱动正常加载PFC帧的收发是由硬件自动处理的。你需要关心的只是确认网卡端口开启了PFC协商并且和交换机侧配置一致。CX6网卡默认并不自动开启PFC接收所以如果你在交换机上看到了持续的pause帧计数但网卡并没有真正降速先查网卡端口是否开启了对pause帧的响应。6. 常见问题与排查技巧实录6.1 PFC风暴明明配了为什么队列还是丢包这是我在多个现场踩过的坑。典型的场景是交换机上PFC配置确实做了网卡也开了但RDMA流量一压立刻就有CRC错包或者丢包计数增长。排查思路先看这个信息ethtool -S enp130s0f0 | grep -i pause如果rx_pause数量很多说明网卡收到了大量PFC暂停帧网络已经在反压了。但如果丢包和pause帧同时存在说明暂停帧没能压住发送端大概率是优先级映射不一致。所谓映射不一致是指交换机端让优先级4进入PFC队列但网卡实际发送RoCE流量用的优先级并不是4。解决方法是两边核验交换机上看DSCP映射网卡上用tcpdump -i enp130s0f0 -v udp port 4791抓包看IP头的TOS值是多少然后用dcb pfc show dev enp130s0f0确认网卡PFC设定。这三者一定要对齐。6.2 ECN标记不生效RDMA流量没有被交换机打标另一个常见问题是CNP计数为0但队列延迟很高毫无反应。这种多半是ECN标记没有真正作用于RoCE流量。用华为CE交换机的排查命令display qos wred ecn-profile name rdma_ecn display qos queue statistics interface 10GE1/0/1如果队列4的ECN丢弃计数一直为0说明报文可能根本没进这个队列或者ECN模板没绑定成功。重点检查两部分一是检查DSCP映射是否真的生效。用display diffserv domain default确认46映射到priority 4。二是在接口下确认ECN模板绑定的队列是否正确CE交换机上模板绑定到队列的优先级编号需要和流量的本地优先级一致。另外还要注意一个细节RoCEv2报文进入交换机后能不能被ECN处理取决于交换机是否使能了IP层的ECN识别。部分华为CE交换机型号默认对某些报文类型不启用ECN需要单独开启对应DSCP的ECN识别。6.3 吞吐上不去DCQCN过度抑制有些场景下网络确实不丢包了延迟也低但吞吐就是起不来。这种情况十有八九是DCQCN的参数配得太激进导致网卡频繁降速流量被长期压制在一个很低的速率上。处理方法分两步第一步把交换机侧的ECN水线往上调比如从30%调到50%让ECN标记触发得更晚第二步把网卡侧的ROCE_CC_CTRL_TMIN调大从4微秒调到8或16微秒让速率恢复变慢但更平滑。注意这不是简单地“调大就好”而是要在延迟和吞吐之间找平衡点。我之前在一个分布式存储项目里就遇到过这种情况业务的IO深度很低但并发连接数极多每个流都频繁触发CNP结果整体吞吐只有物理带宽的40%。把ECN水线往上调、CNP采样周期变长之后吞吐回到了90%以上。核心思路是让DCQCN对轻度拥塞不敏感只对真正的拥塞做响应。6.4 常见问题速查表现象可能原因排查命令解决方向RDMA连接建立失败网卡固件/RoCE版本不支持RoCEv2ibv_devinfo -d mlx5_0 | grep roce升级固件切换到RoCEv2丢包计数持续增长PFC优先级映射不一致ethtool -S 网卡 | grep pause对齐DSCP映射和PFC优先级吞吐只有带宽的50%左右DCQCN参数过敏感rdma statistic show link mlx5_0/1调高ECN水线调大TMIN延迟偶发飙高ECN水线太低PFC频繁触发display qos queue statistics抬高ECN水线检查PFC水线交换机显示pause帧异常多buffer配置不足或死锁display pfc deadlock开启PFC死锁检测调整buffer多队列互相影响无损队列和非无损队列共享buffer不当display qos buffer按比例隔离headroom buffer6.5 一个容易被忽略的坑CNP报文的优先级DCQCN的CNP报文也是RoCE报文它在IP头里同样带DSCP值。一个常见的错误是CNP的DSCP和数据的DSCP不一致或者CNP报文本身没有进入无损队列。如果你在网卡侧看到roce_cnp_sent一直增长但交换机侧的队列统计里没有对应的流量那就要检查一下CNP的优先级设置。在rdma_cm的参数cma_roce_tos设置之后CNP和数据报文默认是同一个DSCP。但在某些自研应用里QP创建时显式指定了不同的TOS这就会导致CNP走的是普通队列拥塞反馈无法及时送达。排查方式很简单在两端同时抓包过滤UDP端口4791看CNP报文的IP TOS值是否和数据流一致。不一致的话就是QP创建的TOS参数问题。6.6 实战调整案例从理性参数到最终定型最后分享一个我实际调通的案例供参考。这个案例的诉求是高并发小IO的分布式存储使用RoCEv2承载存储南北向流量物理环境是25G CX6网卡 华为CE6865交换机。初始配置用的是厂商默认推荐值ECN水线为buffer的30%ROCE_CC_CTRL_TMIN4。跑测试后发现4K随机读的延迟符合预期但多流同时读写时总吞吐始终上不了24Gbps业务表现“时好时坏”。我做的调整是把ECN的低水线从30%调到45%高水线从50%调到60%减少正常波动下的ECN标记比例把ROCE_CC_CTRL_TMIN从4调到8微秒交换机PFC水线从默认的60%调整到75%确认CNP报文DSCP与数据流一致避免拥塞反馈走弯路。调整后多流并发吞吐稳定在23.8GbpsPFC pause帧数量比调整前下降了约70%ECN标记数量下降了约60%。这个效果说明无损网络不是“开关一开就完事”参数整定是必须的。我个人在实际操作中的体会是RDMA无损网络的调试是一个“由粗到细”的反复过程。先把PFC跑通、把ECN跑通、把DCQCN跑通确认没有丢包再去调水线和时序参数。不要一上来就追求极致的低延迟先把链路状态稳住再逐步逼近业务侧的性能目标。另外每一次参数调整后记得清空计数器重新压测用数据说话别靠感觉调网络。