[bonding][BUG] UDP Tx stops after link disconnection of active slave

[bonding][BUG] UDP Tx stops after link disconnection of active slave

[Shmulik Hen]

Hi,

	We've noticed that when using configuring bonding to active backup
mode with two slaves and running UDP stress traffic to several clients,
traffic will stop when disconnecting the link for the current active
slave. When re-connecting the slave the traffic will resume even though it
is not the active slave anymore. While traffic is stopped it looks as
though the application generating the traffic (iperf, netperf, etc.) is
hung and doesn't generate new packets. Once link is restored the
application wakes up again and stars sending new packets. Further
investigation showed that slave adapters tend to stop processing the queue
when their link is down, and therefore any packets that were already
passed from bonding to the disconnected slave are *stuck* in the queue,
thus causing the resources associated with those packets not to free and
so the application hits it's resource limits and stalls. Upon link
connection, the packets in the queue are processed and the application is
free to allocate new resources.

Is there any safe way for bonding to empty the queue of slaves that lost
their link/ became inactive?

-- 
| Shmulik Hen                             |
| Israel Design Center (Jerusalem)        |
| LAN Access Division                     |
| Intel Communications Group, Intel corp. |

Re: [bonding][BUG] UDP Tx stops after link disconnection of active slave

[Chad N. Tindel]

> 	We've noticed that when using configuring bonding to active backup
> mode with two slaves and running UDP stress traffic to several clients,
> traffic will stop when disconnecting the link for the current active
> slave. When re-connecting the slave the traffic will resume even though it
> is not the active slave anymore. While traffic is stopped it looks as
> though the application generating the traffic (iperf, netperf, etc.) is
> hung and doesn't generate new packets. Once link is restored the
> application wakes up again and stars sending new packets. Further
> investigation showed that slave adapters tend to stop processing the queue
> when their link is down, and therefore any packets that were already
> passed from bonding to the disconnected slave are *stuck* in the queue,
> thus causing the resources associated with those packets not to free and
> so the application hits it's resource limits and stalls. Upon link
> connection, the packets in the queue are processed and the application is
> free to allocate new resources.
> 
> Is there any safe way for bonding to empty the queue of slaves that lost
> their link/ became inactive?

Interesting.  Perhaps bonding should go through the queue and move all the 
pending packets over into the new active slave?  It'd be nice if we could
just transfer the entire IP stack around as one big object...

Chad