> -----Original Message-----
> From: Xu, Ting <ting...@intel.com>
> Sent: Thursday, July 9, 2020 2:48 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Xu, Ting
> <ting...@intel.com>; sta...@dpdk.org
> Subject: [PATCH v3] lib/table: fix cache alignment issue
>
> When create softnic hash table with 16 keys, it failed on 32bit
> environment because of the structure rte_bucket_4_16 alignment
> issue. Add __rte_cache_aligned to ensure correct cache align.
>
> Fixes: 8aa327214c ("table: hash")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ting Xu <ting...@intel.com>
>
> ---
> v2->v3: Rebase
> v1->v2: Correct patch time
> ---
> lib/librte_table/rte_table_hash_key16.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_table/rte_table_hash_key16.c
> b/lib/librte_table/rte_table_hash_key16.c
> index 2cca1c924..5e1665c15 100644
> --- a/lib/librte_table/rte_table_hash_key16.c
> +++ b/lib/librte_table/rte_table_hash_key16.c
> @@ -44,7 +44,7 @@ struct rte_bucket_4_16 {
> uint64_t key[4][2];
>
> /* Cache line 2 */
> - uint8_t data[0];
> + uint8_t data[0] __rte_cache_aligned;
> };
>
> struct rte_table_hash {
> --
> 2.17.1
Hi Ting,
This fix is breaking the execution for systems with cache line of 128 bytes, as
typically (on 64-bit systems) this structure would be 64-byte in size and
adding the __rte_cache_aligned would force doubling the size of this structure
through padding enforced by the compiler.
Can you please confirm this is caused by check below failing in the table
create function:
sizeof(struct rte_bucket_4_16) % 64) != 0
Since all the other fields in this data structure are explicitly declared as
64-bit fields, due to the alignment rules I was expecting the compiler to add a
32-bit padding field after the "next" field, which is a pointer that would only
take 32 bits on 32-bit systems. I am not sure why this did not take place in
your case, any thoughts?
Not sure why we would run Soft NIC on 32-bit systems, might be better to
disable Soft NIC for 32-bit systems.
Thanks,
Cristian
