From: "David S. Miller" <davem@redhat.com>
To: cfriesen@nortelnetworks.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 14:17:30 -0700 (PDT) [thread overview]
Message-ID: <20020916.141730.20023507.davem@redhat.com> (raw)
In-Reply-To: <3D864B96.6D0D43F4@nortelnetworks.com>
From: Chris Friesen <cfriesen@nortelnetworks.com>
Date: Mon, 16 Sep 2002 17:22:30 -0400
I did see those posts, but then I saw yours on how the linux
receive end does the right thing with regards to reordering, and
that confused me.
It's a last ditch effort to keep receive performance on the TCP
connection reasonable, it is not meant to be a normal mode
of operation. The reordering detection in the TCP stack does
not get you back to optimal receive performance, it simply can't.
For one thing, all of the fast paths in the TCP input paths require
that the packets arrive in order.
If bonding did what you suggest, reordering would become the norm
and that isn't going to be good for TCP input performance whether
we have reordering detection logic or not.
next prev parent reply other threads:[~2002-09-16 21:17 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
2002-09-16 21:04 ` David S. Miller
2002-09-16 21:22 ` Chris Friesen
2002-09-16 21:17 ` David S. Miller [this message]
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=20020916.141730.20023507.davem@redhat.com \
--to=davem@redhat.com \
--cc=cacophonix@yahoo.com \
--cc=cfriesen@nortelnetworks.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).