4. BlueField 网络数据面基础

BlueField DPU 之所以能同时承担“主机网卡”和“独立服务器”两种角色，关键不在于它有一颗 Arm 处理器，而在于它内部把网络数据面拆成了几个可组合的层次：嵌入式交换机（eSwitch）、SR-IOV 的 PF/VF 表示、virtio 加速通道，以及可编程的流量卸载路径。理解这些层次之间的连接关系，是后续配置 OVS 卸载、vDPA、DOCA 服务的前提。本节先建立一张“数据面地图”，把主机侧、DPU 侧和外部网络之间的数据流走向讲清楚。

一、嵌入式交换机：DPU 内部的数据面枢纽

BlueField 内部集成了一个由硬件实现的嵌入式交换机，通常称为 eSwitch 或嵌入式交换机。它位于物理端口（uplink）与主机侧 PCIe 功能之间，是 DPU 数据面的核心枢纽。eSwitch 的端口可以粗略分为三类：连接外部网络的 uplink 端口、连接主机侧 PF/VF 的 host 端口、以及连接 DPU Arm 侧 PF/VF 的 representor 端口。任何从外部进入主机的流量、从主机发往外部的流量，以及主机与 DPU 上运行的虚拟化/容器网络之间的流量，都要经过 eSwitch 的转发决策。

eSwitch 的转发规则由 DPU 上的软件（如 OVS、DOCA Flow）下发，硬件按规则执行匹配与动作。这意味着：当我们在 DPU 上配置一条“把 VF0 的流量导向 uplink”的规则时，实际生效的是 eSwitch 硬件表项，而不是主机 CPU 上的软件转发。这正是 BlueField 能把网络数据面从主机卸载到 DPU 的物理基础。

二、PF/VF 表示：主机与 DPU 如何“看见”彼此

SR-IOV 把一个物理功能（PF）虚拟出多个虚拟功能（VF）。在 BlueField 场景中，主机侧看到的是 PF 和 VF，DPU 侧看到的则是这些 PF/VF 的 representor（表示端口）。Representor 是 eSwitch 上对应某个主机侧功能的“镜像端口”，DPU 上的控制面软件通过它来识别“这条流量来自主机哪个 VF”，并对其下发转发或卸载规则。

可以用一个简单对应关系来记忆：主机侧 enp3s0f0v0 这样的 VF 接口，在 DPU 侧对应一个 representor，例如 pf0vf0 或 en3f0pf0sf0 这类命名。主机侧 VF 负责收发，DPU 侧 representor 负责被控制面识别和编排。两者不是同一条链路的两端，而是同一 eSwitch 端口在不同操作系统视角下的两个名字。

三、SR-IOV 与 virtio 加速：两条不同的加速路线

SR-IOV 的加速思路是“绕过主机软件栈”：VF 直接映射到虚拟机或容器，数据从 eSwitch 直达 VF，主机内核不参与转发，延迟低、CPU 占用小。但它的代价是迁移性差、对 hypervisor 和网卡驱动有依赖，且主机侧看到的是真实硬件设备。

virtio 加速（如 vDPA、virtio-net 硬件实现）的思路不同：虚拟机仍然看到标准的 virtio 设备，保持可迁移性和兼容性，但 virtio 的数据面被下沉到 DPU 硬件执行。主机侧的 virtio 前端只负责描述符环，真正的报文搬运和转发由 DPU 完成。两条路线的选择取决于业务对性能、迁移性和兼容性的权衡。

四、流量卸载路径与主机—DPU 数据流走向

把上述组件串起来，一条典型的卸载路径是：外部报文到达 uplink → eSwitch 匹配硬件流表 → 若命中卸载规则，直接转发到目标 VF 或 representor → 主机侧 VF 收到报文，主机协议栈只处理“已属于本机”的流量。反向发送时，主机 VF 发出的报文进入 eSwitch，命中规则后直接上 uplink，不再经过 DPU Arm 的软件转发。

未命中硬件流表的报文则走“慢路径”：上送到 DPU Arm 上的 OVS 或 DOCA Flow 控制面，由软件决定如何处理，并把结果写成新的硬件流表项。这种“首包上送、后续卸载”的机制，是 BlueField 数据面既灵活又高性能的关键。

五、一个可观察的配置示例

下面以在 DPU 上查看 representor 与主机 VF 对应关系为例，说明如何验证数据面是否按预期建立。示例命令仅用于说明观察方法，具体接口名以实际环境为准。

# 在 DPU Arm 侧查看 representor 端口
ip link show | grep -E "pf0|representor"

# 在主机侧查看 VF
lspci | grep -i mellanox
ip link show | grep -E "enp|vf"

# 查看 eSwitch 上的端口与 representor 映射（示例）
devlink port show

观察要点：主机侧应能看到 PF 与若干 VF；DPU 侧应能看到与这些 VF 一一对应的 representor。若 representor 缺失，通常意味着 SR-IOV 未启用或 VF 未正确创建，此时 eSwitch 无法识别主机侧流量来源，卸载规则也就无法精确下发。

六、常见误区与排障方向

第一个误区是把 representor 当成“另一块网卡”。它本质上是 eSwitch 上的一个逻辑端口，用于控制面识别，不承担独立的外部连通性。第二个误区是认为 SR-IOV 和 virtio 加速可以随意混用；两者对主机侧设备模型的要求不同，混用时需要确认 hypervisor 与 DPU 固件版本是否支持。第三个误区是只配置主机侧 VF 而忽略 DPU 侧 representor，导致 eSwitch 无法把流量与具体 VF 关联，卸载规则只能退化为粗粒度转发。

排障时建议按“物理链路 → eSwitch 端口 → representor 映射 → 流表规则 → 主机 VF 状态”的顺序逐层检查。先确认 uplink 与主机 VF 均处于 UP，再确认 representor 存在且与 VF 对应，最后检查流表是否命中。这样可以把“网络不通”与“卸载未生效”两类问题区分开，避免在错误层次上反复调整。

掌握本节这张数据面地图后，后续配置 OVS 硬件卸载、vDPA、以及基于 DOCA Flow 的流量编排时，就能清楚每条规则最终作用在 eSwitch 的哪个端口、影响哪一段数据流，从而做到“改哪里、看什么、怎么判断”。