From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 661885323 for ; Fri, 6 Jun 2014 11:07:13 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 06 Jun 2014 02:02:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,987,1392192000"; d="scan'208";a="523771913" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 06 Jun 2014 02:07:24 -0700 Received: from irsmsx106.ger.corp.intel.com (163.33.3.31) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Jun 2014 10:07:23 +0100 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.245]) by IRSMSX106.ger.corp.intel.com ([169.254.8.14]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 10:07:23 +0100 From: "Doherty, Declan" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 1/4] Link Bonding Library Thread-Index: AQHPgNEoU1HH+gm1tUect9Bn8a8myZtjwejQ Date: Fri, 6 Jun 2014 09:07:23 +0000 Message-ID: <345C63BAECC1AD42A2EC8C63AFFC3ADC13D3737A@IRSMSX101.ger.corp.intel.com> References: <20140605081557.42a797e8@nehalam.linuxnetplumber.net> In-Reply-To: <20140605081557.42a797e8@nehalam.linuxnetplumber.net> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2 1/4] Link Bonding Library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:07:14 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Thursday, June 5, 2014 4:16 PM > To: Doherty, Declan > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/4] Link Bonding Library > = > On Wed, 4 Jun 2014 16:18:02 +0100 > declan.doherty@intel.com wrote: > = > > From: Declan Doherty > > > > - Broadcast TX burst broadcast bug fix > > - Add/remove slave behavior fix > > - Checkpatch fixes > > > > Signed-off-by: Declan Doherty > = > 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 b= ut to help balance traffic flows across the slaves of the bonded device, a= nd as we are doing a modulus calculation based on the number of slaves atta= ched, 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 =3D (struct ethhdr *)skb->data; if (skb_headlen(skb) >=3D 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 be= tter 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 s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies.