Hello,
I've been doing some testing using the 8023ad link bonding driver on a system
with 4 10G i40e interfaces in the link bond. One thing I've noticed is that if
any of the links are overloaded when I don't have dedicated control queues
enabled, it starts dropping LACPDUs on transmit. I quickly realized that it's
because of the following code in bond_ethdev_tx_burst_8023ad:
num_tx_slave = rte_eth_tx_burst(slaves[i], bd_tx_q->queue_id,
slave_bufs[i], slave_nb_pkts[i]);
/* If tx burst fails drop slow packets */
for ( ; num_tx_slave < slave_slow_nb_pkts[i]; num_tx_slave++)
rte_pktmbuf_free(slave_bufs[i][num_tx_slave]);
This chunk of code basically treats the LACPPDUs at a very low priority, since
they are generated infrequently. I'd like to ensure that LACPPDUs are
transmitted when there's congestion in the case where dedicated queues are not
supported.
I can think of a few options to resolve this:
1) Store the LACPDUS for later sending in a per-slave buffer if tx fails, and
make sure these are always at the front of the send buffer, so that when
there's room, they're sent (I'm not quite sure what the best way to do this is).
2) Allow enabling the dedicated tx queue without enabling the dedicated rx
queue.
I think both 1 & 2 are good solutions on their own, and should probably both be
implemented. #2 is ideal, but doesn't cover all cases (like if there are
insufficient tx queues to dedicate one to this).
How do people feel about these proposals?
Note: I understand that this is not ideal at all, since the lack of a dedicated
rx queue means that lacpdus could drop on rx. But, in my use-case that's less
likely than link congestion, so I'd like to at least be resilient here.
Thanks,
Kyle