On Fri, 6 Jun 2014 09:07:23 +0000 "Doherty, Declan" <declan.doherty at intel.com> wrote:
> > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > Sent: Thursday, June 5, 2014 4:16 PM > > To: Doherty, Declan > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] Link Bonding Library > > > > On Wed, 4 Jun 2014 16:18:02 +0100 > > declan.doherty at intel.com wrote: > > > > > From: Declan Doherty <declan.doherty at intel.com> > > > > > > - Broadcast TX burst broadcast bug fix > > > - Add/remove slave behavior fix > > > - Checkpatch fixes > > > > > > Signed-off-by: Declan Doherty <declan.doherty at intel.com> > > > > There are some pretty weak hash functions in there. > > > > What about using: > > ..... > > Hi Stephen, > > I suppose the naming of these as hash functions is probably misleading, the > aim is not to create a unique hash for each flow with minimal collisions but > to help balance traffic flows across the slaves of the bonded device, and as > we are doing a modulus calculation based on the number of slaves attached, > which I believe will typically be in the 2-4 range, I'm not sure that a > stronger hashing function will give a better balance of flows across the > slaves. For example in the Linux kernel implementation of the link bonding > driver the mac hashing only uses the last byte of src & dst mac addresses to > calculate it's eth hash. > > /* L2 hash helper */ > static inline u32 bond_eth_hash(struct sk_buff *skb) > { > struct ethhdr *data = (struct ethhdr *)skb->data; > > if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto)) > return data->h_dest[5] ^ data->h_source[5]; > > return 0; > } > > I'll investigate and see if a stronger hashing function will result in a > better balancing of flows. > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > The ether hash is very quick using multplicative hash on 64 bit value.
