背景
参考 dpdk 官方 bonding pmd 文档，mode 0 是轮循，mode 1 是镜像，我司线上使用的 mode 4 是 802.3AD 协义，使用特定层面 hash 算法来分配流量。
使用 mode 4 比较特别，要求
- It needs to call rte_eth_tx_burst and rte_eth_rx_burst with intervals period of less than 100ms.
- Calls to rte_eth_tx_burst must have a buffer size of at least 2xN, where N is the number of slaves. This is a space required for LACP frames. Additionally LACP packets are included in the statistics, but they are not returned to the application.
dpvs bond 问题
最初搭建 fullnat 时想用网卡 bonding, 由于线上都是 mode 4, 不给网络组同学添麻烦，最好保持一致。但是 dpvs 程序启动后，初始化报 warning，并且交换机也看到 bonding 失败。具体报错消息如下：
PMD: Slave 1: failed to enqueue LACP packet into RX ring.
Receive and transmit functions must be invoked on bonded
interface at least 10 times per second or LACP will not
work correctly
将 DPDK 编绎成 DEBUG 模式，打开 bond debug 开关。dpvs 也全部打开 DEBUG, 查看日志输出：
PMD: 625 [Port 0: rx_machine] LACP -> CURRENT
PMD: LACP: {
subtype= 01
ver_num=01
actor={ tlv=01, len=14
pri=0080, system=B4:43:26:57:15:01, key=410E, p_pri=0080 p_num=5E00
state={ ACT AGG DEF }
}
partner={ tlv=02, len=14
pri=0000, system=00:00:00:00:00:00, key=0000, p_pri=0000 p_num=0000
state={ ACT AGG DEF EXP }
}
collector={info=03, length=10, max_delay=0000
, type_term=00, terminator_length = 00}
PMD: 625 [Port 0: tx_machine] Sending LACP frame
PMD: LACP: {
subtype= 01
ver_num=01
actor={ tlv=01, len=14
pri=FFFF, system=6C:92:BF:47:B2:66, key=2100, p_pri=FF00 p_num=0100
state={ ACT AGG }
}
partner={ tlv=02, len=14
pri=0080, system=B4:43:26:57:15:01, key=410E, p_pri=0080 p_num=5E00
state={ ACT AGG DEF }
}
collector={info=03, length=10, max_delay=0000
, type_term=00, terminator_length = 00}
结合 dpdk 源代码解读，rx_machine 是收取交换机发来的协义消息，成功接收，看到交换机的 mac 地址 B4:43:26:57:15:01，dpdk 根据 mode 4 协义发送 lacp 回包，内容和接收的相反，bond 网卡 mac 是 6C:92:BF:47:B2:66，结合最后报错 failed to enqueue LACP packet into RX ring, 可以定性是 tx_ring 队列一直没消费，dpvs 没有发送 lacp 回包给交换机。
dpvs 发包逻辑
dpvs发包都在大 loop 里，是个死循环，发送函数是 lcore_job_xmit
static void lcore_job_xmit(void *args)
{
int i, j;
lcoreid_t cid;
portid_t pid;
struct netif_queue_conf *qconf;
cid = rte_lcore_id();
for (i = 0; i < lcore_conf[lcore2index[cid]].nports; i++) {
pid = lcore_conf[lcore2index[cid]].pqs[i].id;
for (j = 0; j < lcore_conf[lcore2index[cid]].pqs[i].ntxq; j++) {
qconf = &lcore_conf[lcore2index[cid]].pqs[i].txqs[j];
if (qconf->len <= 0)
continue;
netif_tx_burst(cid, pid, j);
qconf->len = 0;
}
}
}
static inline void netif_tx_burst(lcoreid_t cid, portid_t pid, queueid_t qindex)
{
int ntx, ii;
struct netif_queue_conf *txq;
unsigned i = 0;
struct rte_mbuf *mbuf_copied = NULL;
struct netif_port *dev = NULL;
assert(LCORE_ID_ANY != cid);
txq = &lcore_conf[lcore2index[cid]].pqs[port2index[cid][pid]].txqs[qindex];
if (0 == txq->len)
return;
dev = netif_port_get(pid);
......
ntx = rte_eth_tx_burst(pid, txq->id, txq->mbufs, txq->len);
lcore_stats[cid].opackets += ntx;
/* do not calculate obytes here in consideration of efficency */
if (unlikely(ntx < txq->len)) {
RTE_LOG(DEBUG, NETIF, "Fail to send %d packets on dpdk%d tx%d\n", ntx,pid, txq->id);
lcore_stats[cid].dropped += txq->len - ntx;
for (ii = ntx; ii < txq->len; ii++)
rte_pktmbuf_free(txq->mbufs[ii]);
}
}
基本逻辑，就是判断 qconf->len 发包队列长度，如果大于 0，表示有数据需要发送。最终调用 dpdk 库函数 rte_eth_tx_burst 完成最终发送逻辑。
但是这个 qconf 队列和 lacp tx_ring 有什么关系呢？完全没有关系...
dpdk lacp 发包逻辑
首先，每个物理网卡都是一个 rte_eth_dev, 而 bonding 的网卡是 rte_vdev_device, 需要调用 bond_alloc 初始化，最重要有两个函数 bond_mode_8023ad_setup 和 bond_ethdev_mode_set
bond_mode_8023ad_setup 会设置一个定时器，每 100ms 调用一次 bond_mode_8023ad_periodic_cb 函数，这个就是用来协商 lacp 的。rx_machine_update 接收 rx_ring 数据，tx_machine 封装好本机 lacp 后发送到 tx_ring. bond_ethdev_mode_set 最重要的是调置 rx_burst 和 tx_burst 回调函数
eth_dev->rx_pkt_burst = bond_ethdev_rx_burst_8023ad;
eth_dev->tx_pkt_burst = bond_ethdev_tx_burst_8023ad;
非 bonding 的普通网卡，tx_pkt_burst，rx_pkt_burst 都是 ixgbe 的。
bond_ethdev_tx_burst_8023ad 代码比较长不贴了，原理就是在业务正常调用 rte_eth_tx_burst 时，顺便把 lacp tx_ring 的数据发送到网卡。
问题所在
结合两个发包逻辑可以明确，dpvs 属于业务层，qconf 的缓存里有数据才发送，而 lcap 的数据是存储在 dpdk 底层的 tx_ring 中，当 bond 网卡刚被 dpvs up 起来时，业务层是没有数据的，也就不会调用 rte_eth_tx_burst 顺便把 lacp 发送给交换机。
解决方案？
最简单的就是修改 lcore_job_xmit 代码，去掉所有队列长度判断的逻辑，这样就会一直调用底层 rte_eth_tx_burst. 测试一下，bond 成功。但是性能肯定会受影响，希望 dpvs 开发团队能 fix 一下。
想到的另外一个方案，就是注册一个 slow 类型的 job，专职用于刷新 lacp, 我去掉个 pr 吧。
