Message ID | 26860.1305680256@death |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
On 5/17/2011 5:57 PM, Jay Vosburgh wrote: > It would also be useful to include an update bonding.txt to > describe the IPv6 algorithm; I'd word that something like the following > (filling in the missing bits) for the layer3+4 section, applying similar > changes to the layer2+3 section: > Thanks for the feedback. This is a good point, I will take care of this too. > > Style nit: I don't believe the outermost parentheses are > necessary. Since you do this twice, perhaps make a small inline > function to handle it. > The outer parenthesis are definitely not required; I will remove those. I did speak with Andy Gospodarek about breaking out all of the hashing methods into separate functions. I'll give that some more thought. > > For fragmented datagrams, the above will keep all fragments > together, which is good, but are there other header types that should be > skipped over to find the UDP/TCP header for hashing purposes? > This is a good question, and I'm not too sure how to proceed. There are other headers that can sit between the IPv6 header and the upper protocol payload (hop-by-hop, destination options, routing, fragment, AH, ESP, mobility), and the current implementation would handle any of those being present by ignoring the upper protocol data and only hashing on the source and destination IPv6 addresses. I was trying to avoid loops but one would be required to process the headers. Additionally there would need to be code (or a table) that knows how to process each header type, and that may require maintenance any time a new header option become popular. It's definitely do-able, though. Any thoughts? John -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- net-next-2.6/Documentation/networking/bonding.txt 2011-05-09 17:53:03.000000000 -0700 +++ net-next-2.6/Documentation/networking/bonding.txt.new 2011-05-17 17:53:46.000000000 -0700 @@ -733,21 +733,26 @@ 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 + The formula for unfragmented IPv6 TCP and UDP packets is + + [ your formula here ] + + For fragmented TCP or UDP packets and all other IP or IPv6 protocol traffic, the source and destination port - information is omitted. For non-IP traffic, the + information is omitted. For non-IP/IPv6 traffic, the formula is the same as for the layer2 transmit hash policy. - This policy is intended to mimic the behavior of - certain switches, notably Cisco switches with PFC2 as - well as some Foundry and IBM products. + The IPv4 behavior is intended to mimic the behavior of + certain switches, notably Cisco switches with PFC2 as well + as some Foundry and IBM products. The IPv6 behavior was + determined by [ your rationale here ]. This algorithm is not fully 802.3ad compliant. A single TCP or UDP conversation containing both