[dpdk-dev] rte_eth_bond 8023ad behaviour under congestion

[Kyle Larose <klarose@sandvine.com>]

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