[dpdk-dev] 17.05 --> 17.11, minimum hash table key size

[Bly, Mike]

Cristian,

Thank you. I have done the recommended change. The next thing we have run into is the f_hash selection. We were historically using rte_hash_crc_8byte() from rte_has_crc.h. In looking at DPDK content, I do not see anything close in an rte_*.h file to use with the appropriate input parameter list. I did find use of hash_default_key8() in examples/ip_pipeline/pipeline/hash_func.h. Is there no formal rte_*.h replacement/update for this relative to the hash-table changes in 17.11+? Is the expectation that the implementer will create their own as done with the aforementioned ip_pipeline example?

-MikeB

-----Original Message-----
From: Dumitrescu, Cristian <cristian.dumitrescu at intel.com> 
Sent: Friday, June 29, 2018 4:18 AM
To: Yeddula, Avinash <ayeddula at ciena.com>; dev at dpdk.org; dev <dev-bounces at dpdk.org>; users at dpdk.org
Cc: Bly, Mike <mbly at ciena.com>
Subject: [**EXTERNAL**] RE: 17.05 --> 17.11, minimum hash table key size


> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Friday, June 29, 2018 1:11 AM
> To: dev at dpdk.org; dev <dev-bounces at dpdk.org>; users at dpdk.org
> Cc: Bly, Mike <mbly at ciena.com>
> Subject: [dpdk-dev] 17.05 --> 17.11, minimum hash table key size
> 
> Hello,
> 
> We are in process of migrating our design from DPDK 17.05 to 17.11 and 
> we ran into a small problem. Within our design, we have some hash 
> tables with 4-byte keys. While going through the changes done in 
> 17.11, we have found there was an added key_size check, which now 
> requires key_size >= 8 bytes (see check_params_create() in 
> rte_table_hash_ext.c). Not seeing any other options, so I was hoping 
> someone could advise on how to support a 4-byte hash key size in 17.11 and on a go forward basis.
> 
> Regards,
> Avinash

Hi Avinash,

Simply declare you key size to be 8 bytes for any key size less or equal to 8 bytes and set the key mask parameter appropriately so that the additional bytes are masked out.

Regards,
Cristian