rdma-core 与厂商 OFED 怎么选：从内核、功能和维护责任判断 NEWS DETAIL

优先使用发行版内核与 rdma-core 可满足目标功能的组合，通常能获得更清晰的系统维护边界；只有在确有功能、硬件或支持矩阵缺口时，才评估厂商 OFED。选择不能只比较包数量，而要确认内核耦合、升级窗口、容器依赖和运维责任。

适用条件与判断边界

适用于 InfiniBand 或 RoCE 主机驱动栈选型。需要列出 HCA、操作系统、内核、文件系统、MPI/NCCL、存储客户端和虚拟化依赖。某些平台或功能可能要求特定驱动栈，某些云环境则限制自行替换内核模块，必须以目标版本公开支持为准。

实施与选型方法

先在发行版默认栈上验证链路、RDMA、性能、监控和业务，形成缺口清单。若候选 OFED 用于补足功能，在同一内核和硬件上对比安装、模块、用户态库、升级与卸载过程。检查 DKMS、initramfs、内核更新和容器镜像是否依赖主机库，确保不同节点不会混用未记录的栈。

主要风险与控制方式

厂商 OFED 可能与发行版内核更新节奏耦合，卸载或切换后残留库会产生难以定位的问题；inbox 栈也可能缺少目标功能或较新硬件支持。将主机库挂入容器会扩大耦合。任何“性能更高”的判断都必须限定版本、硬件和工作负载。

如何核验结果

1. 记录内核模块、固件、用户态库和工具来源，确认节点间不存在未知混装。
2. 验证 RDMA 连接、代表性 NCCL 或存储负载、监控计数、重启与内核升级。
3. 实际演练从候选栈回退到原栈，检查残留包、initramfs、设备识别和业务恢复。

下一步行动

形成按操作系统与硬件分组的驱动栈标准，明确采用理由和升级责任。没有可复现功能缺口时保持发行版默认路径；需要厂商栈时单独维护节点池并冻结内核窗口。

核对具体版本与功能边界时，可查看NVIDIA rdma-core 文档、NVIDIA Networking 文档中心，并以目标版本页面为准。