On 3/27/20 1:17 PM, Michal Krawczyk wrote:
> 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 <m...@semihalf.com>
> Reviewed-by: Igor Chauskin <igo...@amazon.com>
> Reviewed-by: Guy Tzalik <gtza...@amazon.com>
[snip]
> 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?
> +
> + 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.
> + 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.
> + 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)
> {
>
