From: Chris Friesen <cfriesen@nortelnetworks.com>
To: "David S. Miller" <davem@redhat.com>
Cc: greearb@candelatech.com, cacophonix@yahoo.com,
linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: bonding vs 802.3ad/Cisco EtherChannel link agregation
Date: Mon, 16 Sep 2002 17:10:06 -0400 [thread overview]
Message-ID: <3D8648AE.DD498ECE@nortelnetworks.com> (raw)
In-Reply-To: 20020916.125555.36549381.davem@redhat.com
"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
next prev parent reply other threads:[~2002-09-16 21:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-12 18:39 bonding vs 802.3ad/Cisco EtherChannel link agregation Boris Protopopov
2002-09-12 23:34 ` David S. Miller
2002-09-13 14:29 ` Chris Friesen
2002-09-13 22:22 ` Cacophonix
2002-09-16 13:23 ` Chris Friesen
2002-09-16 16:09 ` Ben Greear
2002-09-16 19:55 ` David S. Miller
2002-09-16 21:10 ` Chris Friesen [this message]
2002-09-16 21:04 ` David S. Miller
2002-09-16 21:22 ` Chris Friesen
2002-09-16 21:17 ` David S. Miller
2002-09-17 10:16 ` jamal
2002-09-17 16:43 ` Ben Greear
2002-09-18 1:07 ` jamal
2002-09-18 4:06 ` Ben Greear
2002-09-18 11:48 ` jamal
-- strict thread matches above, loose matches on Subject: below --
2002-09-13 1:30 Feldman, Scott
2002-09-13 14:50 ` Boris Protopopov
2002-09-16 20:12 Yan-Fa Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D8648AE.DD498ECE@nortelnetworks.com \
--to=cfriesen@nortelnetworks.com \
--cc=cacophonix@yahoo.com \
--cc=davem@redhat.com \
--cc=greearb@candelatech.com \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).