[dpdk-dev] [PATCH 04/29] net/ena/base: set default hash key

[Andrew Rybchenko]

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 <mk at semihalf.com>
> Reviewed-by: Igor Chauskin <igorch at amazon.com>
> Reviewed-by: Guy Tzalik <gtzalik at 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)
>  {
>