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 CFE40106A for ; Mon, 16 Jan 2017 16:34:16 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 16 Jan 2017 07:34:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,239,1477983600"; d="scan'208";a="923115575" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 16 Jan 2017 07:34:14 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX102.ger.corp.intel.com ([169.254.2.230]) with mapi id 14.03.0248.002; Mon, 16 Jan 2017 15:34:13 +0000 From: "De Lara Guarch, Pablo" To: Jerin Jacob CC: "dev@dpdk.org" , "Marohn, Byron" , "Edupuganti, Saikrishna" Thread-Topic: [dpdk-dev] [PATCH v4 1/5] efd: new Elastic Flow Distributor library Thread-Index: AQHSbydTjsMFLSq5j0+u/BqBg7QaeaE6guoAgAC6duA= Date: Mon, 16 Jan 2017 15:34:13 +0000 Message-ID: References: <1484259360-198276-1-git-send-email-pablo.de.lara.guarch@intel.com> <1484481875-126335-1-git-send-email-pablo.de.lara.guarch@intel.com> <1484481875-126335-2-git-send-email-pablo.de.lara.guarch@intel.com> <20170116042547.GA6781@localhost.localdomain> In-Reply-To: <20170116042547.GA6781@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjAzMDQ5N2UtNjEyYi00ZTMwLWFiZDAtZDE2ZDRiMGQ5YTMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjFvcjVjbjR6ZkZDUXFldkxPQ2xnYXE4Z243MzRNcGQrWGc4YThlZk91Y2M9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 1/5] efd: new Elastic Flow Distributor library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:34:17 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Monday, January 16, 2017 4:26 AM > To: De Lara Guarch, Pablo > Cc: dev@dpdk.org; Marohn, Byron; Edupuganti, Saikrishna > Subject: Re: [dpdk-dev] [PATCH v4 1/5] efd: new Elastic Flow Distributor > library >=20 > On Sun, Jan 15, 2017 at 12:04:31PM +0000, Pablo de Lara wrote: > > Elastic Flow Distributor (EFD) is a distributor library that uses > > perfect hashing to determine a target/value for a given incoming flow k= ey. > > It has the following advantages: > > > > - First, because it uses perfect hashing, it does not store > > the key itself and hence lookup performance is not dependent > > on the key size. > > > > - Second, the target/value can be any arbitrary value hence > > the system designer and/or operator can better optimize service rates > > and inter-cluster network traffic locating. > > > > - Third, since the storage requirement is much smaller than a hash-base= d > > flow table (i.e. better fit for CPU cache), EFD can scale to > > millions of flow keys. > > Finally, with current optimized library implementation performance > > is fully scalable with number of CPU cores. > > > > Signed-off-by: Byron Marohn > > Signed-off-by: Pablo de Lara > > Signed-off-by: Saikrishna Edupuganti > > Acked-by: Christian Maciocco > > --- > > +#if (RTE_EFD_VALUE_NUM_BITS =3D=3D 8 || RTE_EFD_VALUE_NUM_BITS =3D=3D > 16 || \ > > + RTE_EFD_VALUE_NUM_BITS =3D=3D 24 || RTE_EFD_VALUE_NUM_BITS > =3D=3D 32) > > +#define EFD_LOAD_SI128(val) _mm_load_si128(val) > > +#else > > +#define EFD_LOAD_SI128(val) _mm_lddqu_si128(val) > > +#endif > > + > > +static inline efd_value_t > > +efd_lookup_internal(const struct efd_online_group_entry * const > group, > > + const uint32_t hash_val_a, const uint32_t hash_val_b, > > + enum rte_efd_compare_function cmp_fn) > > +{ > > + efd_value_t value =3D 0; > > + uint32_t i; > > + > > + switch (cmp_fn) { > > +#ifdef RTE_MACHINE_CPUFLAG_AVX2 > > + case RTE_HASH_COMPARE_AVX2: > > + > > + i =3D 0; > > + __m256i vhash_val_a =3D _mm256_set1_epi32(hash_val_a); > > + __m256i vhash_val_b =3D _mm256_set1_epi32(hash_val_b); > > + >=20 > Could you please abstract and move SIMD specific code to another file lik= e > other > libraries(example: lib_acl) to enable smooth integration with neon and > altivec > SIMD implementations in future. Sure, will modify it and send another version shortly. Thanks, Pablo >=20 > > + for (; i < RTE_EFD_VALUE_NUM_BITS; i +=3D 8) { > > + __m256i vhash_idx =3D > > + > _mm256_cvtepu16_epi32(EFD_LOAD_SI128( > > + (__m128i const *) &group- > >hash_idx[i])); > > + __m256i vlookup_table =3D > _mm256_cvtepu16_epi32( > > + EFD_LOAD_SI128((__m128i const *) > > + &group->lookup_table[i])); > > + __m256i vhash =3D > _mm256_add_epi32(vhash_val_a, > > + _mm256_mullo_epi32(vhash_idx, > vhash_val_b)); > > + __m256i vbucket_idx =3D _mm256_srli_epi32(vhash, > > + EFD_LOOKUPTBL_SHIFT); > > + __m256i vresult =3D > _mm256_srlv_epi32(vlookup_table, > > + vbucket_idx); > > + > > + value |=3D (_mm256_movemask_ps( > > + (__m256) _mm256_slli_epi32(vresult, 31)) > > + & ((1 << (RTE_EFD_VALUE_NUM_BITS - i)) - > 1)) << i; > > + } > > + break; > > +#endif