Hi,
We have tested lib/librte_table/rte_table_hash_ext.c: rte_table_hash_ext_lookup
using dpdk 19.11
and it appears that the function is not reentrant safe causing incorrect hash
lookup misses at very small rate (< 0.005%)
when invoked by multiple threads in parallel.
The reason for reentrancy issue is as follows:
Embedding the "grinders" array in the rte_table_hash
structure results in a hash lookup that is non-reentrant
because temporary values are stored in the grinders array
during the hash lookup. The fix is to put the grinders
array on the stack.
We propose the following change to fix the reentrancy issue (courtesy of Brian
Hiltscher, [email protected]<mailto:[email protected]>):
diff --git a/lib/librte_table/rte_table_hash_ext.c
b/lib/librte_table/rte_table_hash_ext.c
index 802a24fe0..4a1504c54 100644
--- a/lib/librte_table/rte_table_hash_ext.c
+++ b/lib/librte_table/rte_table_hash_ext.c
@@ -66,6 +66,15 @@ struct grinder {
uint32_t key_index;
};
+/*
+ * Embedding the "grinders" array in the rte_table_hash
+ * structure results in a hash lookup that is non-reentrant
+ * because temporary values are stored in the grinders array
+ * during the hash lookup. The fix is to put the grinders
+ * array on the stack.
+ */
+#define FIX_HASH_BUG 1
+
struct rte_table_hash {
struct rte_table_stats stats;
@@ -85,10 +94,10 @@ struct rte_table_hash {
uint32_t data_size_shl;
uint32_t key_stack_tos;
uint32_t bkt_ext_stack_tos;
-
+#ifndef FIX_HASH_BUG
/* Grinder */
struct grinder grinders[RTE_PORT_IN_BURST_SIZE_MAX];
-
+#endif
/* Tables */
uint64_t *key_mask;
struct bucket *buckets;
@@ -856,7 +865,12 @@ static int rte_table_hash_ext_lookup(
void **entries)
{
struct rte_table_hash *t = (struct rte_table_hash *) table;
- struct grinder *g = t->grinders;
+#ifndef FIX_HASH_BUG
+ struct grinder *g = t->grinders;
+#else
+ struct grinder grinders[RTE_PORT_IN_BURST_SIZE_MAX];
+ struct grinder *g = grinders; // make grinders structure per thread
+#endif
Thanks,
Mehrdad Alipour
[email protected]
