diff options
author | John Eaglesham <linux@8192.net> | 2012-08-21 16:43:35 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2012-08-23 01:49:30 -0400 |
commit | 6b923cb7188d46905f43fa84210c4c3e5f9cd8fb (patch) | |
tree | 397012f5f344a693e70999ef67fa1b2a23e7d96f /Documentation/networking | |
parent | b87fb39e399137257a6db3224ea854117e9486e9 (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')
-rw-r--r-- | Documentation/networking/bonding.txt | 30 |
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 | ||