> -----Original Message----- > From: Ananyev, Konstantin > Sent: Wednesday, May 06, 2015 5:11 PM > To: De Lara Guarch, Pablo; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v3 3/6] hash: update jhash function with the > latest available > > Hi Pablo, > > > -----Original Message----- > > From: De Lara Guarch, Pablo > > Sent: Wednesday, May 06, 2015 10:36 AM > > To: Ananyev, Konstantin; dev at dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v3 3/6] hash: update jhash function with the > > latest available > > > > Hi Konstantin, > > > > > -----Original Message----- > > > From: Ananyev, Konstantin > > > Sent: Wednesday, May 06, 2015 1:36 AM > > > To: De Lara Guarch, Pablo; dev at dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH v3 3/6] hash: update jhash function with > > > the > > > latest available > > > > > > > > > Hi Pablo, > > > > > > > -----Original Message----- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > > > > Sent: Tuesday, May 05, 2015 3:44 PM > > > > To: dev at dpdk.org > > > > Subject: [dpdk-dev] [PATCH v3 3/6] hash: update jhash function with the > > > latest available > > > > > > > > Jenkins hash function was developed originally in 1996, > > > > and was integrated in first versions of DPDK. > > > > The function has been improved in 2006, > > > > achieving up to 60% better performance, compared to the original one. > > > > > > > > This patch integrates that code into the rte_jhash library. > > > > > > > > Signed-off-by: Pablo de Lara <pablo.de.lara.guarch at intel.com> > > > > --- > > > > lib/librte_hash/rte_jhash.h | 261 > > > +++++++++++++++++++++++++++++++------------ > > > > 1 files changed, 188 insertions(+), 73 deletions(-) > > > > > > > > diff --git a/lib/librte_hash/rte_jhash.h b/lib/librte_hash/rte_jhash.h > > > > index a4bf5a1..0e96b7c 100644 > > > > --- a/lib/librte_hash/rte_jhash.h > > > > +++ b/lib/librte_hash/rte_jhash.h > > > > @@ -1,7 +1,7 @@ > > > > /*- > > > > * BSD LICENSE > > > > * > > > > - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. > > > > + * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. > > > > * All rights reserved. > > > > * > > > > * Redistribution and use in source and binary forms, with or without > > > > @@ -45,38 +45,68 @@ extern "C" { > > > > #endif > > > > > > > > #include <stdint.h> > > > > +#include <string.h> > > > > +#include <rte_byteorder.h> > > > > > > > > /* jhash.h: Jenkins hash support. > > > > * > > > > - * Copyright (C) 1996 Bob Jenkins (bob_jenkins at burtleburtle.net) > > > > + * Copyright (C) 2006 Bob Jenkins (bob_jenkins at burtleburtle.net) > > > > * > > > > * http://burtleburtle.net/bob/hash/ > > > > * > > > > * These are the credits from Bob's sources: > > > > * > > > > - * lookup2.c, by Bob Jenkins, December 1996, Public Domain. > > > > - * hash(), hash2(), hash3, and mix() are externally useful functions. > > > > - * Routines to test the hash are included if SELF_TEST is defined. > > > > - * You can use this free for any purpose. It has no warranty. > > > > + * lookup3.c, by Bob Jenkins, May 2006, Public Domain. > > > > + * > > > > + * These are functions for producing 32-bit hashes for hash table > > > > lookup. > > > > + * hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and > > > > final() > > > > + * are externally useful functions. Routines to test the hash are > > > > included > > > > + * if SELF_TEST is defined. You can use this free for any purpose. > > > > It's in > > > > + * the public domain. It has no warranty. > > > > * > > > > * $FreeBSD$ > > > > */ > > > > > > > > +#define rot(x, k) (((x) << (k)) | ((x) >> (32-(k)))) > > > > + > > > > /** @internal Internal function. NOTE: Arguments are modified. */ > > > > #define __rte_jhash_mix(a, b, c) do { \ > > > > - a -= b; a -= c; a ^= (c>>13); \ > > > > - b -= c; b -= a; b ^= (a<<8); \ > > > > - c -= a; c -= b; c ^= (b>>13); \ > > > > - a -= b; a -= c; a ^= (c>>12); \ > > > > - b -= c; b -= a; b ^= (a<<16); \ > > > > - c -= a; c -= b; c ^= (b>>5); \ > > > > - a -= b; a -= c; a ^= (c>>3); \ > > > > - b -= c; b -= a; b ^= (a<<10); \ > > > > - c -= a; c -= b; c ^= (b>>15); \ > > > > + a -= c; a ^= rot(c, 4); c += b; \ > > > > + b -= a; b ^= rot(a, 6); a += c; \ > > > > + c -= b; c ^= rot(b, 8); b += a; \ > > > > + a -= c; a ^= rot(c, 16); c += b; \ > > > > + b -= a; b ^= rot(a, 19); a += c; \ > > > > + c -= b; c ^= rot(b, 4); b += a; \ > > > > +} while (0) > > > > + > > > > +#define __rte_jhash_final(a, b, c) do { \ > > > > + c ^= b; c -= rot(b, 14); \ > > > > + a ^= c; a -= rot(c, 11); \ > > > > + b ^= a; b -= rot(a, 25); \ > > > > + c ^= b; c -= rot(b, 16); \ > > > > + a ^= c; a -= rot(c, 4); \ > > > > + b ^= a; b -= rot(a, 14); \ > > > > + c ^= b; c -= rot(b, 24); \ > > > > } while (0) > > > > > > > > /** The golden ratio: an arbitrary value. */ > > > > -#define RTE_JHASH_GOLDEN_RATIO 0x9e3779b9 > > > > +#define RTE_JHASH_GOLDEN_RATIO 0xdeadbeef > > > > + > > > > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN > > > > +#define RTE_JHASH_BYTE0_SHIFT 0 > > > > +#define RTE_JHASH_BYTE1_SHIFT 8 > > > > +#define RTE_JHASH_BYTE2_SHIFT 16 > > > > +#define RTE_JHASH_BYTE3_SHIFT 24 > > > > +#else > > > > +#define RTE_JHASH_BYTE0_SHIFT 24 > > > > +#define RTE_JHASH_BYTE1_SHIFT 16 > > > > +#define RTE_JHASH_BYTE2_SHIFT 8 > > > > +#define RTE_JHASH_BYTE3_SHIFT 0 > > > > +#endif > > > > + > > > > +#define LOWER8b_MASK rte_le_to_cpu_32(0xff) > > > > +#define LOWER16b_MASK rte_le_to_cpu_32(0xffff) > > > > +#define LOWER24b_MASK rte_le_to_cpu_32(0xffffff) > > > > > > > > /** > > > > * The most generic version, hashes an arbitrary sequence > > > > @@ -95,42 +125,119 @@ extern "C" { > > > > static inline uint32_t > > > > rte_jhash(const void *key, uint32_t length, uint32_t initval) > > > > { > > > > - uint32_t a, b, c, len; > > > > - const uint8_t *k = (const uint8_t *)key; > > > > - const uint32_t *k32 = (const uint32_t *)key; > > > > + uint32_t a, b, c; > > > > + union { > > > > + const void *ptr; > > > > + size_t i; > > > > + } u; > > > > > > > > - len = length; > > > > - a = b = RTE_JHASH_GOLDEN_RATIO; > > > > - c = initval; > > > > + /* Set up the internal state */ > > > > + a = b = c = RTE_JHASH_GOLDEN_RATIO + ((uint32_t)length) + > > > > initval; > > > > > > > > - while (len >= 12) { > > > > - a += k32[0]; > > > > - b += k32[1]; > > > > - c += k32[2]; > > > > + u.ptr = key; > > > > > > > > - __rte_jhash_mix(a,b,c); > > > > + /* Check key alignment. For x86 architecture, first case is > > > > always > > > optimal */ > > > > + if (!strcmp(RTE_ARCH,"x86_64") || !strcmp(RTE_ARCH,"i686") || > > > > (u.i > > > & 0x3) == 0) { > > > > > > Wonder why strcmp(), why not something like: 'if defined(RTE_ARCH_I686) > > > || defined(RTE_ARCH_X86_64)' as in all other places? > > > Another question what would be in case of RTE_ARCH="x86_x32"? > > > Konstantin > > > > Functionally is the same and using this method, I can integrate all > > conditions in one line, so it takes less code. > > I also checked the assembly code, and the compiler removes the check if it > > is Intel architecture, so performance remains the same. > > Well, yes I think most modern compilers treat strcmp() as a builtin > function and are able to optimise these strcmp() calls off for that > case. > But we probably can't guarantee that it would always be the case for all > different compiler/libc combinations. > Again, by some reason user might need to use ' -fno-builtin' flag while > building his stuff. > So I would use pre-processor macros here, it is more predictable. > Again, that way it is consistent with other places. > > Actually I wonder do you really need such sort of diversity for > aligned/non-aligned case? > Wonder wouldn't something like that work for you: > > #infdef RTE_ARCH_X86 > const uint32_t *k = (uint32_t *)((uintptr_t)key & (uintptr_t)~3); > const uint32_t s = ((uintptr_t)key & 3) * CHAR_BIT; > #else /*X86*/ > const uint32_t *k = key; > const uint32_t s = 0; > #endif > > while (len > 12) { > a += k[0] >> s | (uint64_t)k[1] << (32 - s); > b += k[1] >> s | (uint64_t)k[2] << (32 - s); > c += k[2] >> s | (uint64_t)k[3] << (32 - s); > k += 3; > length -= 12; > } > > switch (length) { > case 12: > a += k[0] >> s | (uint64_t)k[1] << (32 - s); > b += k[1] >> s | (uint64_t)k[2] << (32 - s); > c += k[2] >> s | (uint64_t)k[3] << (32 - s); > break; > case 11: > a += k[0] >> s | (uint64_t)k[1] << (32 - s); > b += k[1] >> s | (uint64_t)k[2] << (32 - s); > c += (k[2] >> s | (uint64_t)k[3] << (32 - s)) & & LOWER24b_MASK; > break; > ... > case 1: > a += (k[0] >> s | (uint64_t)k[1] << (32 - s)) & LOWER8b_MASK; > break; > ... > > In that way, even for non-aligned you don't need do 4B reads. > For x86, compiler would do it's optimisation work and strip off '>> s | > (uint64_t)k[..] << (32 - s);'. >
Actually, as Sergio pointed out, that approach might penalise non-x86 4B aligned case. So probably, a special path for s== 0 is still needed, i.e: if (s==0) {...; a += k[0]; ...} else {...; a += k[0] >> s | (uint64_t)k[1] << (32 - s);...} Konstantin > > > > Re x86_x32, you are right, probably I need to include it. Although, I just > > realized that it is not used in any other place. > > Wonder if we should include it somewhere else? E.g. rte_hash_crc.h > > Yep, that's true we are not doing it for hash_crc also... > Would probably good to have some sort of ' RTE_ARCH_X86' - that would be > defined for all x86 targets and use it whenever applicable. > But I suppose, that's a subject for another patch. > > Konstantin >