* [dpdk-dev] DPDK hash function related question
@ 2015-09-21 22:34 Yeddula, Avinash
2015-09-22 10:05 ` Dumitrescu, Cristian
0 siblings, 1 reply; 7+ messages in thread
From: Yeddula, Avinash @ 2015-09-21 22:34 UTC (permalink / raw)
To: dev, Bly, Mike
Hello All,
I'm DPDK extensible bucket hash in the rte_table library of packet framework. My question is related to the actual hash function that computes the hash signature.
All the available examples have initialized it to test_hash. I do not see any hash function available in rte_table library , that computes the actual signature
struct rte_table_hash_ext_params hash_table_params = {
.key_size = TABLE_ENTRY_KEY_SIZE,
.n_keys = TABLE_MAX_SIZE,
.n_buckets = TABLE_MAX_BUCKET_COUNT,
.n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
.f_hash = test_hash,
.seed = 0,
.signature_offset = 0;
.key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
};
So, I wanted to use hash functions from DPDK rte_hash library. This is what I'm doing and looking at the code this looks ok to me.
I'm at least a week or 2 away from testing this part of the code. I wanted to confirm that, there is no fundamental flaw in using the DPDK rte_hash library and rte_table library like this. Could someone confirm this please ?
#define DEFAULT_HASH_FUNC rte_hash_crc
struct rte_table_hash_ext_params hash_table_params = {
.key_size = TABLE_ENTRY_KEY_SIZE,
.n_keys = TABLE_MAX_SIZE,
.n_buckets = TABLE_MAX_BUCKET_COUNT,
.n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
.f_hash = DEFAULT_HASH_FUNC ,
.seed = 0,
.signature_offset = 0;
.key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
};
Thanks
-Avinash
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-09-21 22:34 [dpdk-dev] DPDK hash function related question Yeddula, Avinash
@ 2015-09-22 10:05 ` Dumitrescu, Cristian
2015-09-22 13:40 ` Thomas Monjalon
2015-10-12 17:03 ` Yeddula, Avinash
0 siblings, 2 replies; 7+ messages in thread
From: Dumitrescu, Cristian @ 2015-09-22 10:05 UTC (permalink / raw)
To: Yeddula, Avinash, dev, Bly, Mike
Hi Avinash,
Yes, the hash function is configurable.
Are you using a DPDK release older than 2.1? In DPDK we moved away from test_hash to CRC-based hashes. Please take a look at DPDK release 2.1 examples/ip_pipeline application: in pipeline_flow_classification_be.c, we use CRC-based hash functions defined in file hash_func.h from the same folder.
Regards,
Cristian
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Tuesday, September 22, 2015 1:34 AM
> To: dev@dpdk.org; Bly, Mike
> Subject: [dpdk-dev] DPDK hash function related question
>
> Hello All,
>
> I'm DPDK extensible bucket hash in the rte_table library of packet
> framework. My question is related to the actual hash function that computes
> the hash signature.
>
> All the available examples have initialized it to test_hash. I do not see any
> hash function available in rte_table library , that computes the actual
> signature
>
>
>
> struct rte_table_hash_ext_params hash_table_params = {
>
> .key_size = TABLE_ENTRY_KEY_SIZE,
>
> .n_keys = TABLE_MAX_SIZE,
>
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
>
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
>
> .f_hash = test_hash,
>
> .seed = 0,
>
> .signature_offset = 0;
>
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
>
> };
>
>
>
> So, I wanted to use hash functions from DPDK rte_hash library. This is what
> I'm doing and looking at the code this looks ok to me.
>
> I'm at least a week or 2 away from testing this part of the code. I wanted to
> confirm that, there is no fundamental flaw in using the DPDK rte_hash library
> and rte_table library like this. Could someone confirm this please ?
>
>
>
> #define DEFAULT_HASH_FUNC rte_hash_crc
>
>
>
> struct rte_table_hash_ext_params hash_table_params = {
>
> .key_size = TABLE_ENTRY_KEY_SIZE,
>
> .n_keys = TABLE_MAX_SIZE,
>
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
>
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
>
> .f_hash = DEFAULT_HASH_FUNC ,
>
> .seed = 0,
>
> .signature_offset = 0;
>
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
>
> };
>
>
>
> Thanks
>
> -Avinash
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-09-22 10:05 ` Dumitrescu, Cristian
@ 2015-09-22 13:40 ` Thomas Monjalon
2015-09-23 12:47 ` Dumitrescu, Cristian
2015-10-12 17:03 ` Yeddula, Avinash
1 sibling, 1 reply; 7+ messages in thread
From: Thomas Monjalon @ 2015-09-22 13:40 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: dev, Bly, Mike
2015-09-22 10:05, Dumitrescu, Cristian:
> Are you using a DPDK release older than 2.1?
> In DPDK we moved away from test_hash to CRC-based hashes.
> Please take a look at DPDK release 2.1 examples/ip_pipeline application:
> in pipeline_flow_classification_be.c, we use CRC-based hash functions
> defined in file hash_func.h from the same folder.
Has it already been said that these functions should be hosted elsewhere?
e.g in librte_hash ;)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-09-22 13:40 ` Thomas Monjalon
@ 2015-09-23 12:47 ` Dumitrescu, Cristian
0 siblings, 0 replies; 7+ messages in thread
From: Dumitrescu, Cristian @ 2015-09-23 12:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bly, Mike
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, September 22, 2015 4:41 PM
> To: Dumitrescu, Cristian
> Cc: dev@dpdk.org; Yeddula, Avinash; Bly, Mike
> Subject: Re: [dpdk-dev] DPDK hash function related question
>
> 2015-09-22 10:05, Dumitrescu, Cristian:
> > Are you using a DPDK release older than 2.1?
> > In DPDK we moved away from test_hash to CRC-based hashes.
> > Please take a look at DPDK release 2.1 examples/ip_pipeline application:
> > in pipeline_flow_classification_be.c, we use CRC-based hash functions
> > defined in file hash_func.h from the same folder.
>
> Has it already been said that these functions should be hosted elsewhere?
> e.g in librte_hash ;)
It is fine with me. Pablo, feel free to look at these functions and move them to librte_hash if useful.
We are looking to augment these functions to with some more for symmetric hashing during 2.2 (hopefully) or 2.3 development, might be better to wait for this until that time for a more comprehensible solution.
Regards,
Cristian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-09-22 10:05 ` Dumitrescu, Cristian
2015-09-22 13:40 ` Thomas Monjalon
@ 2015-10-12 17:03 ` Yeddula, Avinash
2015-10-13 8:05 ` De Lara Guarch, Pablo
2015-10-13 11:44 ` Dumitrescu, Cristian
1 sibling, 2 replies; 7+ messages in thread
From: Yeddula, Avinash @ 2015-10-12 17:03 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Bly, Mike
Hi Cristian,
I have configured the hash function and it compile fine with "warnings". Since librte_hash vs librte_table is 32bit vs 64bit.
librte_hash library :
/** Type of function that can be used for calculating the hash value. */
typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len, uint32_t init_val);
librte_table library:
typedef uint64_t (*rte_table_hash_op_hash) (void *key, uint32_t key_size, uint64_t seed);
I could use one of these hash functions. This is one option, but our first priority is to use crc hash or cukoo hash.
https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeline/hash_func.h
We do not want to have those warning in our code. What do you suggest ?
Thanks
-Avinash
-----Original Message-----
From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
Sent: Tuesday, September 22, 2015 3:05 AM
To: Yeddula, Avinash; dev@dpdk.org; Bly, Mike
Subject: RE: DPDK hash function related question
Hi Avinash,
Yes, the hash function is configurable.
Are you using a DPDK release older than 2.1? In DPDK we moved away from test_hash to CRC-based hashes. Please take a look at DPDK release 2.1 examples/ip_pipeline application: in pipeline_flow_classification_be.c, we use CRC-based hash functions defined in file hash_func.h from the same folder.
Regards,
Cristian
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Tuesday, September 22, 2015 1:34 AM
> To: dev@dpdk.org; Bly, Mike
> Subject: [dpdk-dev] DPDK hash function related question
>
> Hello All,
>
> I'm DPDK extensible bucket hash in the rte_table library of packet
> framework. My question is related to the actual hash function that
> computes the hash signature.
>
> All the available examples have initialized it to test_hash. I do not see any
> hash function available in rte_table library , that computes the
> actual signature
>
>
>
> struct rte_table_hash_ext_params hash_table_params = {
>
> .key_size = TABLE_ENTRY_KEY_SIZE,
>
> .n_keys = TABLE_MAX_SIZE,
>
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
>
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
>
> .f_hash = test_hash,
>
> .seed = 0,
>
> .signature_offset = 0;
>
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
>
> };
>
>
>
> So, I wanted to use hash functions from DPDK rte_hash library. This is
> what I'm doing and looking at the code this looks ok to me.
>
> I'm at least a week or 2 away from testing this part of the code. I
> wanted to confirm that, there is no fundamental flaw in using the DPDK
> rte_hash library and rte_table library like this. Could someone confirm this please ?
>
>
>
> #define DEFAULT_HASH_FUNC rte_hash_crc
>
>
>
> struct rte_table_hash_ext_params hash_table_params = {
>
> .key_size = TABLE_ENTRY_KEY_SIZE,
>
> .n_keys = TABLE_MAX_SIZE,
>
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
>
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
>
> .f_hash = DEFAULT_HASH_FUNC ,
>
> .seed = 0,
>
> .signature_offset = 0;
>
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
>
> };
>
>
>
> Thanks
>
> -Avinash
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-10-12 17:03 ` Yeddula, Avinash
@ 2015-10-13 8:05 ` De Lara Guarch, Pablo
2015-10-13 11:44 ` Dumitrescu, Cristian
1 sibling, 0 replies; 7+ messages in thread
From: De Lara Guarch, Pablo @ 2015-10-13 8:05 UTC (permalink / raw)
To: Yeddula, Avinash, Dumitrescu, Cristian, dev, Bly, Mike
Hi Avinash,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Monday, October 12, 2015 6:03 PM
> To: Dumitrescu, Cristian; dev@dpdk.org; Bly, Mike
> Subject: Re: [dpdk-dev] DPDK hash function related question
>
> Hi Cristian,
> I have configured the hash function and it compile fine with "warnings". Since
> librte_hash vs librte_table is 32bit vs 64bit.
>
> librte_hash library :
> /** Type of function that can be used for calculating the hash value. */
> typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len,
> uint32_t init_val);
>
> librte_table library:
> typedef uint64_t (*rte_table_hash_op_hash) (void *key, uint32_t
> key_size, uint64_t seed);
>
> I could use one of these hash functions. This is one option, but our first
> priority is to use crc hash or cukoo hash.
Mind that cuckoo hash is not a hash function, but a method for resolving collisions in a hash table.
> https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeli
> ne/hash_func.h
>
> We do not want to have those warning in our code. What do you suggest ?
>
> Thanks
> -Avinash
>
> -----Original Message-----
> From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
> Sent: Tuesday, September 22, 2015 3:05 AM
> To: Yeddula, Avinash; dev@dpdk.org; Bly, Mike
> Subject: RE: DPDK hash function related question
>
> Hi Avinash,
>
> Yes, the hash function is configurable.
>
> Are you using a DPDK release older than 2.1? In DPDK we moved away from
> test_hash to CRC-based hashes. Please take a look at DPDK release 2.1
> examples/ip_pipeline application: in pipeline_flow_classification_be.c, we
> use CRC-based hash functions defined in file hash_func.h from the same
> folder.
>
> Regards,
> Cristian
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> > Sent: Tuesday, September 22, 2015 1:34 AM
> > To: dev@dpdk.org; Bly, Mike
> > Subject: [dpdk-dev] DPDK hash function related question
> >
> > Hello All,
> >
> > I'm DPDK extensible bucket hash in the rte_table library of packet
> > framework. My question is related to the actual hash function that
> > computes the hash signature.
> >
> > All the available examples have initialized it to test_hash. I do not see any
> > hash function available in rte_table library , that computes the
> > actual signature
> >
> >
> >
> > struct rte_table_hash_ext_params hash_table_params = {
> >
> > .key_size = TABLE_ENTRY_KEY_SIZE,
> >
> > .n_keys = TABLE_MAX_SIZE,
> >
> > .n_buckets = TABLE_MAX_BUCKET_COUNT,
> >
> > .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> >
> > .f_hash = test_hash,
> >
> > .seed = 0,
> >
> > .signature_offset = 0;
> >
> > .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> >
> > };
> >
> >
> >
> > So, I wanted to use hash functions from DPDK rte_hash library. This is
> > what I'm doing and looking at the code this looks ok to me.
> >
> > I'm at least a week or 2 away from testing this part of the code. I
> > wanted to confirm that, there is no fundamental flaw in using the DPDK
> > rte_hash library and rte_table library like this. Could someone confirm this
> please ?
> >
> >
> >
> > #define DEFAULT_HASH_FUNC rte_hash_crc
> >
> >
> >
> > struct rte_table_hash_ext_params hash_table_params = {
> >
> > .key_size = TABLE_ENTRY_KEY_SIZE,
> >
> > .n_keys = TABLE_MAX_SIZE,
> >
> > .n_buckets = TABLE_MAX_BUCKET_COUNT,
> >
> > .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> >
> > .f_hash = DEFAULT_HASH_FUNC ,
> >
> > .seed = 0,
> >
> > .signature_offset = 0;
> >
> > .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> >
> > };
> >
> >
> >
> > Thanks
> >
> > -Avinash
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] DPDK hash function related question
2015-10-12 17:03 ` Yeddula, Avinash
2015-10-13 8:05 ` De Lara Guarch, Pablo
@ 2015-10-13 11:44 ` Dumitrescu, Cristian
1 sibling, 0 replies; 7+ messages in thread
From: Dumitrescu, Cristian @ 2015-10-13 11:44 UTC (permalink / raw)
To: Yeddula, Avinash, dev, Bly, Mike
> -----Original Message-----
> From: Yeddula, Avinash [mailto:ayeddula@ciena.com]
> Sent: Monday, October 12, 2015 6:03 PM
> To: Dumitrescu, Cristian; dev@dpdk.org; Bly, Mike
> Subject: RE: DPDK hash function related question
>
> Hi Cristian,
> I have configured the hash function and it compile fine with "warnings". Since
> librte_hash vs librte_table is 32bit vs 64bit.
>
> librte_hash library :
> /** Type of function that can be used for calculating the hash value. */
> typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len,
> uint32_t init_val);
>
> librte_table library:
> typedef uint64_t (*rte_table_hash_op_hash) (void *key, uint32_t
> key_size, uint64_t seed);
>
> I could use one of these hash functions. This is one option, but our first
> priority is to use crc hash or cukoo hash.
> https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeli
> ne/hash_func.h
>
> We do not want to have those warning in our code. What do you suggest ?
Would function pointer conversion work?
>
> Thanks
> -Avinash
>
> -----Original Message-----
> From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
> Sent: Tuesday, September 22, 2015 3:05 AM
> To: Yeddula, Avinash; dev@dpdk.org; Bly, Mike
> Subject: RE: DPDK hash function related question
>
> Hi Avinash,
>
> Yes, the hash function is configurable.
>
> Are you using a DPDK release older than 2.1? In DPDK we moved away from
> test_hash to CRC-based hashes. Please take a look at DPDK release 2.1
> examples/ip_pipeline application: in pipeline_flow_classification_be.c, we
> use CRC-based hash functions defined in file hash_func.h from the same
> folder.
>
> Regards,
> Cristian
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash
> > Sent: Tuesday, September 22, 2015 1:34 AM
> > To: dev@dpdk.org; Bly, Mike
> > Subject: [dpdk-dev] DPDK hash function related question
> >
> > Hello All,
> >
> > I'm DPDK extensible bucket hash in the rte_table library of packet
> > framework. My question is related to the actual hash function that
> > computes the hash signature.
> >
> > All the available examples have initialized it to test_hash. I do not see any
> > hash function available in rte_table library , that computes the
> > actual signature
> >
> >
> >
> > struct rte_table_hash_ext_params hash_table_params = {
> >
> > .key_size = TABLE_ENTRY_KEY_SIZE,
> >
> > .n_keys = TABLE_MAX_SIZE,
> >
> > .n_buckets = TABLE_MAX_BUCKET_COUNT,
> >
> > .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> >
> > .f_hash = test_hash,
> >
> > .seed = 0,
> >
> > .signature_offset = 0;
> >
> > .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> >
> > };
> >
> >
> >
> > So, I wanted to use hash functions from DPDK rte_hash library. This is
> > what I'm doing and looking at the code this looks ok to me.
> >
> > I'm at least a week or 2 away from testing this part of the code. I
> > wanted to confirm that, there is no fundamental flaw in using the DPDK
> > rte_hash library and rte_table library like this. Could someone confirm this
> please ?
> >
> >
> >
> > #define DEFAULT_HASH_FUNC rte_hash_crc
> >
> >
> >
> > struct rte_table_hash_ext_params hash_table_params = {
> >
> > .key_size = TABLE_ENTRY_KEY_SIZE,
> >
> > .n_keys = TABLE_MAX_SIZE,
> >
> > .n_buckets = TABLE_MAX_BUCKET_COUNT,
> >
> > .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> >
> > .f_hash = DEFAULT_HASH_FUNC ,
> >
> > .seed = 0,
> >
> > .signature_offset = 0;
> >
> > .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> >
> > };
> >
> >
> >
> > Thanks
> >
> > -Avinash
> >
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-13 11:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-21 22:34 [dpdk-dev] DPDK hash function related question Yeddula, Avinash
2015-09-22 10:05 ` Dumitrescu, Cristian
2015-09-22 13:40 ` Thomas Monjalon
2015-09-23 12:47 ` Dumitrescu, Cristian
2015-10-12 17:03 ` Yeddula, Avinash
2015-10-13 8:05 ` De Lara Guarch, Pablo
2015-10-13 11:44 ` Dumitrescu, Cristian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).