[dpdk-dev] rte_eth_bond: Packets are received by lag despite interface not collecting

[dpdk-dev] rte_eth_bond: Packets are received by lag despite interface not collecting

[Kyle Larose]

Hello,

I've run into some unexpected behaviour in the rte_eth_bond pmd using 8023ad mode with dedicated queues. bond_ethdev_rx_burst_8023ad_fast_queue iterates over all active slaves, and receives from each. This incorrectly ignores whether or not the interface is collecting. If it is not collecting, the packets should be discarded.

 Setup:
- 4x10G X710 links in a 8023ad lag. 3 are connected to a switch, another to a traffic generator.
- The 3 links form the lag fine. The 4th is taken out of the distribution logic, since the generator is not participating in LACP

Problem:
- If I send packets to a link that is not in the collecting state, the application receives those packets from the lag. It should not

Analysis:
 - Interfaces which are up but not collecting are considered active from the 8023ad lag's perspective
 - bond_ethdev_rx_burst_8023ad_fast_queue receives traffic from all active lags
 - Thus, regardless of the lacp state of the interface, traffic is received

Solution:
 - I think that bond_ethdev_rx_burst_8023ad_fast_queue went a little too far in its performance optimizations. It should still check the state of the slave prior to accepting the packets.

 My suggestion:

 1) If the slave is collecting, receive as normal. 
 2) Otherwise, receive the packets into the rx buffer, then free them, and count them as being discarded due to the slave not collecting (this could be useful for diagnostics).
 3) We receive to drain the rx queue, and so we can count. If we didn't we could get a burst of stale packets when the link starts collecting again.
 3) To try to prevent links in this state from consuming too much CPU resources, we could receive only portion of the burst size at a time.
    Presumably it shouldn't be getting *too* much traffic, but if it is, it'd probably be better to overflow the rxq and drop.


Thoughts?

Thanks,

Kyle