From: Xiangning Yu
There is a timing issue under active-standy mode, when bond_enslave() is
called, bond->params.primary might not be initialized yet.
Any time the primary slave string changes, bond->force_primary should be
set to true to make sure the primary becomes the active slave.
Hi netdev folks,
While playing with bonding active-standby mode, we found a possible
timing issue that the primary might not initialized in bond_enslave():
if (bond_uses_primary(bond) && bond->params.primary[0]) {
/* if there is a primary slave, remember it */
On Mon, Jan 23, 2017 at 12:56 PM, Cong Wang wrote:
> On Mon, Jan 23, 2017 at 10:46 AM, Xiangning Yu wrote:
>> Hi netdev folks,
>>
>> It looks like we call dev_forward_skb() in veth_xmit(), which calls
>> netif_rx() eventually.
>>
>> While netif_rx() wil
On Mon, Jan 23, 2017 at 11:07 AM, Eric Dumazet wrote:
> On Mon, 2017-01-23 at 10:46 -0800, Xiangning Yu wrote:
>> Hi netdev folks,
>>
>> It looks like we call dev_forward_skb() in veth_xmit(), which calls
>> netif_rx() eventually.
>>
>> While netif_rx() wil
Hi netdev folks,
It looks like we call dev_forward_skb() in veth_xmit(), which calls
netif_rx() eventually.
While netif_rx() will enqueue the skb to the CPU RX backlog before the
actual processing takes place. So, this actually means a TX skb has to
wait some un-related RX skbs to finish. And thi
