pt., 27 mar 2020 o 12:12 Andrew Rybchenko <arybche...@solarflare.com>
napisał(a):
>
> 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.
>
I will remove it in v2.
> > + 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.
> > + 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)
> > {
> >
>
