All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.