pt., 27 mar 2020 o 12:12 Andrew Rybchenko [off-list ref]
napisał(a):

On 3/27/20 1:17 PM, Michal Krawczyk wrote:

quoted

The RSS hash key was present in the device, but it wasn't exposed to
the user. The other key still cannot be set, but now it can be accessed
if one needs to do that.

By default, the random hash key is used and it is generated only once
when requested for the first time.

Signed-off-by: Michal Krawczyk <redacted>
Reviewed-by: Igor Chauskin <redacted>
Reviewed-by: Guy Tzalik <redacted>

[snip]

quoted

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index cab38152a7..4c1e4899d0 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c

@@ -256,6 +256,22 @@ static const struct eth_dev_ops ena_dev_ops = {
      .reta_query           = ena_rss_reta_query,
 };

+void ena_rss_key_fill(void *key, size_t size)
+{
+     static bool key_generated;
+     static uint8_t default_key[ENA_HASH_KEY_SIZE];

You have thread-safety patches in the series before this one.
Is it OK to be thread-unsafe here?

quoted

+
+     RTE_ASSERT(size <= ENA_HASH_KEY_SIZE);
+
+     if (unlikely(!key_generated)) {

I believe that unlikely() is not required here. It is not a
datapath and there is no point to use likely/unlikely on
control path.

I will remove it in v2.

quoted

+             for (size_t i = 0; i < ENA_HASH_KEY_SIZE; ++i)

It is C99 feature which breaks DPDK build pretty often, since
neither c99 nor higher are requested in default DPDK build.

Ok, will be fixed in v2.

quoted

+                     default_key[i] = rte_rand() & 0xff;
+             key_generated = true;
+     }
+
+     rte_memcpy(key, default_key, size);
+}
+
 static inline void ena_rx_mbuf_prepare(struct rte_mbuf *mbuf,
                                     struct ena_com_rx_ctx *ena_rx_ctx)
 {