3. 流控机制概述
3.1 为什么需要流控：IB网络中的“拥堵”本质
InfiniBand（IB）网络以高带宽、低延迟著称，但其底层物理链路并非无限容量。当多个发送端（HCA，Host Channel Adapter）同时向同一接收端（如目标HCA或交换机端口）注入数据时，瞬时流量可能超过接收端缓冲区（Buffer）的处理能力。若没有流控机制，数据包将在接收端被无条件丢弃，而IB的可靠传输服务（RC，Reliable Connection）会触发重传，重传又进一步加剧网络拥塞，最终形成“拥塞崩溃”（Congestion Collapse）。
IB流控的核心目的可以归纳为三点：
- 防止缓冲区溢出：确保发送端不会向接收端发送超过其可用缓冲区容量的数据，从物理层面杜绝因丢包导致的重传风暴。
- 实现链路级公平性：让共享同一条物理链路的多条数据流（Flow）能够按权重或优先级合理占用带宽，避免单一流“饿死”其他流。
- 构建端到端的可靠性基础：为上层传输协议（如RC、UC、UD）提供“链路不丢包”的假设前提，使上层协议可以专注于报文重组和错误检测，而非处理频繁的重传。
3.2 IB流控的两大类型：链路层流控与端到端流控
IB流控体系分为两个层次，分别作用于不同的时间尺度和网络范围。下表对比了二者的核心差异：
| 对比维度 | 链路层流控（Link-Level Flow Control） | 端到端流控（End-to-End Flow Control） |
|---|---|---|
| 作用范围 | 仅限相邻两个物理端口之间（点对点） | 跨越整个网络，从源HCA到目的HCA |
| 实现机制 | 基于信用（Credit）的令牌机制 | 基于接收端通告的可用信用或窗口 |
| 时间尺度 | 纳秒~微秒级，逐跳实时响应 | 微秒~毫秒级，随数据包往返传播 |
| 主要目的 | 防止物理链路缓冲区溢出 | 防止目的端HCA内存池耗尽 |
| 协议位置 | IB链路层（物理层之上） | IB传输层（L4） |
3.3 链路层流控（LFC）工作原理：基于信用的逐跳机制
链路层流控是IB网络中最基础、最实时的一层保护。其工作原理可以概括为“发送前先借信用，信用不足则等待”。每个IB物理端口在初始化时，会与对端交换各自的接收缓冲区大小，并据此划分出若干个信用单元（Credit）。每个信用单元通常对应64字节的接收能力。
具体流程如下：
- 信用初始化：链路初始化时，接收端（Receiver）通过管理报文（如SMP）告知发送端（Transmitter）其可用的初始信用总数（Initial Credits）。
- 发送扣减：发送端每发送一个数据包，就根据包长扣除相应数量的信用。例如发送一个4KB的包，若信用单元为64B，则需扣除64个信用。
- 信用返还：接收端从缓冲区中取走数据并交给上层处理后，会通过专用的流控报文（Flow Control Packet）或数据包中携带的“信用更新”字段，将释放的信用返还给发送端。
- 暂停与恢复：当发送端的信用计数器降为0时，必须立即停止发送任何数据包，直到收到新的信用返还。这一机制保证了发送端永远不会超出接收端的物理缓冲能力。
perftest 或 ibstat 查看端口状态，但信用计数属于内部硬件寄存器，通常不直接暴露。更实用的方法是监控 LinkDownedCounter 和 RcvErrors，若这两个计数器持续增长，往往意味着链路层流控未能有效工作或物理链路存在信号完整性问题。
3.4 端到端流控（E2E Flow Control）工作原理：面向连接的信用管理
与链路层流控不同，端到端流控作用于一条完整的逻辑连接（QP，Queue Pair）。它解决的是这样一个问题：即使每条物理链路都不丢包，如果目的端HCA的处理速度跟不上多个发送端的总注入速率，目的端的内存池（Receive Queue）依然可能被耗尽。
IB的端到端流控主要依赖传输层头部的信用字段（Credit Field）实现。其核心逻辑如下：
- 每个QP在建立时，接收端会分配一个初始的接收信用额度（例如，允许发送端发送N个报文或N字节）。
- 发送端每发送一个报文，本地维护的“可用信用”就减少1（或减少报文长度对应的信用值）。
- 接收端每从接收队列中取走一个报文并完成处理（即释放了缓冲区），就通过下一个返回的ACK报文或专用报文，将信用返还给发送端。
- 当发送端的可用信用耗尽时，即使链路层信用充足，发送端也必须暂停发送，等待接收端返还信用。
值得注意的是，IB的端到端流控与TCP的滑动窗口有本质区别：TCP的窗口以字节为单位且动态调整，而IB的信用机制以报文或固定粒度为单位，且通常在QP建立时静态协商，运行中不动态改变（除非使用扩展可靠连接XRC等高级特性）。这种静态特性使得IB的端到端流控具有极低的延迟开销，但也要求应用或中间层必须合理设置QP的接收队列深度（RQ Size）。
3.5 核心原理图解：两级流控的协同工作
为了更直观地理解两级流控如何在不同位置发挥作用，下图展示了从源HCA经过两级交换机到达目的HCA的路径中，链路层流控与端到端流控的覆盖范围及协作关系。
上图清晰地展示了：橙色箭头代表数据包沿物理链路逐跳转发，每一跳之间都有蓝色虚线表示的链路层信用返还机制在实时运作；而绿色虚线则代表端到端信用返还，它跨越所有中间交换机，直接从目的HCA返还至源HCA。这种“逐跳保底、端到端保收”的双层设计，是IB网络在高负载下仍能保持极低丢包率的关键。
3.6 典型场景与配置误区
场景：某高性能计算集群运行MPI（消息传递接口）作业，使用RC服务类型。在节点规模从64扩展到256时，发现聚合带宽不升反降，且伴随大量重传。通过 ibstat 检查发现各端口 RcvErrors 均为0，但 LinkDownedCounter 正常。进一步使用 ibdiagnet 检查发现，部分QP的接收队列深度（RQ Size）设置过小（仅设置为16个报文），而发送端在突发模式下一次性注入了大量报文，导致端到端信用耗尽，发送端被迫频繁暂停。
误区与复盘：
- 误区1：认为只要链路层流控正常，网络就不会丢包。实际上，链路层流控只能防止物理端口缓冲区溢出，无法防止目的端HCA的接收队列溢出。当多个QP同时向同一个HCA发送时，即使每个QP的信用都未耗尽，总和也可能超过HCA的总接收能力。
- 误区2：盲目增大QP接收队列深度。虽然增大RQ Size可以缓解端到端信用不足，但会占用HCA宝贵的内存资源（尤其是使用DC（Dynamic Connected）传输时，共享接收缓冲区更需谨慎配置）。合理的做法是根据应用的最大未完成报文数（Outstanding Requests）来设置RQ Size，通常建议设置为发送队列深度的1.5~2倍。
- 误区3：忽略交换机内部的共享缓冲区管理。即使每条链路都有信用控制，交换机内部多个端口之间仍可能因共享缓冲区分配不均而出现局部拥塞。此时应启用交换机的 加权公平排队（WFQ） 或 优先级流控（PFC） 功能，确保关键流量（如存储流量）不被普通计算流量阻塞。
RcvErrors。该计数器为0只能说明物理层没有丢包，并不代表端到端流控工作正常。正确的排查顺序是：① 检查 ibdiagnet 报告中的QP信用超时计数；② 使用 perftest 的 ib_write_bw 测试不同消息大小下的实际带宽，观察是否存在“信用停顿”导致的带宽平台期；③ 检查交换机端口的 CongestionDiscards 计数，该值若持续增长，说明交换机内部缓冲区已出现拥塞，需要调整流控参数或路由策略。
3.7 小结：流控是IB网络稳定性的基石
IB的流控机制并非单一技术，而是一套分层的防御体系。链路层流控通过逐跳信用机制，以纳秒级速度消除了物理链路丢包的可能性；端到端流控则通过QP级信用管理，确保目的端HCA的处理能力不会被突发流量击穿。理解这两级流控的区别与联系，是进行IB网络性能调优、故障排查和容量规划的基础。在实际运维中，应同时关注物理端口计数器和传输层QP状态，才能准确判断流控是否真正发挥了作用。