model为Hi1822-FC的FC卡，SpeedMbps为什么取不到值要特意设置个0

交流互助区
1

问题描述

image
image1076×604 28.5 KB

如题，Hi1822-FC为model的FC卡，network_adapter仓库里配置为

    SpeedMbps = speed_mbps or 0,

    SpeedGbps = speed_gbps or 0

这两个字段中SpeedGbps为FC卡特有的接口下属性，SpeedMbps为网口公共属性

实测Hi1822-FC为model的FC卡在安装ibma以后，web上会有两个速率字段：

企业微信截图_17927355386766
企业微信截图_179273553867661920×919 50.9 KB

0和32G对应上面说的公共属性和FC卡独有属性

查看webui代码发现，如果公共属性为null，webui会处理为不显示该属性，但是由于network_adapter中特意处理为拿不到该值时取0：

image
image963×819 31.7 KB

会导致前端渲染了两个速率

我能想到的两个修改方案是：1.network_adapter中这处代码的or 0删除；2.webui对FC卡做渲染过滤

对于方案1，想知道这里有什么特殊背景么，什么场景会要求这个值为0，而不为null呢

2

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

结论

在给定的知识库与文档上下文中，没有找到“SpeedMbps 必须回退为 0”的特殊背景或业务场景说明。从现有资料能确认的是：这个 or 0 更像是代码中的通用缺省兜底，而不是 FC 卡场景下明确要求的行为。上下文反而多处指向：FC 卡的速率应通过 bmc.dev.NetworkPort.FibreChannel 接口下的 SpeedGbps 表示。

总结

  • SpeedMbps 取到 0 的直接原因：FC 卡的 link_speed 编码落在 Gbps 映射表中，而 Mbps 映射表未覆盖该编码，导致 speed_mbps = nil，再被 or 0 兜底为 0。
  • 是否存在“必须为 0”的特殊背景：给定上下文中没有记载，无法确认存在这样的场景。
  • 上下文支持的方向：FC 卡速率应以 bmc.dev.NetworkPort.FibreChannel.SpeedGbps 表达；未获取到的属性更适合保持为空，而不是强行置 0。
  • 删除 or 0 的影响：可避免 FC 卡出现多余的 0Mbps 显示，但需额外确认 Redfish 及其他消费方对空值的处理逻辑，这一点上下文未提供。
点击此处查看详细分析解答

结论

在给定的知识库与文档上下文中，没有找到“SpeedMbps 必须回退为 0”的特殊背景或业务场景说明。从现有资料能确认的是：这个 or 0 更像是代码中的通用缺省兜底，而不是 FC 卡场景下明确要求的行为。上下文反而多处指向：FC 卡的速率应通过 bmc.dev.NetworkPort.FibreChannel 接口下的 SpeedGbps 表示。

上下文中可确认的速率字段机制

1. NicPort 中存在两个速率字段

文档上下文明确提到：

  • NicPort 对象中有两个字段用于表示速率：SpeedGbps、SpeedMbps。
  • Web 端使用 SpeedGbps 字段显示速率。
  • Redfish 接口中使用 SpeedMbps / 1000 来显示速率。

这与您描述的“公共属性”和“FC 卡独有属性”对应关系一致。

2. FC 卡速率应使用 SpeedGbps

知识图谱与文档上下文均指出：

  • bmc.dev.NetworkPort.FibreChannel 是用于描述网络端口 Fibre Channel 属性的接口，其中包含 SpeedGbps。
  • 社区回答中明确建议：“FC 卡应该用 bmc.dev.NetworkPort.FibreChannel 接口下的 SpeedGbps 表示速率。”
  • LPe32002 FC卡 的速率应通过 bmc.dev.NetworkPort.FibreChannel 接口的 SpeedGbps 字段上报。

因此，从接口语义上看，FC 卡的主速率表达应是 SpeedGbps，而不是 SpeedMbps。

3. SpeedMbps = 0 的来源是“映射不到 → 兜底为 0”

结合您贴出的代码可以分析：

  • pldm_link_speed_mbps_switch 只覆盖了 0x00 ~ 0x06 等速率编码；
  • pldm_link_speed_gbps_switch 覆盖了 0x10 ~ 0x13，分别对应 8 / 16 / 32 / 64 Gbps；
  • Hi1822-FC 返回的 link_speed 若落在 0x10 ~ 0x13（例如 0x12 对应 32Gbps），则：
    • speed_gbps = 32
    • speed_mbps = nil（因为 Mbps 映射表中没有该编码）
  • 随后执行：
    SpeedMbps = speed_mbps or 0
    于是 SpeedMbps 被写成 0，前端就多渲染出一个 0Mbps。

所以，这个 0 并不是实际测到的速率，而是“Mbps 映射表未覆盖 FC 速率编码”后触发的缺省值。这也解释了为什么会出现“0Mbps + 32Gbps”两个速率字段。

是否存在“必须为 0 而不是 null”的场景？

上下文中没有明确记载

提供的知识图谱和文档片段中，没有说明某种业务场景要求 SpeedMbps 必须为 0 而不能为 null。也没有资料表明 FC 卡的公共网口属性需要以 0 作为有效值参与显示或判断。

上下文中的相关线索反而偏向“未获取时应为 null”

检索结果中出现过类似议题：

  • “优化网卡部分属性未获取到值时显示为null”

这说明项目方向中存在“属性未获取到值时显示为 null”的优化诉求。虽然该检索结果只是议题标题，未展开具体实现背景，但它与“删除 or 0、让未获取值保持为空”的方向是一致的。

类似问题的历史案例也表明“直接赋值/单位未转换”是缺陷

文档中 LPe32002 FC卡 的案例显示：

  • 博通网卡通过标准 PLDM 命令获取链路速率后，直接把返回值 32 赋给 SpeedMbps；
  • SpeedGbps 没有任何赋值；
  • 结果 Web 端显示 0Gbps，Redfish 显示 0.032；
  • 问题分析认为：应先确认返回值单位，再按单位转换后给 SpeedGbps 和 SpeedMbps 都赋值。

该案例说明：上下文中对这类现象的判断是“赋值逻辑/单位处理有问题”，而不是“必须保留 0 作为默认值”。

对修改方案的上下文评估

方案 1：删除 or 0

从上下文看，这一方案与以下事实一致：

  • FC 卡速率应主要通过 SpeedGbps 表示；
  • SpeedMbps 为网口公共属性，FC 卡场景下不一定有对应的 Mbps 映射；
  • 当前 0 是映射缺失后的兜底值，并非真实速率；
  • 删除 or 0 后，未映射时 SpeedMbps 保持为空，可避免前端把 0Mbps 当作有效速率渲染。

但需要注意，上下文没有说明：

  • 是否有其他消费方依赖 SpeedMbps 为数值类型；
  • Redfish 侧使用 SpeedMbps / 1000 时，对空值的处理逻辑是什么；
  • 是否存在历史兼容场景要求该字段必须为 0。

这些点在给定资料中均无法确认。

方案 2：WebUI 对 FC 卡做渲染过滤

上下文中没有关于 WebUI 针对 FC 卡做字段过滤的说明，因此无法从现有资料判断该方案是否已被采用或是否合适。上下文只说明 Web 端使用 SpeedGbps 显示速率、Redfish 使用 SpeedMbps / 1000 显示速率，未涉及前端按卡类型过滤字段的逻辑。

总结

  • SpeedMbps 取到 0 的直接原因：FC 卡的 link_speed 编码落在 Gbps 映射表中，而 Mbps 映射表未覆盖该编码，导致 speed_mbps = nil，再被 or 0 兜底为 0。
  • 是否存在“必须为 0”的特殊背景：给定上下文中没有记载，无法确认存在这样的场景。
  • 上下文支持的方向：FC 卡速率应以 bmc.dev.NetworkPort.FibreChannel.SpeedGbps 表达；未获取到的属性更适合保持为空，而不是强行置 0。
  • 删除 or 0 的影响：可避免 FC 卡出现多余的 0Mbps 显示，但需额外确认 Redfish 及其他消费方对空值的处理逻辑，这一点上下文未提供。