Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
So, where do you and I stand wrt the proposed changes to bonding.txt? Are
we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe the
Rick Jones <[EMAIL PROTECTED]> wrote:
>So, where do you and I stand wrt the proposed changes to bonding.txt? Are
>we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe the
levels of badness, as
Jay -
So, where do you and I stand wrt the proposed changes to bonding.txt? Are we at
an impass?
sincerely,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
2- next worst is "balance-rr many slow" to "single fast", with
the reordering rate generally being substantially lower than case #1 (it
looked like your test showed about a 1% reordering rate, if I'm reading
your data correctly).
The percentage of reordering for TCP is likely capped by i
Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
I have to wonder if the full description of the different versions of
being a little bit pregnant is worth it. Just saying that using
balance-rr will result in reordering seems much more simple to comprehend.
True, but the d
Rick Jones <[EMAIL PROTECTED]> wrote:
>I have to wonder if the full description of the different versions of
>being a little bit pregnant is worth it. Just saying that using
>balance-rr will result in reordering seems much more simple to comprehend.
True, but the different configuration
Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
[...]
- 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 sing
Rick Jones <[EMAIL PROTECTED]> wrote:
[...]
>- 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 netwo
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 (mod