pfc必须两端同时开启且优先级严格对齐，单边配置无效；linux侧需用ethtool -s查pfc计数、devlink或/sys/class/net/.../pfc路径设掩码，交换机侧须禁用dcbx自动协商、改用manual模式并匹配阈值与缓冲区。
必须两端同时开启且优先级严格对齐，单边配置等于没配。
Linux网卡侧PFC使能：用ethtool查状态、mlnx\_tune或devlink配参数
Linux服务器侧PFC是否生效，不看内核模块是否加载，而要看网卡硬件队列是否真正启用了PFC。Mellanox/CX系列网卡最常用的是ethtool -a和devlink dev param set组合；NVIDIA BlueField DPU则倾向用mlnx_tune -p一键调优。
-
ethtool -a <code>enp3s0f0显示Pause on为off，不代表PFC关闭——它只反映传统802.3x流控，PFC需单独查：ethtool -S <code>enp3s0f0| grep pfc，关注rx_pause/tx_pause计数是否增长 - 启用PFC前必须确认DCB协商已就绪：
cat /sys/class/net/<code>enp3s0f0/device/mlx5/ports/1/pfc应返回enabled或具体优先级掩码（如0x80表示仅优先级7） - 手动配置优先级掩码（以启用优先级7为例）：
echo 0x80 > /sys/class/net/<code>enp3s0f0/device/mlx5/ports/1/pfc；注意该路径在不同驱动版本中可能含mlx5_core或pci子目录，务必先ls确认 - 若用
devlink（推荐新环境）：devlink dev param set pci/<code>0000:03:00.0name pfc_enable value true，再用devlink dev param set ... name pfc_priority_mask value 0x80
交换机侧PFC配置：避免dcb pfc enable mode auto引发协商失败
很多厂商文档默认推荐mode auto，但实际生产中这是高危操作。DCBX协议在多厂商混合环境中极易因TLV字段解析差异导致协商中断，最终PFC静默失效。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 强制使用
mode manual，绕过DCBX协商，直接硬编码优先级行为。华为/Cisco/H3C主流设备均支持：dcb pfc enable mode manual - 优先级阈值必须与网卡侧匹配：交换机上
pfc priority 7 buffer-size 80 threshold 80中的80指缓冲区占用率80%触发暂停，若网卡侧设为75%，会出现“交换机已发暂停帧但网卡还没开始停”的窗口期，导致丢包 - 务必检查端口物理层状态：
display interface <code>10ge1/0/1中DCB status: up且PFC status: enabled同时成立才算真正就绪；仅DCB status: up不能说明PFC已激活 - 禁用所有未使用的优先级PFC：比如只用优先级7跑RoCEv2，就只开7，不要顺手把0-6全enable——这会放大反压传播范围，诱发上游非关键链路误暂停
PFC优先级映射一致性：802.1p标签必须从应用层穿透到网卡硬件队列
常见故障是流量根本没进PFC保护的队列。比如RoCEv2报文打了DSCP=26，但交换机没做DSCP-to-802.1p映射，或者网卡没把DSCP映射到硬件优先级7，结果所有包都落在默认优先级0，而0又没开PFC，等于裸奔。
- 在网卡侧验证映射是否生效：
tc qdisc show dev <code>enp3s0f0应看到mq或多队列qdisc，且tc class show里有明确按priority分的class（如class mq 1:7） - 交换机上必须显式配置映射表，例如华为：
traffic classifier roce operator and→if-match dscp 26→traffic behavior roce→remark 8021p 7→traffic policy roce→classifier roce behavior roce - 绕过中间设备干扰的快速验证法：直连交换机与服务器，用
tcpdump -i <code>enp3s0f0-nn -e vlan[0] & 802.1p抓包，确认RoCE报文的802.1p字段确实是7
PFC调试时最易忽略的三个硬性依赖
即使所有配置命令都执行成功，以下三点任一缺失都会让PFC形同虚设。
- 物理链路必须支持Pause帧：某些白盒交换机或老旧网卡固件默认禁用Pause帧接收/发送能力，需在BIOS/UEFI中打开
Flow Control选项，或刷写支持DCB的firmware - MTU必须统一且足够大：RoCEv2推荐MTU=4096，若交换机端口MTU=1500而网卡设为4096，PFC暂停帧虽能发出，但大包在途中被分片，导致拥塞检测失准；建议全链路设为
9000（jumbo frame）并验证ping -M do -s 8972 <code>peer_ip不丢包 - 缓冲区大小不可为零：部分交换机型号（如早期Cisco Nexus）在PFC enable后若未显式分配buffer，会默认给PFC队列0字节缓冲，此时暂停帧一发，上游立即停发，但下游根本来不及排水，造成死锁；必须手工配置
pfc priority 7 buffer-size 16等非零值
真正难的不是敲出那几条命令，而是确认每一跳设备的缓冲区阈值、优先级映射、Pause帧收发能力全部对齐——少一个环节，PFC就只是个漂亮的开关。
