On 10/04/2021 03:10, Wang, Yipeng1 wrote:
-----Original Message-----
From: Medvedkin, Vladimir <vladimir.medved...@intel.com>
Sent: Tuesday, April 6, 2021 12:51 PM
To: dev@dpdk.org
Cc: Ananyev, Konstantin <konstantin.anan...@intel.com>; Chilikin, Andrey
<andrey.chili...@intel.com>; Kinsella, Ray <ray.kinse...@intel.com>; Wang,
Yipeng1 <yipeng1.w...@intel.com>; Gobriel, Sameh
<sameh.gobr...@intel.com>; Richardson, Bruce
<bruce.richard...@intel.com>
Subject: [PATCH v2 2/3] hash: add predictable RSS implementation
This patch implements predictable RSS functionality.
Signed-off-by: Vladimir Medvedkin <vladimir.medved...@intel.com>
---
lib/librte_hash/rte_thash.c | 577
++++++++++++++++++++++++++++++++++++++++++--
lib/librte_hash/rte_thash.h | 42 ++++
lib/librte_hash/version.map | 1 +
3 files changed, 602 insertions(+), 18 deletions(-)
<snip>
+/**
+ * writes m-sequence to the hash_key for range [start, end]
+ * (i.e. including start and end positions) */ static int
+generate_subkey(struct rte_thash_ctx *ctx, struct thash_lfsr *lfsr,
+uint32_t start, uint32_t end)
+{
+uint32_t i;
+uint32_t req_bits = (start < end) ? (end - start) : (start - end);
+req_bits++; /* due to incuding end */
+
+/* check if lfsr overflow period of the m-sequence */
+if (((lfsr->bits_cnt + req_bits) > (1ULL << lfsr->deg) - 1) &&
+((ctx->flags &
RTE_THASH_IGNORE_PERIOD_OVERFLOW) !=
+RTE_THASH_IGNORE_PERIOD_OVERFLOW))
+return -ENOSPC;
[Wang, Yipeng]
If nospace, should one increase lfsr->deg? Or if it is already the highest deg
you predefined then what to do?
Maybe a log msg could help user with more information on the solutions.
It is not possible to increase the degree of lfsr due to mathematical
restrictions. It must be exactly equal to the number of bits for which
we want to have a collision.
+
+if (start < end) {
+/* original direction (from left to right)*/
+for (i = start; i <= end; i++)
+set_bit(ctx->hash_key, get_bit_lfsr(lfsr), i);
<snip>
+/**
+ * Adjust tuple with complimentary bits.
+ *
[Wang, Yipeng]
More explanation for this API is needed.
My understanding is that user should call this function in a loop, until
the above callback function returns success thus this function succeeds.
I'm going to rewrite this function in v3. The loop will be internal.
BTW, why not put this API in the first API commit?
My fault, will fix this
+ * @param h
+ * Pointer to the helper struct
+ * @param orig_tuple
+ * Pointer to the tuple to be adjusted
+ * @param adj_bits
+ * Valure returned by rte_thash_get_compliment
[Wang, Yipeng] typo. *value
+ * @param fn
+ * Callback function to check adjusted tuple. Could be NULL
+ * @param userdata
+ * Pointer to the userdata to be passed to fn(). Could be NULL
+ *
+ * @return
+ * 0 on success
+ * negative otherwise
+ */
+__rte_experimental
+int
+rte_thash_adjust_tuple(struct rte_thash_subtuple_helper *h,
+uint8_t *orig_tuple, uint32_t adj_bits,
+rte_thash_check_tuple_t fn, void *userdata);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_hash/version.map b/lib/librte_hash/version.map index
93cb230..a992a1e 100644
--- a/lib/librte_hash/version.map
+++ b/lib/librte_hash/version.map
@@ -32,6 +32,7 @@ DPDK_21 {
EXPERIMENTAL {
global:
+rte_thash_adjust_tuple;
rte_hash_free_key_with_position;
rte_hash_lookup_with_hash_bulk;
rte_hash_lookup_with_hash_bulk_data;
--
2.7.4
--
Regards,
Vladimir
