1. 概述PFCPriority Flow Control优先级流控在链路层按优先级暂停发送避免缓存溢出丢包ECNExplicit Congestion Notification显式拥塞通知在 IP/传输层给报文打拥塞标记让发送端主动降速。 二者分别解决「不丢包」和「别把队列堆满」两个问题常在 RoCEv2、存储与 AI 集群中组合使用。具体来说PFC 工作在数据链路层通过 IEEE 802.1Qbb 标准定义的 MAC Control 帧在接收端缓存即将耗尽时向对端发送 Pause 帧暂停指定优先级的流量发送从而避免因缓存溢出导致的丢包。它关注的是「这一跳」的可靠性确保无损转发。而 ECN 工作在 IP 层和传输层依据 RFC 3168由交换机在出口队列深度超过阈值时对带有 ECTECN-Capable Transport标记的报文打上 CECongestion Experienced标记接收端收到后通过反馈机制通知发送端降低发送速率。它关注的是「端到端」的拥塞控制从源头减少注入网络的流量。两者分工明确、互为补充PFC 解决的是「队列已满、即将丢包」的硬性问题ECN 解决的是「队列将满、提前降速」的软性问题。PFC 是最后的兜底防线ECN 是前置的主动调节。在 RoCEv2、NVMe over Fabrics 以及 AI 大模型训练集群等对丢包极度敏感的场景中二者通常组合使用形成「ECN 先行降速、PFC 兜底保底」的双层防护机制。同时启用时门限必须满足Kmin ≤ Kmax XOFF且 AC5P 上有效 Resume 水位XOFF − XON应高于 Kmax确保 ECN 的标记区与 PFC 的暂停区之间有足够的缓冲间隔避免两者相互干扰、频繁触发。PFC 链路层、按优先级停发标准IEEE 802.1Qbb。接收端队列将满时向对端发送 Pause暂停指定优先级的发送队列回落后再发 Resume。目标是无损转发。ECN 网络层、标记后降速标准RFC 3168。交换机在出口队列用WRED看水位对 ECT 包打 CE接收端反馈给发送端降速。须与 WRED 联用见4.3 节。2. 为什么传统以太网不够用经典以太网是有损lossy的交换机缓存不够就丢包由 TCP 超时重传恢复。这对 Web、文件传输通常可接受但对下列业务代价很大RDMA / RoCEv2丢一个包往往触发 go-back-N 重传吞吐骤降、时延抖动放大。NVMe over Fabrics、分布式存储尾时延敏感丢包会把 IO 拉长一个数量级。AI / HPC 集合通信一次 AllReduce 被最慢的那条流拖住尾时延决定作业时间。因此数据中心引入 DCBData Center Bridging能力用 PFC 把指定优先级做成近似无损再用WRED ECN配合 DCQCN 等在队列真正溢出前把流量压下来。其余优先级仍可走普通有损转发避免全网被 Pause 冻住。3. PFC 原理3.1 与 802.3x Pause 的差异IEEE 802.3x 的 Pause 是整条链路停发一个优先级队列满了所有流量一起停。这会造成低优先级的尽力而为流量把高优先级业务一起卡住无头阻塞Head-of-Line Blocking一条拥塞流拖死同口其他流。PFC802.1Qbb把 Pause 细化到8 个优先级Priority 0–7通常与 802.1p CoS / DSCP 映射对应。只有被启用 PFC 的优先级会被暂停其他优先级继续转发。对比项802.3x Pause802.1Qbb PFC作用粒度整条物理链路单个优先级最多 8 个帧类型MAC Control PauseOpcode 0x0001MAC Control PFCOpcode 0x0101时间字段1 个 pause_time8 个 Class Enable Vector 8 个 pause_time典型用途早期全双工流控现已少用数据中心无损以太、RoCE 队列3.2 工作流程以「服务器 A → 交换机 → 服务器 B」中交换机入端口缓存将满为例报文按 CoS/DSCP 进入对应优先级队列。该队列占用超过XOFF 阈值交换机向上游发送端发出 PFC PauseXOFF携带该优先级的暂停时间。上游停止发送该优先级的帧其他优先级不受影响。队列占用从 XOFF 起再下降XON 窗口值AC5P 为 offset即占用 ≤ XOFF−XON后交换机发送 Resumepause_time0或等 Pause 超时上游恢复发送。上游设备发送端交换机队列Pri 3 将满 → XOFF回落 → XON下游设备接收端数据Pri 3PFC Pause / ResumePause 只停 Pri 3Pri 0–2、4–7 仍可转发图 1 PFC 按优先级反压数据向下游走Pause 向上游走Pause 帧目的 MAC 为组播01-80-C2-00-00-01EtherType 为 MAC Control0x8808。Class Enable Vector 的 bit 指示本次要对哪些优先级生效每个优先级带独立的pause_time以 512 bit-time 为单位。3.3 PFC 协议如何工作PFC 是逐跳、按优先级的硬反压拥塞点不修改业务报文只额外发出一张 MAC Control 帧命令对端「这个优先级先别发」。帧格式实现时真正解析的字段字段内容作用目的 MAC01-80-C2-00-00-01链路内组播不转发到其他口EtherType / Opcode0x8808/0x0101与 802.3x PauseOpcode0x0001区分Class Enable Vector16 bit常用低 8 bit 对应 Pri 0–7为 1 的优先级本次 Pause 生效pause_time[0..7]各 16 bit单位 512 bit-time0 为 XOFF 时长0 为 ResumeXON100GE 上 1 个 quanta ≈ 5.12 nspause_time65535 大约能停几百微秒量级。对端可以在超时前被新的 Pause 刷新再次 XOFF 则续命收到 0 则立刻恢复。两端状态机接收端拥塞点发 Pause 的一方芯片按端口优先级常称 PGPriority Group统计已用缓存。占用 ≥ XOFF → 该入方向对邻接体发 Pause占用降至 XOFF−XONAC5P 窗口语义或满足 NOS 定义的 Resume 条件 → 发 Resume 或停止刷新 Pause让对端超时恢复。发送端被停的一方MAC/调度器冻结该优先级的出队其他优先级照常。已上链路的 in-flight 帧停不下来必须由对端 Headroom 吞掉。不改数据报文业务帧的 IP/TCP 头完全不动。所以 PFC 对端系统拥塞控制「看不见」只能看到「对端突然不收了」。PFC 作用在这一跳的入方向缓存是「这个邻居还在灌我先让他停」。它不能指定「只停某一条流」同优先级的所有流一起停。这就是后面必须用 ECN 做流级降速的原因。3.4 PGPriority Group优先级组是什么PG Priority Group优先级组。它是交换机 MMU 在入方向上给缓存记账、决定是否发 PFC Pause 的单位。前面说的「入向 PG」就是「某个入端口上的某一个优先级组」。这里的 MMU 指什么MMU Memory Management Unit缓存管理单元。在交换芯片语境下它管的是 ASIC 里那块包缓存Packet Buffer报文进来占多少 cell、记在哪个入向 PG、要从哪个出向队列出去、水位到了是 Pause、打 CE 还是丢包。PFC 的XOFF与 ECN 的Kmin/Kmax是 MMU水线AC5P 上XON 是 Resume 窗口offsetHeadroom、Guaranteed是容量Size——见 3.5.1 节。不是 Linux 内核里的东西。和 CPU 里的 MMU同名不同物。CPU MMU 把虚拟地址翻译成物理页跑 Linux 的那颗核用。交换芯片 MMU 给线速转发的包分配片上/外挂缓存。看show buffer/ PFC 计数时说的是后者看free -m/ OOM 时说的是 CPU 内存。不要和下面几个词混成一个东西名称是什么出现在哪CoS / 802.1p 优先级VLAN 标签里的 3 bit取值 0–7表示这张帧属于哪类业务报文头PFC 优先级Pause 矢量Pause 帧 Class Enable Vector 的 bit0–bit7对端按这个停哪一类发送PFC 协议帧PGPriority Group芯片把一个或多个 CoS归并成一组这一组共用一块入向缓存账本Guaranteed / Service / Headroom、XOFF/XONMMU 入向资源出向队列出端口上按调度用的队列ECN/WRED 多看这里MMU 出向每个物理口上通常有若干 PG很多芯片最多 8 个编号 PG0–PG7。报文进来后看 CoS/DSCP → 映射到某个 PG →占用记在「本端口 该 PG」上。该 PG 的 Service 顶到 XOFF就只对这个 PG 对应的优先级发 Pause其他 PG 不受影响。为什么不直接叫「优先级」而叫「组」8 个 CoS 不必做成 8 套完全独立的无损缓存。常见做法是CoS 3RoCE→PG3无损单独的 Service Headroom开 PFCCoS 0/1/2/4… →同一个有损 PG共享一块 Service没有 Headroom、不开 PFC满了就丢。「组」的意思就是几个优先级可以挤进同一本入向账真正触发 Pause 的粒度是 PG不是任意一条流。Pause 帧上仍用 0–7 的优先级 bit 告诉对端停哪一类这些 bit 与 PG 的映射必须两端一致。口令入向 PG 入端口优先级组这一对上的缓存计数器。出口堵不会单独产生 Pause是「从这个口、这个 PG 进来还没出去的字节」把这本计数器抬到 XOFF该口才向外发 Pause。3.5 缓冲区与阈值PFC 能否「真无损」取决于缓存和阈值是否覆盖反压回路时延所需余量 ≈ 链路带宽 ×往返时延 设备内部处理时延XOFFPause 阈值队列占用达到该值就开始停上游。必须低于队列上限并留出「Pause 发出到上游真正停发」这段时间里仍会涌入的数据。XONResume 窗口AC5P 上为相对 XOFF 的回差 cell 数占用须从 XOFF 再下降 XON 才 Resume避免 Pause/Resume 抖动。HeadroomXOFF 到队列尾之间的空间专门吸收 in-flight 报文。25GE/100GE 且线缆较长时in-flight 字节数显著增加必须加大无损队列缓存或缩短 PFC 域例如只在 ToR 与服务器之间启用而不跨整张 Fabric 无限制蔓延。3.5.1 水线还是 Size—— 别混成一个数字配置 PFC 时最常见误解把XON、XOFF、Headroom都当成「缓存大小」。 在 Marvell Prestera /AC5PAlleyCat5P等芯片上三者角色不同XOFF 是绝对水线AC5P 上 XON 是窗口/回差offset不是第二条绝对水线Headroom 是容量Size。参数本质典型单位作用XOFF水线cell入向 PG 占用 ≥ XOFF → 发 PauseXONAC5P窗口 / 回差offsetcell自 XOFF 触发后占用须再下降 ≥ XON cell 才 Resume不是绝对占用水线Headroom容量 SizecellPause 空窗期 in-flight 报文的专有缓存区Guaranteed容量 Sizecell队列/PG 保底专有缓存别人抢不走ECN Kmin/Kmax水线cell 或相对动态上限出向队列深度触发 CE 标记见 4.3 节口令水线决定「什么时候动作」Size 决定「最多能存多少」。XOFF 只比较当前占用计数本身不占 bufferHeadroom 是真实划出来的 cell 池。水线与 Size 的区别及影响维度水线XOFF / XON / Kmin / KmaxSizeHeadroom / Guaranteed / Pool回答的问题占用到多少 cell 该 Pause / Resume / 打 CE这块区域最多能占多少 cell是否占 buffer否只是与计数器比较的点是硬件真实容量上限配太小过早 Pause / Resume 难解除、ECN 过早打标易丢包、队列饿死、无损失效配太大Pause 太晚Headroom 前先溢出占死全局 buffer其他 PG/队列受影响与 ECN 联用时两类参数必须一起规划。AC5P上绝对水线顺序为0 Kmin ≤ Kmax XOFF Limit XON 为回差窗口有效 Resume 绝对水位约为XOFF − XON见 3.5.2 节。Headroom_size ≈ Limit − XOFF概念高度见 6.3 节。3.5.2 设备 上的 XON / XOFF / HeadroomAC5P MMU 在入向 PG上按 Guaranteed / Service / Headroom 三段划分出向无 Headroom。 PFC 三个参数落在不同段入向 PG无损如 RoCE CoS3 → PG3 ┌─────────────────────────────┐ │ ③ Headroom ← Size 配额 │ Pause 后继续到达的 in-flight ├─────────────────────────────┤ │ ② Service Pool ← XOFF 绝对水线在此 │ XOFF 触发 PauseXON 为回差窗口 │ DBA 动态借共享池 │ ├─────────────────────────────┤ │ ① Guaranteed ← Size 配额 │ 保底专有 └─────────────────────────────┘XOFFPause 水线监控对象入向 PG 在 ② Service 区的占用Guaranteed 用完后在共享池里涨的部分。当PG_used ≥ XOFF向邻接发 PFC Pause对应优先级 bit。必须低于 ② 可借上限并在进入 ③ 之前触发——否则还没 Pause 就先满。若启用DBA4.9 节② 的动态上限Q_limit随共享池变化CLI 里的 cell 数可能是相对值核算前查 NOS 手册。XONResume 窗口 / 回差AC5P 特有语义在AC5PPrestera AlleyCat5P及多数 Marvell Prestera MMU 实现上 CLI 里的pfc resume-threshold/xon/xon_offset配置的是Resume 窗口值offset不是「占用降到 XON 这条绝对水线就 Resume」。Pause 触发 PG_used ≥ XOFF → 发 Pause持续刷新直至解除 Resume 触发 PG_used ≤ XOFF − XON → 发 Resumepause_time0 等价表述自触发 Pause 后占用须再下降 ≥ XON cell 才解除 有效 Resume 绝对水位 XOFF − XONoffset 例XOFF10000 cellXON2000 cell → 占用降到 ≤8000 cell 时 ResumeXOFF唯一需要放在绝对水位轴上的 PFC Pause 门限。XON相对 XOFF 的回差窗口越大表示须排空越多才 ResumePause 维持越久。XON 过小占用刚略低于 XOFF 就 Resume上游立刻再灌 → Pause/Resume 振荡见 6.5 节。XON 过大队列已缓解仍长期 Pause吞吐恢复慢、尾时延拉长。与 ECN 联用时希望Kmax (XOFF − XON)即全打标区仍在 Resume 绝对水位之上避免刚 Resume 又立刻打满。少数其他厂商 NOS 把 XON 配成绝对水线PG_used ≤ XON_abs才 Resume。 读 AC5P/OEM 手册时先确认若参数名含offset、delta、xon_offset或说明为「相对 XOFF 的回差」则按窗口值理解不要把 XON 数值与 XOFF 直接比大小。HeadroomSize不是触发水线③ 整段是专有 SizePause 已发出、对端尚未停发时链路上 in-flight 帧仍会继续到达只能占用 Headroom。Headroom用尽才是真正溢出无损 PG 仍可能丢包不是 XOFF 本身触发丢包。Headroom 必须不可被其他 PG 抢占有损流量不能与无损 PG 抢同一块 Headroom pool。Headroom_size ≥ 链路带宽 × Pause 回路时延 100GE 粗算每 1 µs 回路时延 ≈ 12.5 KB in-flight 例回路 2 µs → Headroom 至少约 25 KB再乘 cell 对齐、芯片流水线、多跳余量与 ECN 门限的分工AC5P 同时开启时观察点参数类型触发顺序ECN出向队列深度Kmin/Kmax 水线先端侧 DCQCN 降速PFC入向PG 占用XOFF 绝对水线XON 窗口 offsetAC5P后CNP 来不及时的兜底PFC 兜底入向HeadroomSize最后吞 in-flight配错时的典型现象问题根因现象有 Pause 仍丢包HeadroomSize 不足或 XOFF 水线太高PFC 计数有同时 ingress drop / MMU discardPause 风暴、吞吐锯齿XON 窗口过小回差不足Pause 帧速率极高过早 Pause、ECN 无效XOFF 水线太低或 ② DBA 过紧Pause 常态CE/CNP 很少只调 XOFF 不调 Headroom把水线当成容量理解XOFF 后 in-flight 无空间 → 丢包CLI 映射名称随 OEM/NOS 而异优先级DSCP 24 → CoS 3 → PG 3无损 pfc enable priority 3 pfc pause-threshold XOFF # 绝对水线PG_used ≥ XOFF → Pause pfc resume-threshold XON # AC5P窗口/回差 cellResume 当 PG_used ≤ XOFF−XON pfc headroom N cells # SizeHeadroom 池容量 mmu queue-guarantee … # SizeGuaranteed mmu queue-threshold … # Size/共享上限视平台 mmu buffer-mode flowctrl-enhance # Marvell 系 PFC 场景常用全局模式测试时区分两类问题show interface … pfc看 PG 是否在 XOFF 附近波动水线 Pause 期间若仍 discard查 Headroom 是否顶满Size。 DBA 场景还需同时读共享池P_used与 PGQ_limit4.9 节。3.5.3 如何测出 XON 窗口值AC5PXON 是配置出来的 offset测试目的是验证「硬件实际 Resume 条件是否等于PG_used ≤ XOFF − XON」并量化有效回差是否与 CLI 一致。 推荐先只开 PFC、关 ECN/DCQCN避免 CNP 降速干扰 PG 水位。方法一PG 占用 Pause/Resume 时刻对齐最准推荐拓扑仪表/主机 A → 交换机入端口 PiPFC 开→ 出端口 Po 接仪表 B 或 shaping 堵死。记录配置XOFF、XONresume-threshold、CoS→PG 映射、cell 字节数。在发 Pause 的交换机上高频采样入向 PG 占用脚本轮询show mmu/show buffer pg等间隔 110 ms命令名随 NOS。同时在 Pi 链路上抓包或读show interface … pfc的pfc_tx_pause/pfc_tx_pause_duration。制造稳态拥塞Pri3无损线速打入Po 限速或 B 不接收直到首次发出 Pause。记录首次 Pause时刻的PG_pause应 ≥ 配置 XOFF通常贴近 XOFF。保持瓶颈等出口继续 drain记录首次 Resumepause_time0或停止刷新 Pause时刻的PG_resume。测得 XON ≈ PG_pause − PG_resume 或Pause 恰在 XOFF 触发时XON ≈ XOFF_config − PG_resume 判定|测得 XON − 配置 XON| ≤ 若干 cell对齐/采样误差→ 通过若采样周期 10 ms可能错过尖峰Pause/Resume 测试建议中等拥塞PG 在 XOFF 附近停留数十 ms或改用交换机 MMU 快照/告警阈值触发记录。方法二仅抓 PFC 帧无 MMU 计数时在 Pi 对端或 Pi 口 SPAN 抓包过滤eth.type 0x8808 pfcWireshark 显示过滤器因版本而异 Pause pause_time[pri] 0 Resume pause_time[pri] 0统计同一优先级连续 Pause 帧与第一个 Resume 帧的时间间隔T_pause。同时读出口 drain 速率R_egressshaping 已知时可直接用配置值。粗算排空量Δbytes ≈ R_egress × T_pause换算 cell 后与配置 XON 比对误差较大仅作辅助。此法不能单独作为验收因 drain 非恒定、还有芯片内部并行调度须与方法一或方法三交叉验证。方法三配置扫参验证「窗口」行为而非绝对数值固定 XOFF只改 XON观察 Pause/Resume 振荡频率配置 XON预期现象说明很小如 256 cellpfc_tx_pause速率很高吞吐锯齿刚低于 XOFF 就 Resume → 证实 XON 是 offset 而非绝对水线适中Pause 偶发尖峰PG 在 (XOFF−XON)XOFF 波动健康回差很大Pause 维持时间长恢复慢XON 越大须排空越多才 Resume若把 XON 当成绝对水线去配例如 XON8000、XOFF10000却出现「占用远高于 8000 仍 Pause、远低于 8000 才 Resume」 即可反证 AC5P 按XOFF−XON生效。方法四发送端 pfc_rx 与交换机 PG 对时发送端网卡统计pfc_rx_pause/pfc_rx_pause_durationethtool -S 或厂商工具。交换机侧同步采 PG 占用 pfc_tx_pause。对齐时间戳发送端「收到 Pause」≈ 交换机「发出 Pause」 链路延迟发送端「Pause 结束」≈ 交换机 Resume 延迟。在交换机 Resume 瞬间读PG_resume用方法一公式算 XON。测试前置与注意关 ECN / 仪表不响应 CNP否则发送端提前降速PG 到不了 XOFF测不到完整 Pause/Resume 周期。只测目标 PG背景流映射到非 PFC 优先级避免其他 PG 抢共享池DBA 下Q_limit会变。单跳、单入端口 incast多入端口同时 Pause 时各 PG 独立计数别混读。cell 对齐PG 读数与 CLI 配置同为 cell若平台显示字节除以每 cell 字节数再比。区分 Pause 刷新与 ResumeXOFF 期间会周期性重发 Pausepause_time0只有pause_time0才是 Resume别把刷新帧当 Resume。Headroom 未顶满若 Pause 期间有 discard先查 Headroom不要误判 XON。最小验收脚本逻辑示例# 伪代码轮询直到观察到一轮完整 Pause → Resume prev_pause_cnt 0 while not done: pg read_pg_used(port, pg_id) # cell tx_pause read_pfc_tx_pause(port, pri) if tx_pause prev_pause_cnt and pg_pause is None: pg_pause pg # 首次 Pause if saw_pause and is_resume_frame(pri): # pause_time0 或计数器回落 pg_resume pg xon_meas pg_pause - pg_resume break prev_pause_cnt tx_pause sleep(1ms)口令测 XON 在首次 Pause 与首次 Resume 之间看 PG 多降了多少 cell。应与配置 XON 一致若测得 XON≈0 行为刚 Pause 就 Resume说明窗口配太小或采样太粗。3.5.4 AC5P 400G 端口 XOFF / XON 推荐起点Marvell 公开的 AC5P MMU 手册不给出固定 cell 级的 XOFF/XON 出厂值PFC 场景默认走mmu buffer-mode flowctrl-enhanceOrion/Marvell OEM MMU 指南具体门限由 NOS 在 CPSS 上映射为pfc pause-threshold/pfc resume-threshold。 下列推荐按IEEE PFC Headroom 算法 400G 线速 AC5P 浅缓冲 XONoffset推导须在本机用 3.5.3 节实测收敛。推导前提核算前必查项说明如何确认cell 字节数下文按256 B/cell估算Prestera 系常见以平台为准show mmu/ CPSS 文档 / NOS 手册PG 可用上限 Q_limitDBA 下动态变化文档算例常用~12200 cell作单口量级参考4.9 节拥塞时读 PGQ_limit、P_usedPause 回路时延 T_loop线缆往返 两端检测/发帧/停调度DC 典型1.55 µs抓 Pause→对端停发间隔或按距离估算400G 每 µs in-flight400 Gbit/s ÷ 8 ≈50 KB/µs100G 为 12.5 KB/µs固定公式Step 1先算 HeadroomSize非 XOFFHeadroom_bytes ≈ 400G × T_loop / 8 2×MTU PFC_frame ≈ 50 KB/µs × T_loop ~20 KB开销余量 Headroom_cells ≈ Headroom_bytes / 256 例T_loop 3 µs → 150 KB 20 KB ≈ 170 KB → ~665 cell → 建议配 768 cell向上取整Headroom 用pfc headroom单独配不是XON。Step 2定 XOFF绝对水线原则XOFF须满足Limit − XOFF ≥ Headroom_sizePause 后 in-flight 有处放XOFF ≫ Kmax与 ECN 联用时CNP 空窗在 KmaxXOFF见 6.2.1 节在 AC5P 浅缓冲上XOFF 约为 PG 可用 Service 预算的55%70%不宜顶满 Q_limit。XOFF ≈ Q_limit × (0.550.70) − Headroom_margin Q_limit ≈ 12000 cell 时XOFF 粗算 62007800 cell视 Headroom 与 DBA α 微调Step 3定 XONResume 窗口 offsetAC5P 上 XON 不是绝对水线。400G 排空极快回差过小会 Pause/Resume 振荡过大则恢复慢。建议 XON_offset max( 1536 cell, // 400G 最低回差≈384 KB XOFF × 12% XOFF × 20% // 或按 XOFF 比例 ) 有效 Resume 水位 ≈ XOFF − XON推荐配置表400Gcell256 B/cell场景T_loopHeadroom(Size)XOFFXON(offset)有效 Resume≈ToR ↔ NICDAC/AOC ≤3 m~1.5 µs38451252006000153636644464Leaf-Spine30100 m MMF~3 µs640768620072002048256036405152长距 / 多跳300500 m~57 µs1024140868007800307237284728首选起点多数 400G AI/RoCE Leaf-Spine100 m 内pfc pause-threshold 6800 # XOFFcell pfc resume-threshold 2048 # XON 窗口cellResume 当 PG_used ≤ 6800−2048 4752 pfc headroom 768 # Sizecell3 µs 回路量级与 ECN 配套同端口 400G仅开无损 PG须满足Kmax XOFF − XON。与上表 XOFF6800、XON2048 配套时Kmin 400600 cell 出口 WRED 低门限浅缓冲 Kmax 24003200 cell 须 4752给 DCQCN 留 ≥1 RTT 空窗 顺序 Kmin ≤ Kmax (XOFF−XON) XOFF理由摘要XOFF 随 T_loop 上移400G 每 µs 多 50 KB in-flight回路越长须在更早水位 Pause为 Headroom 留空间IEEE 802.1 PFC headroom 思想。XOFF 不宜过高AC5P 片上共享 SRAM 浅XOFF 顶满 Q_limit 则 Headroom 池不足 → 有 Pause 仍丢包。XOFF 不宜过低与 Kmax 间距不够 → CE 已有即触发 Pause6.2.1incast 下 DCQCN 来不及降速。XON 取 15363072 cell400G 下单次 Resume 须排空数百 KB 量级才有稳定回差512 cell 易振荡4096 cell 恢复过慢。与 100G 不是 4× 关系线速 in-flight 乘 4但片上 Q_limit 不乘 4故 XOFF 绝对值约为 100G 推荐~17002500 cell 量级的2.53×而非 4×。验收标准incast 突发CE/CNP 有PFC Pause 仅短尖峰稳态 Pause≈0。方法三扫参XON256 振荡、XON2048 平稳 → 证实 offset 语义。方法一测得PG_pause − PG_resume ≈ 2048 cell与配置 XON 一致。无 Headroom discard无长时间 PG 顶在 XOFF 不 Resume除非真死锁。上表为工程起点非 Marvell 保密手册中的固定常数。上线前须结合本机Q_limit、cell 大小、线缆 RTT、incast 扇入 N 用 3.5.3 节实测微调。3.6 风险与副作用PFC 死锁Deadlock环形依赖下互相 Pause队列无法排空。多见于有环、非对称调度或优先级映射错误。检测与恢复机制见 3.7 节。PFC 风暴Pause 在多跳之间传播把拥塞从热点扩散成大面积停发。不公平与队头阻塞同一优先级内仍可能 HOL大象流会拖死同优先级老鼠流。与有损业务混跑不当若把所有流量都映射到 PFC 优先级Pause 会冻住整网失去「按优先级隔离」的意义。PFC 解决的是「这一跳不要丢包」并不减少注入网络的流量。没有 ECN/DCQCN 等拥塞控制时发送端会继续全速打Pause 会沿着路径向上游蔓延。生产环境几乎总是「PFC ECN」一起开而不是只开 PFC。
