On 4 July 2017 at 21:55, De Lara Guarch, Pablo
[off-list ref] wrote:

quoted

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Tuesday, July 4, 2017 12:26 AM
To: Dumitrescu, Cristian <redacted>; De Lara Guarch,
Pablo [off-list ref]
Cc: dev@dpdk.org; Jianbo Liu <redacted>;
jerin.jacob@caviumnetworks.com; ashwin.sekhar@caviumnetworks.com
Subject: Re: [dpdk-dev] [PATCH] examples/ip_pipeline: use crc32 in hash
functions for arm64

04/07/2017 01:19, Dumitrescu, Cristian:

quoted

From: Thomas Monjalon [mailto:thomas@monjalon.net]

quoted

18/05/2017 11:09, Jianbo Liu:

quoted

Implement the same hash functions with crc32 on arm platform.

Signed-off-by: Jianbo Liu <redacted>
---
 examples/ip_pipeline/pipeline/hash_func.h       |   2 +
 examples/ip_pipeline/pipeline/hash_func_arm64.h | 245

++++++++++++++++++++++++

quoted

 2 files changed, 247 insertions(+)  create mode 100644
examples/ip_pipeline/pipeline/hash_func_arm64.h

I don't understand why this code is in an example.
We have some CRC code in librte_hash, librte_net and ip_pipeline.
Cristian, Jianbo,
does it make sense to move these functions somewhere else?

I think example apps are a great way to propose new hash functions.
IMO we should encourage the definition/exploration of new hash

functions in our example apps.

quoted

These functions are examples of how fast hash functions can be built

using special CPU instructions.

quoted

They have much better performance than e.g. jhash, but their
properties are largely unknown, as no rigorous study on their
properties (such as uniform distribution) has been conducted. I have
seen them providing good performance  for the data set I have been

using, but I have no extensive data to support their maturity level.

quoted

If somebody is willing to invest the effort in proving them, I would
be more than happy to see them moved to a library like librte_hash.
Pablo as maintainer has the choice (I think it is not the first time
we discuss bout these hash funcs :) )

As mentioned in one of our deprecation notices, I am actively working
(not ready for 17.8 unfortunately) to add a key mask parameter to these

functions, so more work on these hash functions is likely to take place.

OK thanks for the explanation.
I still think we do not need to prove hash for integrating them.
I would be interested to read Pablo's opinion.

If these functions are used as hash functions, I would place them in rte_hash.

The case where we placed the CRC function in librte_net was because that
was not used as a hash function, so it made sense to me placing it there,
but in this case, it looks like it is, so I think rte_hash is a valid place
(although someone would need to integrate it with the existing CRC hash function in that library).

I think Cristian explanation justified using the special hash functions here.
And they may have better performance than the standard functions in the library.

Thanks!
Jianbo