netdev - Re: Bonding gigabit and fast?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20484.1229489335@death.nxdomain.ibm.com>
Date:	Tue, 16 Dec 2008 20:48:55 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	"Tvrtko A. Ursulin" <tvrtko@...ulin.net>
cc:	Chris Snook <csnook@...hat.com>, netdev@...r.kernel.org
Subject: Re: Bonding gigabit and fast?

Tvrtko A. Ursulin <tvrtko@...ulin.net> wrote:
[...]
>I was using balance-rr, alb flavour does not seem to like 8139too.

	The choice of balance-rr may be half of your problem.  Try
balance-xor with xmit_hash_policy=layer3+4, it may behave better.  That
mode doesn't know about dissimilar speed slaves, so it simply balances
by math, but that still may behave better than balance-rr because it
won't stripe single connections across slaves.

	The balance-alb mode would likely be better (it's smarter about
balancing across slaves of differing speeds), but requires that the
slaves be able to change MAC address while up, which not every device is
capable of doing.

	To elaborate a bit on balance-rr, it will usually cause out of
order delivery to varying degrees, which in turn causes TCP's congestion
control and/or fast retransmits to kick in.  The effect can be mitigated
to some degree (but not eliminated) by raising the value of the
net.ipv4.tcp_reordering sysctl.  If memory serves, values more than
about 125 don't make much additional difference.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html