mctp over smbus创建endpoint机制的修改方案讨论

交流互助区
,
1

// 此模板仅供参考，如果不适用可以修改

问题描述

mctp over smbus创建endpoint机制的修改。【hardware-sig例会评审讨论需要】

有伙伴厂商适配网迅网卡时发现，走mctp over smbus创建endpoint有概率在60s之后才创建成功，但是代码机制只等待了60s（60内没有创建成功就认为链路无效，不执行相关任务），导致ncsi task没有执行。

77FDCA20-FE6A-46d8-978C-32783A6793CB
77FDCA20-FE6A-46d8-978C-32783A6793CB1011×637 32.5 KB

BF80802A-3EF5-423c-B19B-AC37EFF61C5A
BF80802A-3EF5-423c-B19B-AC37EFF61C5A995×529 27.9 KB

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：[如 OpenUBMC2509]

  • 硬件配置：[如 CPU、内存等]

重现步骤

  1. [第一步]

  2. [第二步]

  3. [第三步]

期望结果

[您希望实现什么]

实际结果

[实际发生了什么，包含错误信息]

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

[详细总结您对此问题的分析结论]

2

答案内容由AI生成，仅供参考：

5. 初步结论

该问题涉及 MCTP over SMBus Endpoint 创建、MCTPD 注册、资源树可见性、SMBus 绑定配置以及 NCSI 任务触发条件。从现有信息看，建议评审重点放在：

  1. 60s 固定等待与 Endpoint 创建完成之间的边界判定；
  2. 是否改为周期性检查或事件驱动的 Endpoint 就绪等待；
  3. discovery 重试机制中返回值类型异常的处理；
  4. Endpoint 配置与 MctpBinding_1、Chip_SmbusChip 的一致性；
  5. Endpoint 未就绪时 NCSI task 的触发与失败处理策略。

由于上下文未给出具体等待逻辑实现，最终修改方案仍需结合代码和日志在 hardware-sig 例会中进一步确认。

点击此处查看详细分析解答

MCTP over SMBus 创建 Endpoint 机制修改讨论分析

1. 问题理解

根据描述，伙伴厂商在适配网迅网卡时发现：走 MCTP over SMBus 创建 Endpoint，有概率在 60s 左右创建成功；但当前代码机制只等待 60s，若 60s 内未创建成功就认为链路无效，并不执行相关 NCSI 任务，最终导致 NCSI task 没有执行。

从问题现象看，核心矛盾在于：Endpoint 创建完成的时序与代码固定等待/判定阈值之间存在边界竞争。如果 Endpoint 在接近 60s 时完成创建，而代码在 60s 到达时已经判定链路无效，就可能出现“实际创建成功但任务未执行”的情况。

2. 上下文中可确认的相关机制

  • create_mctp_endpoint_for_smbus：用于为不支持原生 MCTP 的设备建立 MCTP over SMBus Endpoint。
  • GetSmbusEndpoint：用于获取 SMBus Endpoint 对象；如果 Endpoint 尚未进入资源树，该接口会失败。
  • Endpoint 状态与资源树可见性：Endpoint 需要正确配置 MessageType、物理地址、绑定 Chip 等；上下文中也提到 Endpoint 可能初始化失败、未出现在系统树或资源树中。
  • MCTPD：负责管理 MCTP Endpoint、路由、设备发现和协议消息处理，并通过 SMBus 与 Chip_SmbusChip_0103_dev 等设备通信。
  • MctpBinding_1：定义 BMC 的 SMBus EID 为 8、物理地址为 16；Chip_SmbusChip 也绑定 SMBus 物理地址 16。
  • Endpoint_1 配置：上下文中存在多种配置描述，例如 TargetEid、TargetPhyAddr、MessageType、MediumType 和关联 Chip 等，评审时需要确认实际生效配置是否一致。
  • 已有相关优化条目：包括“优化 mctp over smbus oem 协议 discovery 重试机制，避免返回非 string 类型导致 string_byte 调用失败”，以及“修改 mctp 对象创建”。这些可作为本次修改的关联参考。

3. 建议在 hardware-sig 例会评审中讨论的修改方向

3.1 明确 60s 等待与超时判定逻辑

需要确认当前代码中 60s 的具体含义：

  • 是固定 sleep 60s 后检查一次？
  • 还是 60s 内周期检查 Endpoint 是否创建成功？
  • 创建成功的判定标准是 create_mctp_endpoint_for_smbus 返回、MCTPD 注册完成，还是 GetSmbusEndpoint 能取到对象？

如果 Endpoint 有概率在 60s 边界附近创建成功，建议评审是否调整判定方式，避免“刚创建成功但已被判定链路无效”的边界问题。

3.2 将一次性等待改为可观测的重试/状态等待

建议讨论是否把当前固定等待机制改为：

  • 在等待窗口内周期性检查 Endpoint 是否进入资源树；
  • 或等待 MCTPD 的 Endpoint 注册/创建完成状态；
  • 只有达到明确超时条件后，才将链路置为无效并跳过 NCSI 任务。

具体等待间隔、重试次数和总超时时间需要结合网迅网卡实际创建耗时评审确定，不能仅依赖固定 60s 单点判定。

3.3 保留并检查 discovery 重试机制的健壮性

已有优化条目提到：调用 string_byte 前检查返回值是否为 string 类型，避免返回非 string 时调用失败。该优化与 MCTP over SMBus discovery 重试机制相关，建议在本次修改中确认：

  • Endpoint discovery 重试返回异常类型时是否会中断创建流程；
  • 重试失败是否会被误判为链路无效；
  • 是否需要补充重试日志和失败原因。

3.4 检查 Endpoint 配置一致性

评审时需要核对实际生效的 Endpoint 配置，包括：

  • TargetEid / TargetPhyAddr；
  • MessageType；
  • MediumType；
  • 绑定的 Chip；
  • BMC SMBus EID 与物理地址，例如 MctpBinding_1 中 EID=8、物理地址=16。

上下文中 Endpoint_1 存在多种配置描述，因此需要确认网迅网卡场景下实际使用的配置是否与创建机制匹配。

3.5 NCSI 任务触发条件需要解耦或延迟处理

当前问题是 Endpoint 未在 60s 内创建成功时，NCSI task 不执行。建议讨论：

  • Endpoint 未就绪时，是否应直接判定链路无效；
  • 是否可以将 NCSI task 延迟到 Endpoint 就绪后再触发；
  • 或至少记录明确的“Endpoint 未就绪”状态，而不是仅表现为 NCSI task 未执行。

3.6 增强日志与可观测性

建议补充或检查以下日志点：

  • create_mctp_endpoint_for_smbus 开始、返回和耗时；
  • GetSmbusEndpoint 失败原因；
  • MCTPD Endpoint 注册/创建状态；
  • Endpoint 是否进入资源树；
  • 60s 超时判定时刻与实际创建成功时刻；
  • NCSI task 未执行的具体原因。

4. 需要补充的信息

现有上下文未提供 60s 等待逻辑的具体代码和网迅网卡日志，因此无法直接给出最终修改代码。建议补充：

  • 网迅网卡型号及实际使用的 MediumType、MessageType；
  • Endpoint 创建成功的时间戳与 60s 超时时间戳；
  • create_mctp_endpoint_for_smbus、GetSmbusEndpoint、MCTPD 相关日志；
  • Endpoint 是否在超时后才出现在资源树；
  • NCSI task 的触发条件与失败路径；
  • 当前修改方案涉及的代码位置。

5. 初步结论

该问题涉及 MCTP over SMBus Endpoint 创建、MCTPD 注册、资源树可见性、SMBus 绑定配置以及 NCSI 任务触发条件。从现有信息看，建议评审重点放在：

  1. 60s 固定等待与 Endpoint 创建完成之间的边界判定；
  2. 是否改为周期性检查或事件驱动的 Endpoint 就绪等待；
  3. discovery 重试机制中返回值类型异常的处理；
  4. Endpoint 配置与 MctpBinding_1、Chip_SmbusChip 的一致性；
  5. Endpoint 未就绪时 NCSI task 的触发与失败处理策略。

由于上下文未给出具体等待逻辑实现，最终修改方案仍需结合代码和日志在 hardware-sig 例会中进一步确认。

3

建议报名hardware sig讨论，有结论同步在帖子上

4

评审讨论结论：暂时先加长延时时间。

5

ok