在 BlueField DPU 环境中，运维人员会看到物理端口、主机侧 PF/VF、嵌入式系统接口和 representor 等多类网络对象。它们的名称可能只差几个字符，却承担不同职责。Representor 常用于在交换控制面观察或施加与某个主机功能相关的策略，但它不是“另一张普通网卡”。如果资产系统只按接口名抓取，重装、模式切换或版本变化后很容易把策略绑定到错误对象，表现为部分流量绕过、统计归属错误或虚拟机失联。
先画出对象关系而不是背接口名
每台 DPU 应建立一张身份表，至少包含物理端口、主机 PF、VF、嵌入式侧功能、representor、PCI 地址、设备序列身份和当前网络命名空间。接口名只是当前系统生成的标签，稳定关系应由 PCI 功能、端口索引和平台查询结果共同确认。若采用 SR-IOV，VF 创建、销毁和重新编号都会改变对象集合；若采用不同工作模式，数据路径位置也可能变化。变更方案必须明确“流量从哪里进入、在哪个交换域处理、从哪里离开”。
控制面可见不代表业务已经经过
在 representor 上看到链路或计数器，不足以证明目标工作负载流量经过预期路径。验证需要发送带有明确源、目的和时间窗口的受控流量，同时观察主机、嵌入式系统、交换控制面和外部网络的计数变化。若使用 OVS 或硬件卸载，还要确认规则是否下发、是否命中硬件、异常流量走什么慢路径。只检查配置数据库中的规则存在，可能漏掉下发失败、能力不支持或优先级冲突。
命名空间与管理权限要划清
某些接口存在于 DPU 的嵌入式操作系统，主机管理员未必直接可见；反之，主机内部的 VF 和业务命名空间也不是 DPU 管理员看到的同一视图。排障流程应写明每条命令在哪一侧执行、需要什么权限、输出如何关联。生产平台不应为方便排障长期开放全局管理权限。策略自动化、监控采集与人工登录要使用不同身份，并把高风险操作和配置导出纳入审计。
生命周期事件最容易破坏映射
固件或软件升级、DPU 重启、主机重启、VF 数量变化、驱动重新加载和模式切换，都可能影响接口出现顺序或名称。上线前应逐项演练，并让自动化在对象缺失或关系不一致时停止配置，而不是按旧名字继续执行。资产系统应保存变更前后映射与规则摘要，监控平台则要避免把新接口时间序列接到旧对象上。若必须回退，应同时恢复 DPU 侧与主机侧配置，单边回退可能造成路径语义不一致。
验收应回答五个问题
- 每个 representor 对应哪个主机功能、物理端口和租户，证据来自哪里。
- 正常流量、异常流量和未命中规则的流量分别走哪条路径。
- 策略是否实际下发并命中预期执行位置，慢路径是否在容量范围内。
- 主机或 DPU 任一侧重启后，映射与策略是否能够自动重建。
- 管理员、采集器和编排系统分别拥有何种权限，操作是否可审计。
BlueField 的模式、接口模型和 DOCA 组件会随版本演进，部署时应从 NVIDIA DOCA Documentation选择与实际软件版本对应的 BlueField 平台、网络与虚拟化章节。本文描述的是识别与验证方法，不代表任何具体型号默认支持某种卸载或模式；采购和实施仍需核对完整硬件、固件、操作系统和软件组合。
WeChat
Profile