From: Rick Jones <rick.jones2@hp.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Linux Network Development list <netdev@vger.kernel.org>
Subject: Re: error(s) in 2.6.23-rc5 bonding.txt ?
Date: Fri, 07 Sep 2007 16:46:54 -0700 [thread overview]
Message-ID: <46E1E2EE.7080202@hp.com> (raw)
In-Reply-To: <32121.1189207861@death>
> That said, it's certainly plausible that, for a given set of N
> ethernets all enslaved to a single bonding balance-rr, the individual
> ethernets could get out of sync, as it were (e.g., one running a fuller
> tx ring, and thus running "behind" the others).
That is the scenario of which I was thinking.
> If bonding is the only feeder of the devices, then for a continuous
> flow of traffic, all the slaves will generally receive packets (from
> the kernel, for transmission) at pretty much the same rate, and so
> they won't tend to get ahead or behind.
I could see that if there was just one TCP connection going doing bulk
or something, but if there were a bulk transmitter coupled with an
occasional request/response (ie netperf TCP_STREAM and a TCP_RR) i'd
think the tx rings would no longer remain balanced.
> I haven't investigated into this deeply for a few years, but
> this is my recollection of what happened with the tests I did then. I
> did testing with multiple 100Mb devices feeding either other sets of
> 100Mb devices or single gigabit devices. I'm willing to believe that
> things have changed, and an N feeding into one configuration can
> reorder, but I haven't seen it (or really looked for it; balance-rr
> isn't much the rage these days).
Are you OK with that block of text simply being yanked?
rick
next prev parent reply other threads:[~2007-09-07 23:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 22:02 error(s) in 2.6.23-rc5 bonding.txt ? Rick Jones
2007-09-07 23:31 ` Jay Vosburgh
2007-09-07 23:46 ` Rick Jones [this message]
2007-09-08 1:01 ` Jay Vosburgh
2007-09-28 21:31 ` Rick Jones
2007-09-08 6:05 ` Bill Fink
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=46E1E2EE.7080202@hp.com \
--to=rick.jones2@hp.com \
--cc=fubar@us.ibm.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).