Re: bonding vs 802.3ad/Cisco EtherChannel link agregation

[Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx>]

"David S. Miller" wrote:

> There is a lot of logic in our TCP input btw that notices packet
> reordering on the receive side and acts accordingly (ie. it does not
> fire off fast retransmits or backoff prematurely when reordering
> is detected)

Okay, that makes me even more curious why we don't send successive packets out 
successive pipes in a
bonded link.

It seems to me that when sending packets out a bonded link, we should scan for 
the next device that
has an opening on its queue (perhaps also taking into account link speed etc) 
so as to try and keep
the entire aggregate link working at max capacity.

Does this not make sense in the real world for some reason?  Maybe a config 
option
CONFIG_MAX_BONDED_THROUGHPUT to allow a single stream to take up the entire 
aggregate link even if
it makes the receiver do more work?

Chris