[ovs-dev] [PATCH 7/8] vswitchd: Implement balance-tcp bonding.
blp at nicira.com
Tue Feb 1 21:54:38 UTC 2011
On Sun, Jan 30, 2011 at 03:58:14PM -0800, Ethan Jackson wrote:
> This commit implements a new bonding mode "balance-tcp" which takes
> into account L4 flow information when hashing. If LACP negotiation
> is unsuccessful it automatically falls back to "balance-slb" bonding.
> Bug #4213.
I'm not sure that bond_hash_tcp() is careful enough. It will come up
with different hashes for ICMP packets with different types and codes,
and for ARP packets with different inner IP addresses, for example.
bond_hash_tcp() basically takes a "blacklisting" approach: hash the
whole flow except for fields known not to be valid for link selection.
I would consider taking the opposite "whitelisting" approach: hash only
the fields known to be valid for link selection. Then new fields added
to the flow structure couldn't invalidate the algorithm. You could use
hash_symmetric_l4() from multipath.c as an example of that approach.
Maybe we should put hash_symmetric_l4() and your new function in flow.c,
since they seem to be generally interesting.
If you do keep the blacklisting approach for some reason then you can
use struct assignment in place of memcpy in bond_hash_tcp().
I don't see what difference the change to bond_send_learning_packets()
makes. It looks equivalent to me.
Should bond_unixctl_show() just skip listing MACs if L4 hashing is
turned on? The information it prints is not meaningful in that case,
When no bond mode is explicitly set, would it make sense to default to
balance-tcp if LACP negotiation succeeds?
In vswitch.xml, we can delete the list of supported modes, since the
ovsdb doc processor automatically lists them. But it would be a good
idea to describe some details of each mode.
Did you revise the following text in vswitch.xml somewhere in this
series? It is not accurate anymore:
A port that has more than one interface is a ``bonded port.''
Bonding allows for load balancing and failover. Open vSwitch
supports ``source load balancing'' (SLB) and "active backup"
bonding. SLB bonding assigns flows to slaves based on source MAC
address and output VLAN, with periodic rebalancing as traffic
patterns change. Active backup bonding assigns all flows to one
slave, failing over to a backup slave when the active slave is
disabled. Neither form of bonding require 802.3ad or other special
support from the upstream switch to which the slave devices are
More information about the dev