3. 链路层帧结构：LRH、BTH、GRH等关键头部字段解析
各位同学，咱们今天聊聊InfiniBand的帧结构。说实话，我刚入行那会儿，看着这些头部字段也是一头雾水。但后来在调一个高性能计算集群时，发现很多莫名其妙的丢包和延迟问题，追根溯源都跟这些头部字段配置不当有关。所以，这块内容虽然看起来枯燥，但绝对是实战中的硬通货。
3.1 整体帧结构概览
InfiniBand的报文，说白了就是一层套一层的结构。你想想看，数据要从一个节点跑到另一个节点，中间要经过交换机、链路，每一层都需要自己的“导航信息”。
一个完整的InfiniBand报文，从外到内依次是：
- LRH（Local Routing Header）：本地路由头，负责在子网内跳来跳去
- GRH（Global Routing Header）：全局路由头，跨子网时才需要
- BTH（Base Transport Header）：基础传输头，负责端到端的传输控制
- 数据载荷：真正的业务数据
- ICRC（Invariant CRC）：不变CRC，校验不变字段
- VCRC（Variant CRC）：可变CRC，校验可变字段
关键点：LRH和VCRC是每跳都会变化的，而GRH、BTH、ICRC在整个传输过程中保持不变。这个设计很巧妙——每跳交换机只需要解析LRH就能做转发，效率极高。
3.2 LRH（本地路由头）深度解析
LRH是每个InfiniBand报文都必须有的头部，共8字节。我在项目中遇到过好几次，因为LRH中的SL（服务等级）配错了，导致高优先级流量和普通流量混在一起，延迟直接飙升。
LRH的主要字段如下：
| 字段 | 位数 | 说明 |
|---|---|---|
| VL（Virtual Lane） | 4 | 虚拟通道号，0-14可用，15保留 |
| LVer（Link Version） | 4 | 链路版本，目前固定为0 |
| SL（Service Level） | 4 | 服务等级，用于QoS |
| LNH（LNH） | 2 | 下一头部类型：00=无，01=GRH，10=BTH，11=保留 |
| DLID（Destination LID） | 16 | 目标本地标识符 |
| SLID（Source LID） | 16 | 源本地标识符 |
实战技巧：我个人习惯在配置LID时，把管理节点放在低地址段（如0x0001-0x0010），计算节点放在高地址段。这样在排查问题时，看一眼DLID就能大概知道流量方向。
3.3 BTH（基础传输头）深度解析
BTH是传输层的核心，共12字节。它负责的事情可多了：操作码、目的QP、分组序列号、分片信息等等。我记得有一次调试RDMA写操作，发现对端一直收不到数据，最后查出来是BTH中的目的QP写错了。
BTH的关键字段：
| 字段 | 位数 | 说明 |
|---|---|---|
| OpCode（操作码） | 8 | 定义操作类型：RDMA写、RDMA读、Send等 |
| SE（Solicited Event） | 1 | 请求事件标志 |
| M（MigReq） | 1 | 迁移请求标志 |
| Pad（填充计数） | 2 | 数据载荷末尾的填充字节数 |
| TVer（Transport Version） | 4 | 传输版本，目前为0 |
| PKey（分区键） | 16 | 用于隔离不同租户或应用 |
| F（FECN） | 1 | 前向显式拥塞通知 |
| B（BECN） | 1 | 后向显式拥塞通知 |
| Resv（保留位） | 6 | 保留，必须为0 |
| DestQP（目的队列对） | 24 | 目标端的QP编号 |
| PSN（分组序列号） | 24 | 用于排序和丢包检测 |
避坑指南：我曾经在配置PKey时，把两个不同分区的节点配成了同一个PKey，结果数据串了，调试了整整两天。记住：PKey是隔离的第一道防线，一定要规划好。
3.4 GRH（全局路由头）深度解析
GRH不是必须的，只有跨子网通信时才需要。它基于IPv6的格式，共40字节。说白了，LRH负责在子网内部找路，GRH负责在子网之间找路。
GRH的主要字段：
| 字段 | 位数 | 说明 |
|---|---|---|
| IPVer（IP版本） | 4 | 固定为6，表示IPv6格式 |
| TrafficClass（流量类别） | 8 | 用于QoS和拥塞控制 |
| FlowLabel（流标签） | 20 | 标识同一流的分组 |
| PayloadLen（载荷长度） | 16 | GRH之后的数据长度 |
| NextHdr（下一头部） | 8 | 固定为0x1B，表示BTH |
| HopLimit（跳数限制） | 8 | 每经过一跳减1，到0丢弃 |
| SGID（源GID） | 128 | 源全局标识符 |
| DGID（目的GID） | 128 | 目的全局标识符 |
核心要点：GRH中的FlowLabel字段很有意思。你想想看，如果两个QP之间的所有报文都用同一个FlowLabel，交换机就可以做流级别的负载均衡，而不是逐包负载均衡。这在避免乱序方面特别有用。
3.5 头部处理流程实战
咱们来看一个实际的处理流程。假设一个报文从节点A发往节点B，中间经过一台交换机：
- 发送端：构造LRH（填上源LID和目标LID）、BTH（填上操作码和QP信息），如果需要跨子网再加GRH
- 交换机入口：解析LRH，根据DLID查转发表，决定从哪个端口转发
- 交换机出口：更新LRH中的DLID（如果是多跳），重新计算VCRC
- 接收端：解析BTH，检查PSN是否连续，根据OpCode做相应处理
个人经验：我建议大家在调试时，用抓包工具把报文完整抓下来，然后逐字段比对。特别是PSN，如果发现跳变，基本可以断定是丢包了。嗯，这个方法帮我解决过不少疑难杂症。
3.6 常见问题与排查思路
最后，我总结几个实战中容易踩的坑：
- LID冲突：两个节点配了相同的LID，交换机直接懵圈。解决办法是用子网管理器统一分配。
- PKey不匹配：发送端和接收端的PKey对不上，报文会被静默丢弃。检查两边配置是否一致。
- PSN回绕：PSN是24位的，超过16777215后会回绕到0。如果接收端窗口设置不合理，可能误判为丢包。
- GRH滥用：同一子网内没必要用GRH，白白浪费40字节带宽。我见过有人图省事全局都用GRH，结果性能掉了10%。
好了，关于LRH、BTH、GRH的解析就到这里。下一节咱们聊聊拥塞控制，那可是个更有意思的话题。