4. BlueField网络数据面基础
BlueField DPU 之所以能同时承担主机网络、存储卸载和多租户隔离，根本原因在于它把“网卡”拆成了可编程的多级数据面。理解这一层，需要先厘清几个容易混淆的概念：物理端口运行在什么链路模式、主机侧看到的是 PF 还是 VF、虚拟机内部用的是 VirtIO 还是直通 VF，以及 DPU 内部如何用 Representor 把“虚拟口”和“物理口”统一到同一个切换模型里。本节围绕这条主线展开。
一、以太网模式与 InfiniBand 模式
BlueField 的物理端口可以工作在两种链路层模式：Ethernet（以太网）和 InfiniBand（IB）。这不是简单的“插不同线”，而是固件/驱动层面的链路类型选择，决定了上层协议栈、寻址方式和卸载能力的差异。
以太网模式下，端口使用 MAC 寻址，承载标准 TCP/IP、RoCEv2、VXLAN 等协议，适合与通用交换机、云原生网络对接。InfiniBand 模式下，端口使用 LID/GID 寻址，走 IB 子网管理（SM）体系，提供原生 RDMA、更低的时延和更细的拥塞控制，常见于 HPC 和 AI 训练集群。两种模式对 BlueField 内部的数据面管线影响不同：IB 模式下 RDMA 是“原生”的，以太网模式下 RDMA 通常以 RoCEv2 形式承载在 UDP 之上。
需要强调的是，模式切换通常需要重载固件或重启端口，且同一物理端口在同一时刻只处于一种链路模式。工程上常见的做法是：管理面用一条以太网链路，数据面用 IB 链路，或者全部统一到以太网 + RoCEv2，以降低运维复杂度。
二、PF、VF 与 SR-IOV 的关系
在 PCIe 视角下，BlueField 暴露给主机的功能分为两类：PF（Physical Function）和 VF（Virtual Function）。PF 是物理功能的代表，拥有完整的配置空间和管理能力，通常由 DPU 的嵌入式 Arm 侧或主机上的特权驱动持有；VF 是 SR-IOV 扩展出来的轻量功能，只保留数据面所需的队列和中断资源，供虚拟机或容器直接使用。
SR-IOV 的价值在于：它让一个物理设备在 PCIe 层面“裂变”成多个独立功能，每个 VF 可以被独立分配给一个 VM，并且通过 IOMMU 做地址隔离。这样 VM 的收发包可以绕过 Hypervisor 的软件 vSwitch，直接落到 VF 的队列上，获得接近线速的吞吐和更低的 CPU 占用。
但 VF 直通也带来一个问题：VF 本身不具备完整的“网络端口”语义，Hypervisor 很难像操作一个 vNIC 那样对它做策略、镜像、ACL 和迁移。这正是 Representor 要解决的问题。
三、VirtIO 与 VF 直通的取舍
VirtIO 是半虚拟化方案：Guest 里是 virtio-net 驱动，Host 侧是 vhost/vhost-user 后端，数据包要经过 Guest 内核、virtqueue、Host 后端再到物理口。它的优点是兼容性好、可迁移、便于做策略；缺点是每次收发都要经过软件路径，CPU 开销大、时延高。
VF 直通则相反：Guest 直接驱动 VF，数据路径几乎全在硬件里完成，性能好，但牺牲了可迁移性和部分可视性。BlueField 的典型做法是“混合”：控制面走 VirtIO 或 PF 通道，数据面走 VF 直通，同时用 Representor 把 VF 的流量“映射”回 DPU 的切换域，从而既保留性能又保留策略能力。
四、Representor 与统一切换模型
Representor 可以理解为“某个虚拟口在 DPU 切换域中的代理端口”。每个 VF、每个 VirtIO 后端、甚至每个容器 veth，都可以在 DPU 的 eSwitch（嵌入式交换机）里对应一个 representor。这样，DPU 的转发逻辑只需要面对统一的“端口”抽象：物理口、PF、VF representor、VirtIO representor 都是端口，规则、ACL、镜像、计量都可以统一施加。
下图给出 BlueField 数据面的整体切换模型：主机侧有 PF 与若干 VF，VM 内可以是 VirtIO 或 VF 直通；DPU 内部通过 eSwitch 把物理口与各类 representor 连接起来，形成“物理口 ↔ representor ↔ 虚拟功能”的映射关系。
五、切换模型的实际含义
把上述关系落到工程上，可以这样理解：主机侧看到的 PF 和 VF 是“功能视角”，DPU 内部看到的 representor 是“端口视角”，两者通过 eSwitch 建立映射。当 VM-A 的 VF0 发包时，包先进入 VF0 的队列，DPU 识别到它对应 representor 0，于是可以在 eSwitch 里查规则：是否允许访问某个 VLAN、是否需要镜像给监控口、是否要限速。规则命中后再从物理口发出。反向收包同理，物理口收到包后按目的 representor 分发到对应 VF。
这种模型带来的直接好处是：策略不再依赖 Hypervisor 的软件 vSwitch，而是下沉到 DPU 硬件切换域，既保留了 VF 直通的性能，又恢复了类似 OVS 的可编程能力。对于多租户场景，每个租户的 VF 和 representor 可以绑定到独立的 VNI/VLAN，实现租户间二层隔离。
lspci 是否看到 VF、DPU 侧 devlink port 是否列出对应 representor、以及 eSwitch 规则计数是否随流量增长。三者一致，说明映射关系正确建立。六、一个可参考的配置观察示例
以下命令用于在 DPU 侧确认 representor 与 VF 的对应关系，属于教学示例，实际名称以设备枚举为准：
# 查看 devlink 端口列表，识别物理口与 representor
devlink port show
# 典型输出片段（示例）：
# pci/0000:03:00.0/0: type eth netdev enp3s0f0np0 flavour physical
# pci/0000:03:00.0/1: type eth netdev enp3s0f0np0vf0 flavour pcivf
# pci/0000:03:00.0/2: type eth netdev enp3s0f0np0vf1 flavour pcivf
# 查看 eSwitch 模式与规则
devlink dev eswitch show pci/0000:03:00.0
tc -s filter show dev enp3s0f0np0 ingress观察要点：flavour physical 对应物理口，flavour pcivf 对应 VF representor；eswitch show 中的 mode 若为 switchdev，表示规则由内核/DPU 硬件卸载路径处理，若为 legacy 则更多依赖驱动内部逻辑。规则计数增长说明流量确实经过了 eSwitch，而不是被旁路。
七、常见误区与排障方向
- 把 PF 当数据口用：PF 更适合管理面，数据面应优先使用 VF 或 representor 路径，否则容易与主机网络栈耦合过深。
- VF 直通后忘记建 representor：没有 representor，eSwitch 就看不到这个 VF，策略和镜像都会失效。
- IB 模式下套用以太网假设：IB 使用 LID/GID 和 SM，不能直接套用 MAC/VLAN 的排障思路。
- VirtIO 与 VF 混用时路径不清：建议先明确“控制面走谁、数据面走谁”，再分别验证两条路径的计数与连通性。
掌握这五个概念之间的关系，就掌握了 BlueField 数据面的“坐标系”：链路模式决定底层承载，PF/VF 决定主机侧功能划分，SR-IOV 决定隔离与性能，VirtIO 决定兼容与迁移，Representor 与 eSwitch 决定策略能否统一下沉。后续的卸载、加速与多租户配置，都是在这套坐标系上展开的。