From mboxrd@z Thu Jan  1 00:00:00 1970
From: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Subject: Re: [PATCH 0/2] rewritten rte_hash_crc() call
Date: Fri, 14 Nov 2014 06:33:27 -0500
Message-ID: <20141114113327.GA19147@hmsreliant.think-freely.org>
References: <1409724351-23786-1-git-send-email-e_zhumabekov@sts.kz>
 <2916837.QJI9btJm0N@xps13>
 <20141114005211.GC14230@localhost.localdomain>
 <5465AC00.1070602@sts.kz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: dev-VfR2kkLFssw@public.gmane.org
To: Yerden Zhumabekov <e_zhumabekov-8EHiFRVJVgQ@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <5465AC00.1070602-8EHiFRVJVgQ@public.gmane.org>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev-VfR2kkLFssw@public.gmane.org>
List-Help: <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=subscribe>
Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org
Sender: "dev" <dev-bounces-VfR2kkLFssw@public.gmane.org>

On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
> 14.11.2014 6:52, Neil Horman =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > On Thu, Nov 13, 2014 at 06:33:14PM +0100, Thomas Monjalon wrote:
> >> Any comment on these patches?
> >>
> >> 2014-09-03 12:05, Yerden Zhumabekov:
> >>> As SSE4.2 provides CRC32 instructions with either 32 and 64 bit ope=
rands,
> >>> new rte_hash_crc_8byte() call assisted with _mm_crc32_u64 intrinsic=
 may be
> >>> useful.
> >>>
> >>> ... <skipped> ...
> >>
> > Yeah, sorry I didn't speak up earlier.  I meant to ask if the __mm_cr=
c_u64
> > intrinsic will emit software emulated versions of the sse4.2 instruct=
ion in the
> > event that you build with a config that doesn't enable sse4.2?  If no=
t, then
> > NAK, since this will break on the default build.  In that event you'l=
l have to
> > modify the new function to do a runtime cpu flags check to either jus=
t use the
> > instruction inlined with some asm, or emulate it in software.
>=20
> Hello,
>=20
> A quick grep on dpdk source shows that rte_hash_crc() is used in
> librte_hash in following context:
>=20
> In rte_hash.c:
> /* Hash function used if none is specified */
> #ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> #include <rte_hash_crc.h>
> #define DEFAULT_HASH_FUNC       rte_hash_crc
> #else
> #include <rte_jhash.h>
> #define DEFAULT_HASH_FUNC       rte_jhash
> #endif
>=20
> In rte_fbk_hash.h
> #ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> #include <rte_hash_crc.h>
> /** Default four-byte key hash function if none is specified. */
> #define RTE_FBK_HASH_FUNC_DEFAULT=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=
=B7rte_hash_crc_4byte
> #else
> #include <rte_jhash.h>
> #define RTE_FBK_HASH_FUNC_DEFAULT=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=B7=C2=
=B7rte_jhash_1word
> #endif
> #endif
>=20
>=20
> I guess it covers the cpu flags check you're talking about.
>=20

Not really.  That covers the case of applications selecting the hash func=
tion
using the DEFUALT_HASH_FUNC macro, but doesn't nothing for applications u=
sing
the function directly.  Test_hash_perf is an example  of this, and ostens=
ibly
because of the behavior without SSE4.2 it defines these huge test tables =
twice
based on the availability of SSE4.2.  It would be better if we could allo=
w
applications to use rte_hash_crc regardless, and make the code it uses at=
 run
time configurable.
Neil

> --=20
> Sincerely,
>=20
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
>=20
>=20
>=20