From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Richardson,
Bruce" <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [PATCH] hash: update jhash function with the latest available
Date: Fri, 17 Apr 2015 16:03:44 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D89727289E30@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20150416140115.GA10552@bricha3-MOBL3>
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, April 16, 2015 3:01 PM
> To: De Lara Guarch, Pablo
> Cc: dev-VfR2kkLFssw@public.gmane.org
> Subject: Re: [dpdk-dev] [PATCH] hash: update jhash function with the latest
> available
>
> On Thu, Apr 16, 2015 at 02:26:59PM +0100, Pablo de Lara wrote:
> > 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.
> >
> > Check out: http://burtleburtle.net/bob/c/lookup3.c
> >
> > This patch integrates that code in the rte_jhash library,
> > adding also a new function rte_jhash_word2,
> > that returns two different hash values, for a single key.
> >
>
> Should the addition of the new functionality not be a separate patch from
> the
> update to the existing code?
True, actually, I miss one extra function (2 in total).
> Also, do the new functions return the exact same values as the previous
> versions,
> just faster?
The new functions return different values from the previous version
AND faster (some cases, MUCH faster)
[...]
> > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > + case 12:
> > + c += k[2]; b += k[1]; a += k[0]; break;
> > + case 11:
> > + c += k[2]&0xffffff; b += k[1]; a += k[0]; break;
> > + case 10:
> > + c += k[2]&0xffff; b += k[1]; a += k[0]; break;
> > + case 9:
> > + c += k[2]&0xff; b += k[1]; a += k[0]; break;
> > + case 8:
> > + b += k[1]; a += k[0]; break;
> > + case 7:
> > + b += k[1]&0xffffff; a += k[0]; break;
> > + case 6:
> > + b += k[1]&0xffff; a += k[0]; break;
> > + case 5:
> > + b += k[1]&0xff; a += k[0]; break;
> > + case 4:
> > + a += k[0]; break;
> > + case 3:
> > + a += k[0]&0xffffff; break;
> > + case 2:
> > + a += k[0]&0xffff; break;
> > + case 1:
> > + a += k[0]&0xff; break;
> > +#else
> > + case 12:
> > + c += k[2]; b += k[1]; a += k[0]; break;
> > + case 11:
> > + c += k[2]&0xffffff00; b += k[1]; a += k[0]; break;
> > + case 10:
> > + c += k[2]&0xffff0000; b += k[1]; a += k[0]; break;
> > + case 9:
> > + c += k[2]&0xff000000; b += k[1]; a += k[0]; break;
> > + case 8:
> > + b += k[1]; a += k[0]; break;
> > + case 7:
> > + b += k[1]&0xffffff00; a += k[0]; break;
> > + case 6:
> > + b += k[1]&0xffff0000; a += k[0]; break;
> > + case 5:
> > + b += k[1]&0xff000000; a += k[0]; break;
> > + case 4:
> > + a += k[0]; break;
> > + case 3:
> > + a += k[0]&0xffffff00; break;
> > + case 2:
> > + a += k[0]&0xffff0000; break;
> > + case 1:
> > + a += k[0]&0xff000000; break;
> > +#endif
>
> Only the constants seem different in this block. Can we get rid of the
> #ifdefs using rte_XX_to_cpu() calls instead?
Will add that in next version.
>
> > + /* zero length strings require no mixing */
> > + case 0:
> > + return c;
> > + };
> > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > + } else if ((u.i & 0x1) == 0) {
> > + /* read 16-bit chunks */
> > + const uint16_t *k = (const uint16_t *)key;
> > + const uint8_t *k8;
> > +
> > + /* all but last block: aligned reads and different mixing */
> > + while (length > 12) {
> > + a += k[0] + (((uint32_t)k[1])<<16);
> > + b += k[2] + (((uint32_t)k[3])<<16);
> > + c += k[4] + (((uint32_t)k[5])<<16);
> > +
> > + __rte_jhash_mix(a, b, c);
> > +
> > + k += 6;
> > + length -= 12;
> > + }
> > +
> > + /* handle the last (probably partial) block */
> > + k8 = (const uint8_t *)k;
> > + switch (length) {
> > + case 12:
> > + c += k[4]+(((uint32_t)k[5])<<16);
> > + b += k[2]+(((uint32_t)k[3])<<16);
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 11:
> > + /* fall through */
> > + c += ((uint32_t)k8[10])<<16;
> > + case 10:
> > + c += k[4];
> > + b += k[2]+(((uint32_t)k[3])<<16);
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 9:
> > + /* fall through */
> > + c += k8[8];
> > + case 8:
> > + b += k[2]+(((uint32_t)k[3])<<16);
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 7:
> > + /* fall through */
> > + b += ((uint32_t)k8[6])<<16;
> > + case 6:
> > + b += k[2];
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 5:
> > + /* fall through */
> > + b += k8[4];
> > + case 4:
> > + a += k[0]+(((uint32_t)k[1])<<16);
> > + break;
> > + case 3:
> > + /* fall through */
> > + a += ((uint32_t)k8[2])<<16;
> > + case 2:
> > + a += k[0];
> > + break;
> > + case 1:
> > + a += k8[0];
> > + break;
> > + case 0:
> > + /* zero length requires no mixing */
> > + return c;
> > + }
> > +#endif
>
> No else block for this ifdef?
According to the code, for big endian, it only covers 4-byte alignment and rest of cases.
>
> > + } else {
> > + const uint8_t *k = (const uint8_t *)key;
> > +
> > + /* all but the last block: affect some 32 bits of (a, b, c) */
> > + while (length > 12) {
> > +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> > + a += k[0];
> > + a += ((uint32_t)k[1])<<8;
> > + a += ((uint32_t)k[2])<<16;
> > + a += ((uint32_t)k[3])<<24;
> > + b += k[4];
> > + b += ((uint32_t)k[5])<<8;
> > + b += ((uint32_t)k[6])<<16;
> > + b += ((uint32_t)k[7])<<24;
> > + c += k[8];
> > + c += ((uint32_t)k[9])<<8;
> > + c += ((uint32_t)k[10])<<16;
> > + c += ((uint32_t)k[11])<<24;
> > +#else
> > + a += ((uint32_t)k[0])<<24;
> > + a += ((uint32_t)k[1])<<16;
> > + a += ((uint32_t)k[2])<<8;
> > + a += ((uint32_t)k[3]);
> > + b += ((uint32_t)k[4])<<24;
> > + b += ((uint32_t)k[5])<<16;
> > + b += ((uint32_t)k[6])<<8;
> > + b += ((uint32_t)k[7]);
> > + c += ((uint32_t)k[8])<<32;
> > + c += ((uint32_t)k[9])<<16;
> > + c += ((uint32_t)k[10])<<8;
> > + c += ((uint32_t)k[11]);
> > +#endif
>
> Maybe find a better way to shorten/remove this #ifdef also. E.g. shorter
> ifdef defining macros for the different shift amounts, 0, 8, 16, 24.
Agree. Will change that in v2.
[...]
Thanks for the comments. I will send a v2 soon.
next prev parent reply other threads:[~2015-04-17 16:03 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 13:26 [PATCH] hash: update jhash function with the latest available Pablo de Lara
[not found] ` <1429190819-27402-1-git-send-email-pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-04-16 14:01 ` Bruce Richardson
2015-04-17 16:03 ` De Lara Guarch, Pablo [this message]
2015-04-24 11:23 ` [PATCH v2 0/6] update jhash function Pablo de Lara
[not found] ` <1429874587-17939-1-git-send-email-pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-04-24 11:23 ` [PATCH v2 1/6] test/hash: move hash function perf tests to separate file Pablo de Lara
2015-04-24 11:23 ` [PATCH v2 2/6] test/hash: improve accuracy on cycle measurements Pablo de Lara
2015-04-24 11:23 ` [PATCH v2 3/6] hash: update jhash function with the latest available Pablo de Lara
2015-04-24 11:23 ` [PATCH v2 4/6] hash: add two new functions to jhash library Pablo de Lara
2015-04-24 11:23 ` [PATCH v2 5/6] hash: remove duplicated code Pablo de Lara
2015-04-24 11:23 ` [PATCH v2 6/6] hash: rename rte_jhash2 to rte_jhash_32b Pablo de Lara
2015-05-05 14:43 ` [PATCH v3 0/6] update jhash function Pablo de Lara
[not found] ` <1430837034-21031-1-git-send-email-pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-05-05 14:43 ` [PATCH v3 1/6] test/hash: move hash function perf tests to separate file Pablo de Lara
2015-05-05 14:43 ` [PATCH v3 2/6] test/hash: improve accuracy on cycle measurements Pablo de Lara
2015-05-05 14:43 ` [PATCH v3 3/6] hash: update jhash function with the latest available Pablo de Lara
[not found] ` <1430837034-21031-4-git-send-email-pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-05-06 0:35 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB97725821424ED1-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-06 9:36 ` De Lara Guarch, Pablo
[not found] ` <E115CCD9D858EF4F90C690B0DCB4D8972729A7B7-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-06 16:11 ` Ananyev, Konstantin
2015-05-07 11:11 ` Ananyev, Konstantin
2015-05-05 14:43 ` [PATCH v3 4/6] hash: add two new functions to jhash library Pablo de Lara
2015-05-05 14:43 ` [PATCH v3 5/6] hash: remove duplicated code Pablo de Lara
2015-05-05 14:43 ` [PATCH v3 6/6] hash: rename rte_jhash2 to rte_jhash_32b Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 0/6] update jhash function Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 1/6] test/hash: move hash function perf tests to separate file Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 2/6] test/hash: improve accuracy on cycle measurements Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 3/6] hash: update jhash function with the latest available Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 4/6] hash: add two new functions to jhash library Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 5/6] hash: remove duplicated code Pablo de Lara
2015-05-12 11:02 ` [PATCH v4 6/6] hash: rename rte_jhash2 to rte_jhash_32b Pablo de Lara
2015-05-12 15:33 ` [PATCH v4 0/6] update jhash function Neil Horman
2015-05-13 13:52 ` De Lara Guarch, Pablo
2015-05-13 14:20 ` Neil Horman
2015-05-18 16:14 ` Bruce Richardson
2015-05-22 10:16 ` [PATCH v5 00/10] " Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 01/10] test/hash: move hash function perf tests to separate file Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 02/10] test/hash: improve accuracy on cycle measurements Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 03/10] test/hash: update key size range and initial values for testing Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 04/10] test/hash: change order of loops in hash function tests Pablo de Lara
2015-06-10 11:05 ` Bruce Richardson
2015-05-22 10:16 ` [PATCH v5 05/10] test/hash: add new functional tests for hash functions Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 06/10] hash: update jhash function with the latest available Pablo de Lara
2015-06-10 11:07 ` Bruce Richardson
2015-05-22 10:16 ` [PATCH v5 07/10] hash: add two new functions to jhash library Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 08/10] hash: remove duplicated code Pablo de Lara
2015-05-22 10:16 ` [PATCH v5 09/10] hash: rename rte_jhash2 to rte_jhash_32b Pablo de Lara
2015-06-10 11:09 ` Bruce Richardson
2015-05-22 10:16 ` [PATCH v5 10/10] test/hash: verify rte_jhash_1word/2words/3words Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 00/10] update jhash function Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 01/10] test/hash: move hash function perf tests to separate file Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 02/10] test/hash: improve accuracy on cycle measurements Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 03/10] test/hash: update key size range and initial values for testing Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 04/10] test/hash: change order of loops in hash function tests Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 05/10] test/hash: add new functional tests for hash functions Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 06/10] hash: update jhash function with the latest available Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 07/10] hash: add two new functions to jhash library Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 08/10] hash: remove duplicated code Pablo de Lara
2015-06-16 9:33 ` Thomas Monjalon
2015-06-16 10:31 ` De Lara Guarch, Pablo
2015-06-16 13:08 ` Thomas Monjalon
2015-06-10 15:25 ` [PATCH v6 09/10] hash: rename rte_jhash2 to rte_jhash_32b Pablo de Lara
2015-06-10 15:25 ` [PATCH v6 10/10] test/hash: verify rte_jhash_1word/2words/3words Pablo de Lara
2015-06-12 10:37 ` [PATCH v6 00/10] update jhash function Bruce Richardson
2015-06-16 10:22 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E115CCD9D858EF4F90C690B0DCB4D89727289E30@IRSMSX108.ger.corp.intel.com \
--to=pablo.de.lara.guarch-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.