3. RDMA网卡硬件架构：从PCIe接口到队列对的核心组件
3.1 网卡内部结构总览
RDMA网卡（通常称为HCA，Host Channel Adapter）在硬件设计上与普通以太网卡有本质区别。普通网卡的核心任务是“收包-中断-驱动处理”，而RDMA网卡的核心任务是“绕过CPU，直接在内存与网络之间搬运数据”。为了实现这一目标，HCA内部必须包含以下关键模块：
- PCIe物理接口与DMA引擎：负责与主机内存进行高速数据交换。
- 队列对（QP，Queue Pair）：承载上层应用提交的发送/接收请求，是RDMA通信的“工作单元”。
- 完成队列（CQ，Completion Queue）：用于异步通知应用“某个请求已经处理完毕”。
- 拥塞控制与流控引擎：管理RoCEv2等协议在物理网络中的传输质量。
- 固件与寄存器管理单元：负责配置、错误上报和状态查询。
理解这些模块的物理位置和逻辑关系，是后续分析硬件兼容问题（如PCIe链路不稳定、QP创建失败、CQ溢出）的基础。
3.2 PCIe接口与DMA引擎：数据进出的咽喉
RDMA网卡通过PCIe接口与CPU和内存相连。PCIe链路的速率（Gen3/Gen4/Gen5）和通道数（x8/x16）直接决定了DMA引擎能够使用的最大带宽。例如，一张支持200Gbps的HCA，如果被插在PCIe Gen3 x8的插槽上，实际吞吐量将严重受限。
DMA引擎是HCA内部最繁忙的模块。当应用调用ibv_post_send()提交一个发送请求时，驱动会将该请求翻译为DMA描述符，写入HCA的发送队列。HCA的DMA引擎随后直接从主机内存中读取数据（无需CPU参与），将其封装为网络报文发送出去。接收方向同理，DMA引擎将收到的数据直接写入应用预先注册好的内存缓冲区。
关键参数max_dma_size和max_sge（Scatter/Gather Element数量）决定了单次DMA操作能处理的数据块大小和内存段数量。如果驱动或固件对这两个参数的配置不一致，会导致EINVAL错误。
# 查看当前HCA的PCIe链路状态（以Mellanox/ConnectX系列为例）
lspci -vvv -s 03:00.0 | grep -E "LnkSta|LnkCap"
# 期望输出示例（Gen4 x16）：
# LnkCap: Port #0, Speed 16GT/s, Width x16
# LnkSta: Speed 16GT/s, Width x163.3 队列对（QP）：RDMA通信的核心抽象
QP是RDMA通信的“端点”。一个QP由发送队列（SQ）和接收队列（RQ）组成。应用通过QP提交工作请求（WR，Work Request），HCA硬件负责执行这些请求。QP的状态机包括RESET → INIT → RTR（Ready to Receive）→ RTS（Ready to Send），任何状态转换失败都会导致QP进入ERROR状态。
在硬件内部，QP并不是一个简单的内存队列，而是一组复杂的硬件描述符环形缓冲区。每个QP占用一定的内存映射I/O（MMIO）空间和门铃（Doorbell）寄存器。驱动通过写门铃寄存器通知HCA“有新请求入队”。
硬件兼容问题常出现在以下场景：
- QP数量超限：固件支持的QP总数（如
HCA_MAX_QP）被耗尽，创建新QP返回ENOMEM。 - QP上下文损坏：因PCIe传输错误导致QP上下文（QPC）在内存中被篡改，HCA检测到校验错误后自动将QP置为ERROR。
- 门铃丢失：在极端负载下，MMIO写操作可能被CPU重排序，导致HCA未感知到新请求，表现为“请求卡住”。
3.4 完成队列（CQ）与事件通知机制
CQ用于异步通知应用“WR已完成”。当SQ中的发送请求完成，或RQ中收到新数据时，HCA会向CQ中写入一条完成队列元素（CQE）。应用通过ibv_poll_cq()轮询CQ获取完成信息。
CQ的深度（cqe数量）是硬件资源的一部分。如果CQ被填满而应用未及时轮询，HCA会触发CQ溢出（Overrun），此时新的完成事件将被丢弃，严重时会导致连接断开。硬件设计上，CQ通常与事件队列（EQ）配合使用：当CQ从空变为非空时，HCA通过EQ向驱动发送中断或事件通知。
在硬件兼容性排查中，CQ相关的典型问题包括：
- CQ深度不足：应用设置的
cqe数小于QP的并发WR数，导致溢出。 - EQ中断丢失：在MSI-X中断配置错误时，HCA无法向CPU发送完成事件，应用轮询CQ永远为空。
3.5 关键硬件组件与故障映射表
| 硬件组件 | 功能 | 常见故障现象 | 驱动/固件相关日志 |
|---|---|---|---|
| PCIe接口 | 主机与HCA的物理链路 | 链路降速、CRC错误 | PCIe Link Down, Correctable Error |
| DMA引擎 | 内存与网卡间的数据搬运 | 数据校验错误、超时 | DMA error, Local Protection Error |
| QP上下文 | 存储QP状态与内存地址 | QP跳转ERROR、创建失败 | QP Catastrophic Error |
| CQ/EQ | 完成通知与中断聚合 | 轮询超时、中断风暴 | CQ Overrun, EQ Error |
3.6 硬件架构视角的故障排查流程
当遇到RDMA性能下降或连接异常时，建议按照以下顺序从硬件架构角度进行排查：
- 检查PCIe物理层：使用
lspci或mlxlink确认链路速率和宽度是否达标，查看是否有大量可纠正错误。 - 检查DMA路径：查看驱动统计中的
tx_errors和rx_errors，以及dma_mapping_error计数。 - 检查QP状态：使用
ibv_devinfo或rdma link查看QP状态，确认是否有QP处于ERROR状态。 - 检查CQ/EQ健康度：通过
perftest工具进行环回测试，观察是否出现CQ溢出或中断丢失。
ibv_poll_cq()返回0（无完成事件）但QP仍在发送的情况。排查过程：首先确认PCIe链路正常（Gen4 x16无CRC错误），其次检查DMA引擎无错误计数。最终通过rdma resource show cq发现CQ深度仅为128，而应用并发WR数为256，导致CQ溢出后新完成事件被丢弃。将CQ深度调整为512后问题消失。此案例说明，硬件架构中的资源容量（CQ深度）与应用行为不匹配是隐蔽的兼容性问题。
3.7 硬件与驱动的协作边界
理解硬件架构的最终目的是明确驱动层能做什么、不能做什么。驱动无法修复PCIe信号完整性，也无法扩大固件中QP表的容量。但驱动可以：
- 检测到PCIe错误后触发链路重置或热复位。
- 在QP进入ERROR状态后，自动重新初始化QP并恢复连接。
- 通过调整
max_cqe和max_qp_wr参数，适配不同应用的并发需求。
在后续章节中，我们将深入驱动源码，分析这些修复逻辑的具体实现位置和触发条件。