From: Rick Jones <rick.jones2@hp.com>
To: netdev@vger.kernel.org
Subject: [PATCH] remove claim balance_rr won't reorder on many to one
Date: Tue, 30 Oct 2007 12:48:47 -0700 (PDT) [thread overview]
Message-ID: <200710301948.MAA04351@tardy.cup.hp.com> (raw)
Remove the text which suggests that many balance_rr links feeding into
a single uplink will not experience packet reordering.
More up-to-date tests, with 1G links feeding into a switch with a 10G
uplink, using a 2.6.23-rc8 kernel on the system on which the 1G links
were bonded with balance_rr (mode=0) shows that even a many to one
link configuration will experience packet reordering and the attendant
TCP issues involving spurrious retransmissions and the congestion
window. This happens even with a single, simple bulk transfer such as
a netperf TCP_STREAM test. A more complete description of the tests
and results, including tcptrace analysis of packet traces showing the
degree of reordering and such can be found at:
http://marc.info/?l=linux-netdev&m=119101513406349&w=2
Also, note that some switches use the term "trunking" in a context
other than link aggregation.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
diff -r 35e54d4beaad Documentation/networking/bonding.txt
--- a/Documentation/networking/bonding.txt Wed Oct 24 05:06:40 2007 +0000
+++ b/Documentation/networking/bonding.txt Mon Oct 29 03:47:19 2007 -0700
@@ -1696,23 +1696,6 @@ balance-rr: This mode is the only mode t
interface's worth of throughput, even after adjusting
tcp_reordering.
- Note that this out of order delivery occurs when both the
- sending and receiving systems are utilizing a multiple
- interface bond. Consider a configuration in which a
- balance-rr bond feeds into a single higher capacity network
- channel (e.g., multiple 100Mb/sec ethernets feeding a single
- gigabit ethernet via an etherchannel capable switch). In this
- configuration, traffic sent from the multiple 100Mb devices to
- a destination connected to the gigabit device will not see
- packets out of order. However, traffic sent from the gigabit
- device to the multiple 100Mb devices may or may not see
- traffic out of order, depending upon the balance policy of the
- switch. Many switches do not support any modes that stripe
- traffic (instead choosing a port based upon IP or MAC level
- addresses); for those devices, traffic flowing from the
- gigabit device to the many 100Mb devices will only utilize one
- interface.
-
If you are utilizing protocols other than TCP/IP, UDP for
example, and your application can tolerate out of order
delivery, then this mode can allow for single stream datagram
@@ -1720,7 +1703,9 @@ balance-rr: This mode is the only mode t
to the bond.
This mode requires the switch to have the appropriate ports
- configured for "etherchannel" or "trunking."
+ configured for "etherchannel" or "aggregation." N.B. some
+ switches might use the term "trunking" for something other
+ than link aggregation.
active-backup: There is not much advantage in this network topology to
the active-backup mode, as the inactive backup devices are all
next reply other threads:[~2007-10-30 19:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 19:48 Rick Jones [this message]
2007-10-30 20:55 ` [PATCH] remove claim balance_rr won't reorder on many to one Jay Vosburgh
2007-10-30 22:12 ` Rick Jones
2007-10-31 0:22 ` Jay Vosburgh
2007-10-31 1:02 ` Rick Jones
2007-10-31 1:08 ` Rick Jones
2007-11-06 21:40 ` Rick Jones
2007-11-06 22:49 ` Jay Vosburgh
2007-11-06 22:59 ` Rick Jones
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=200710301948.MAA04351@tardy.cup.hp.com \
--to=rick.jones2@hp.com \
--cc=netdev@vger.kernel.org \
/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).