aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking/bonding.txt
diff options
context:
space:
mode:
authorJohn Eaglesham <linux@8192.net>2012-08-21 16:43:35 -0400
committerDavid S. Miller <davem@davemloft.net>2012-08-23 01:49:30 -0400
commit6b923cb7188d46905f43fa84210c4c3e5f9cd8fb (patch)
tree397012f5f344a693e70999ef67fa1b2a23e7d96f /Documentation/networking/bonding.txt
parentb87fb39e399137257a6db3224ea854117e9486e9 (diff)
bonding: support for IPv6 transmit hashing
Currently the "bonding" driver does not support load balancing outgoing traffic in LACP mode for IPv6 traffic. IPv4 (and TCP or UDP over IPv4) are currently supported; this patch adds transmit hashing for IPv6 (and TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the bonding driver. In addition, bounds checking has been added to all transmit hashing functions. The algorithm chosen (xor'ing the bottom three quads of the source and destination addresses together, then xor'ing each byte of that result into the bottom byte, finally xor'ing with the last bytes of the MAC addresses) was selected after testing almost 400,000 unique IPv6 addresses harvested from server logs. This algorithm had the most even distribution for both big- and little-endian architectures while still using few instructions. Its behavior also attempts to closely match that of the IPv4 algorithm. The IPv6 flow label was intentionally not included in the hash as it appears to be unset in the vast majority of IPv6 traffic sampled, and the current algorithm not using the flow label already offers a very even distribution. Fragmented IPv6 packets are handled the same way as fragmented IPv4 packets, ie, they are not balanced based on layer 4 information. Additionally, IPv6 packets with intermediate headers are not balanced based on layer 4 information. In practice these intermediate headers are not common and this should not cause any problems, and the alternative (a packet-parsing loop and look-up table) seemed slow and complicated for little gain. Tested-by: John Eaglesham <linux@8192.net> Signed-off-by: John Eaglesham <linux@8192.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking/bonding.txt')
-rw-r--r--Documentation/networking/bonding.txt30
1 files changed, 25 insertions, 5 deletions
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 6b1c7110534e..10a015c384b8 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -752,12 +752,22 @@ xmit_hash_policy
752 protocol information to generate the hash. 752 protocol information to generate the hash.
753 753
754 Uses XOR of hardware MAC addresses and IP addresses to 754 Uses XOR of hardware MAC addresses and IP addresses to
755 generate the hash. The formula is 755 generate the hash. The IPv4 formula is
756 756
757 (((source IP XOR dest IP) AND 0xffff) XOR 757 (((source IP XOR dest IP) AND 0xffff) XOR
758 ( source MAC XOR destination MAC )) 758 ( source MAC XOR destination MAC ))
759 modulo slave count 759 modulo slave count
760 760
761 The IPv6 formula is
762
763 hash = (source ip quad 2 XOR dest IP quad 2) XOR
764 (source ip quad 3 XOR dest IP quad 3) XOR
765 (source ip quad 4 XOR dest IP quad 4)
766
767 (((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
768 XOR (source MAC XOR destination MAC))
769 modulo slave count
770
761 This algorithm will place all traffic to a particular 771 This algorithm will place all traffic to a particular
762 network peer on the same slave. For non-IP traffic, 772 network peer on the same slave. For non-IP traffic,
763 the formula is the same as for the layer2 transmit 773 the formula is the same as for the layer2 transmit
@@ -778,19 +788,29 @@ xmit_hash_policy
778 slaves, although a single connection will not span 788 slaves, although a single connection will not span
779 multiple slaves. 789 multiple slaves.
780 790
781 The formula for unfragmented TCP and UDP packets is 791 The formula for unfragmented IPv4 TCP and UDP packets is
782 792
783 ((source port XOR dest port) XOR 793 ((source port XOR dest port) XOR
784 ((source IP XOR dest IP) AND 0xffff) 794 ((source IP XOR dest IP) AND 0xffff)
785 modulo slave count 795 modulo slave count
786 796
787 For fragmented TCP or UDP packets and all other IP 797 The formula for unfragmented IPv6 TCP and UDP packets is
788 protocol traffic, the source and destination port 798
799 hash = (source port XOR dest port) XOR
800 ((source ip quad 2 XOR dest IP quad 2) XOR
801 (source ip quad 3 XOR dest IP quad 3) XOR
802 (source ip quad 4 XOR dest IP quad 4))
803
804 ((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
805 modulo slave count
806
807 For fragmented TCP or UDP packets and all other IPv4 and
808 IPv6 protocol traffic, the source and destination port
789 information is omitted. For non-IP traffic, the 809 information is omitted. For non-IP traffic, the
790 formula is the same as for the layer2 transmit hash 810 formula is the same as for the layer2 transmit hash
791 policy. 811 policy.
792 812
793 This policy is intended to mimic the behavior of 813 The IPv4 policy is intended to mimic the behavior of
794 certain switches, notably Cisco switches with PFC2 as 814 certain switches, notably Cisco switches with PFC2 as
795 well as some Foundry and IBM products. 815 well as some Foundry and IBM products.
796 816