Re: [PATCH net-next] bonding: change xmit hash functions to use skb_flow_dissect

[Eric Dumazet <eric.dumazet@gmail.com>]

On Sat, 2013-04-20 at 08:12 +0200, Nikolay Aleksandrov wrote:
> On 20/04/13 02:57, Eric Dumazet wrote:
> > On Sat, 2013-04-20 at 01:02 +0200, Nikolay Aleksandrov wrote:
> >> As Eric suggested earlier, bonding hash functions can make good use of
> >> skb_flow_dissect. The old use cases should have the same results, but
> >> there should be good improvement for tunnel users mostly over IPv4.
> >> I've kept the IPv6 address hashing algorithm and thus if a tunnel is
> >> used over IPv6 then the addresses will be the same but there still can be
> >> improvement because the ports from skb_flow_dissect will be mixed in.
> >> This also fixes a problem with protocol == ETH_P_8021Q load balancing.
> > 
> > Are you sure ? we don't look at skb->vlan_tci
> We don't need to look at vlan_tci, the problem was that when we had a
> packet with skb->protocol == htons(ETH_P_8021Q) before we wouldn't use
> the network headers inside and always fall back to L2 hash which in most
> cases is weaker.
> When using skb_flow_dissect we avoid that because of the header extraction

What I meant to say is : Most devices used in a bonding setup use
hardware assist vlan tagging, so I doubt it was a real concern.

The real gain is tunneling decapsulation for free.

> > Not sure its worth doing this test, as IPv6 addresses are mixed already.
> > 
> > So just
> > 
> > hash = (__force u32)flow.ports ^
> >        (__force u32)keys.dst ^
> >        (__force u32)keys.src;
> > 
> > hash ^= (hash >> 16);
> > hash ^= (hash >> 8);
> > 
> > return hash % count;
> > 
> Hm, I actually wanted to keep the old hash because it mixes
> different parts of the address so to produce the same results as the
> original version.
> I think that ipv6_addr_hash mixes the whole IPv6 address, as the old
> bond version mixes only bits 32-128.
> I'd be happy to update it to this version if the bonding maintainers
> agree to it, then we'll be able to remove some ugliness :-)
> 

My original idea was to re-use skb_flow_dissect() to keep a more simple
bonding hash implementation, yet using all bits.

The only difference between l23 and l34 is that l23 wont use flow.ports,
but the hash will be the same :

hash = (__force u32)keys.dst ^ (__force u32)keys.src;
hash ^= (hash >> 16);
hash ^= (hash >> 8);
return hash % count;
 

using ntohl() is really not needed here, just xor32 all the different
parts (or xor64 as in the IPv6 hash function), then the final xor16/xor8
has the property that hash % count is well spread.

Sure, the hash is not the original one, but its not in a RFC, is it ?

Also keep in mind to change documentation.

BTW, I was waiting this patch was first pulled on net-next to do this
myself.
 
commit 4394542ca4ec9f28c3c8405063d200b1e7c347d7
bonding: fix l23 and l34 load balancing in forwarding path

Your patch based on current net-next makes things more complex for
David. I do not feel this is urgent stuff, is it ?