bonding support for IPv6 transmit hashing
Subsystems (3)
PATCH v3 2/2 bonding support for IPv6 transmit hashing
Documentation/networking/bonding.txt +26 -5
@@ -752,12 +752,22 @@ xmit_hash_policy protocol information to generate the hash. Uses XOR of hardware MAC addresses and IP addresses to - generate the hash. The formula is + generate the hash. The IPv4 formula is (((source IP XOR dest IP) AND 0xffff) XOR ( source MAC XOR destination MAC )) modulo slave count + The IPv6 forumla is + + iphash = + (source ip quad 2 XOR dest IP quad 2) XOR + (source ip quad 3 XOR dest IP quad 3) XOR + (source ip quad 4 XOR dest IP quad 4) + + ((iphash >> 16) XOR (iphash >> 8) XOR iphash) + modulo slave count + This algorithm will place all traffic to a particular network peer on the same slave. For non-IP traffic, the formula is the same as for the layer2 transmit
@@ -778,19 +788,30 @@ xmit_hash_policy slaves, although a single connection will not span multiple slaves. - The formula for unfragmented TCP and UDP packets is + The formula for unfragmented IPv4 TCP and UDP packets is ((source port XOR dest port) XOR ((source IP XOR dest IP) AND 0xffff) modulo slave count - For fragmented TCP or UDP packets and all other IP - protocol traffic, the source and destination port + The formula for unfragmented IPv6 TCP and UDP packets is + + iphash = + (source ip quad 2 XOR dest IP quad 2) XOR + (source ip quad 3 XOR dest IP quad 3) XOR + (source ip quad 4 XOR dest IP quad 4) + + ((source port XOR dest port) XOR + (iphash >> 16) XOR (iphash >> 8) XOR iphash) + modulo slave count + + For fragmented TCP or UDP packets and all other IPv4 and + IPv6 protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy. - This policy is intended to mimic the behavior of + The IPv4 policy is intended to mimic the behavior of certain switches, notably Cisco switches with PFC2 as well as some Foundry and IBM products.
Quoted 16 lines · John
Documentation/networking/bonding.txt +1
-1@@ -752,12 +752,22 @@ xmit_hash_policy protocol information to generate the hash. Uses XOR of hardware MAC addresses and IP addresses to - generate the hash. The formula is + generate the hash. The IPv4 formula is (((source IP XOR dest IP) AND 0xffff) XOR ( source MAC XOR destination MAC )) modulo slave count
Documentation/networking/bonding.txt xmit_hash_policy · line 770
Quoted 10 lines
Documentation/networking/bonding.txt +10
-0+ The IPv6 forumla is + + iphash = + (source ip quad 2 XOR dest IP quad 2) XOR + (source ip quad 3 XOR dest IP quad 3) XOR + (source ip quad 4 XOR dest IP quad 4) + + ((iphash >> 16) XOR (iphash >> 8) XOR iphash) + modulo slave count +
Wouldn't it be beneficial to include the ipv6 flow label in the hash calculation?
Greetings,
Hannes
Quoted 31 lines · Hannes Frederic Sowa
Quoted 16 lines · John
Documentation/networking/bonding.txt +1
-1@@ -752,12 +752,22 @@ xmit_hash_policy protocol information to generate the hash. Uses XOR of hardware MAC addresses and IP addresses to - generate the hash. The formula is + generate the hash. The IPv4 formula is (((source IP XOR dest IP) AND 0xffff) XOR ( source MAC XOR destination MAC )) modulo slave countDocumentation/networking/bonding.txt xmit_hash_policy · line 770
Quoted 10 lines
Documentation/networking/bonding.txt +10
-0+ The IPv6 forumla is + + iphash = + (source ip quad 2 XOR dest IP quad 2) XOR + (source ip quad 3 XOR dest IP quad 3) XOR + (source ip quad 4 XOR dest IP quad 4) + + ((iphash >> 16) XOR (iphash >> 8) XOR iphash) + modulo slave count +Wouldn't it be beneficial to include the ipv6 flow label in the hash calculation?
Quoted 8 lines
Greetings,
Hannes
--
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-info.html
Hannes,
In all of the traffic I inspected I don't believe I saw a single flow label set. Even if it were set 100% of the time by Linux, any packets routed or bridged from another operating system wouldn't see any benefit. The current algorithm distributes the traffic very well, I don't believe adding the flow label would be beneficial even if it were set more frequently.
If you feel strongly about its inclusion, though, I am willing to reconsider.
John
Quoted 36 lines · John
Quoted 18 lines · Hannes Frederic Sowa
Quoted 17 lines · John
Documentation/networking/bonding.txt +1
-1@@ -752,12 +752,22 @@ xmit_hash_policy protocol information to generate the hash. Uses XOR of hardware MAC addresses and IP addresses to - generate the hash. The formula is + generate the hash. The IPv4 formula is (((source IP XOR dest IP) AND 0xffff) XOR ( source MAC XOR destination MAC )) modulo slave countQuoted 14 lines
Documentation/networking/bonding.txt xmit_hash_policy · line 770
Quoted 10 lines
Documentation/networking/bonding.txt +10
-0+ The IPv6 forumla is + + iphash = + (source ip quad 2 XOR dest IP quad 2) XOR + (source ip quad 3 XOR dest IP quad 3) XOR + (source ip quad 4 XOR dest IP quad 4) + + ((iphash >> 16) XOR (iphash >> 8) XOR iphash) + modulo slave count +Wouldn't it be beneficial to include the ipv6 flow label in the hash calculation?
Hannes,
Quoted 8 lines
In all of the traffic I inspected I don't believe I saw a single flow label set. Even if it were set 100% of the time by Linux, any packets routed or bridged from another operating system wouldn't see any benefit. The current algorithm distributes the traffic very well, I don't believe adding the flow label would be beneficial even if it were set more frequently.
If you feel strongly about its inclusion, though, I am willing to reconsider.
It would definitely help to load balance tunnelled traffic over a bonded interface. But as I currently don't use such a setup, I don't have a strong opinion on that.
Greetings,
Hannes