[dpdk-dev] [PATCH v3 3/6] hash: update jhash function with the latest available

Ananyev, Konstantin konstantin.ananyev at intel.com
Thu May 7 13:11:08 CEST 2015



> -----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
> 



More information about the dev mailing list