PFC(Priority-based_Flow_Control)

在咱们上一节聊到的“高性能网络与存储层”监控中，你敏锐地抓住了那个最核心、也最让网络工程师头疼的词——PFC。

PFC 的全称是 Priority-based Flow Control（基于优先级的流控），它是 IEEE 802.1Qbb 标准定义的一项底层网络技术。

要彻底理解它，你必须先明白我们在 AI 算力集群里为什么要用它：为了给极其娇贵的 RDMA/RoCEv2 网络“保驾护航”。

1. 为什么我们需要 PFC？(以太网的先天缺陷)

传统的普通以太网（比如咱们平时上网、刷视频用的网络）是“尽力而为 (Best Effort)” 的。

• 普通网络的逻辑： 当交换机太忙、缓存塞满时，它的处理方式极其简单粗暴——直接把塞不下的数据包丢掉 (Packet Drop)。反正上层的 TCP 协议发现丢包后，会重新发送。这对看网页没影响。
• AI 算力的噩梦： 咱们买的几百万的 HGX 服务器，为了极低的延迟，走的是 RDMA (RoCEv2) 协议，它绕过了 CPU 直接把数据写到对方的显存里。RDMA 极其害怕丢包！ 一旦丢包，不仅要重传，还会导致整个 GPU 集群在等这一个包，算力利用率瞬间暴跌。

结论： AI 训练需要一张绝对不丢包（无损，Lossless）的网络。而 PFC，就是把普通以太网强行变成无损网络的“魔法”。

2. PFC 是怎么工作的？（红绿灯与反压机制）

你可以把交换机的端口想象成一个收费站，前面有一段极短的缓冲车道（Buffer）。

1. 基于优先级（Priority-based）： 一根网线被划分为 8 个虚拟车道（优先级 0-7）。我们通常把普通的 SSH、监控数据放在 0 道，把金贵的 GPU RDMA 数据放在 3 道或 4 道。
2. 反压机制（Backpressure）： 当交换机发现 3 道（RDMA）的缓冲车道快要停满（达到高水位线）时，在发生车祸（丢包）之前，交换机会顺着网线往回发一个红色的信号——这就是 PFC Pause Frame（暂停帧）。
3. 上游急刹车： 发送端的网卡收到这个暂停帧后，会立刻停止往 3 道发送数据，直到交换机处理完积压的数据，再发一个解除暂停的信号。

精妙之处： 因为是“基于优先级”的，所以交换机只会让 3 道的 RDMA 停下，此时 0 道的普通 SSH 连接和监控数据依然畅通无阻，你依然可以远程登录机器排查问题。

为了让你直观感受这种微秒级的底层网络博弈，我为你搭建了这个 “PFC 无损网络与拥塞控制沙盒”。你可以对比一下，如果没有 PFC，昂贵的 GPU 会经历怎样的灾难：

image.png

3. AIOps 视角的深水区：为什么我们要监控 PFC？

既然 PFC 这么好，能防止丢包，为什么在上一节的监控里，我们要死死盯着 PFC Pause Frames，把它当成大敌呢？

这是因为 PFC 是一把极其危险的双刃剑：

• 传染性与 PFC 风暴： 如果 Node B 处理太慢，连接它的交换机会向上一级交换机发 PFC，上一级再向最源头的 Node A 发 PFC。拥塞会像瘟疫一样瞬间传遍整个机房，导致全网急刹车，这叫拥塞扩散 (Congestion Spreading)。
• 死锁 (Deadlock)： 如果交换机 A 叫 B 停下，B 叫 C 停下，C 叫 A 停下……三个交换机形成了一个闭环，谁都不发数据，这叫 PFC 死锁。此时整个集群的 GPU 会被瞬间“点穴”，算力利用率直接跌成一根 0 的直线，只能靠网络工程师强行重启交换机端口来解决。

这就是 AIOps 的价值所在：当你看到大屏上某台机器的 PFC 暂停帧/秒 突破了几千，虽然此刻还没丢包，但这就相当于这台机器正在疯狂踩急刹车。作为架构师，你需要立刻定位是谁在疯狂发流量（比如某个存储备份任务占用了 RDMA 通道），并将其限速，在引起“PFC 风暴全网大堵车”之前把隐患掐死。