"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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
