3. DPDK Bonding驱动架构：DPDK PMD与Bonding驱动的关系

在DPDK生态中，Bonding驱动并非一个独立的硬件驱动，而是构建在现有物理端口PMD（Poll Mode Driver）之上的一个逻辑聚合层。理解DPDK PMD与Bonding驱动的关系，是掌握主备切换延迟测试与故障排查的基础。

3.1 分层架构：从物理端口到逻辑聚合

DPDK的Bonding架构严格遵循分层设计，从上到下依次为：应用层 → Bonding虚拟PMD → 物理端口PMD → 硬件。这种设计使得上层应用无需感知底层物理端口的数量与拓扑，只需与一个统一的Bonding端口交互。

3.2 PMD与Bonding驱动的职责划分

为了更清晰地理解两者的协作关系，下表从多个维度对比了物理PMD与Bonding虚拟PMD的职责差异：

3.3 Bonding驱动的内部实现机制

DPDK Bonding驱动在实现上，通过回调函数（Callbacks）和代理模式（Proxy Pattern）将物理PMD的操作“包装”起来。其核心数据结构为 struct bond_dev_private，其中保存了成员端口列表、当前活动端口、Bonding模式等信息。

以下是一个简化的Bonding驱动初始化流程代码片段，展示了如何将物理PMD注册为Bonding的成员：

// 伪代码：Bonding驱动创建与成员添加流程
// 1. 创建Bonding虚拟设备
int bond_port_id = rte_eth_bond_create("bond0", BONDING_MODE_ACTIVE_BACKUP, 0);

// 2. 将物理端口添加到Bonding组
rte_eth_bond_member_add(bond_port_id, physical_port_id_0);
rte_eth_bond_member_add(bond_port_id, physical_port_id_1);

// 3. 设置主端口（Active）
rte_eth_bond_primary_set(bond_port_id, physical_port_id_0);

// 4. 启动Bonding端口（内部会启动所有成员端口）
rte_eth_dev_start(bond_port_id);

// 5. 应用层只需通过bond_port_id进行收发
//    实际数据由Bonding PMD调度到physical_port_id_0或physical_port_id_1
rte_eth_rx_burst(bond_port_id, 0, rx_pkts, BURST_SIZE);
rte_eth_tx_burst(bond_port_id, 0, tx_pkts, nb_pkt);

3.4 主备模式下的数据流路径

在主备（Active-Backup）模式下，Bonding PMD的数据流路径最为清晰，也是我们后续延迟测试的重点关注对象：

3.5 关键差异总结

• 透明性： 应用层通过标准rte_eth_* API操作Bonding端口，完全感知不到底层物理端口的存在。
• 故障隔离： 物理PMD负责硬件级错误处理（如描述符环溢出），Bonding PMD负责链路级故障切换（如网线断开）。
• 性能开销： Bonding PMD在数据路径上增加了一层函数调用和调度逻辑，在高速转发场景下（如线速10G/25G）会引入微秒级的额外延迟，这也是主备切换延迟测试需要精确测量的原因。
• 调试视角： 排查Bonding故障时，需要同时检查Bonding PMD的状态（通过rte_eth_bond_*_get系列API）和物理PMD的状态（通过rte_eth_link_get）。