All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Chilikin, Andrey" <andrey.chilikin@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	"Wang, Yipeng1" <yipeng1.wang@intel.com>,
	"Gobriel,  Sameh" <sameh.gobriel@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/3] hash: add predictable RSS implementation
Date: Mon, 12 Apr 2021 09:47:30 +0000	[thread overview]
Message-ID: <DM6PR11MB4491CE573779470E934BE7C49A709@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <3fb31ad3-cb84-05a4-fb0e-46e33e008f57@intel.com>

> 
> <snip>
> 
> >> +#defineRETA_SZ_MIN2U
> >> +#defineRETA_SZ_MAX16U
> >
> > Should these RETA_SZ defines be in public header?
> > So user can know what are allowed values?
> >
> 
> I don't think this is necessary, because the user chooses it not
> arbitrary, but depending on the NIC.

Sure thing, but it would be goo for the user to know what are the SW
Limitations on it without digging through .c.

> 
> >> +#define RETA_SZ_IN_RANGE(reta_sz)((reta_sz >= RETA_SZ_MIN) && \
> 
> <snip>
> 
> >> +uint32_t i;
> >
> > Empty line is  missing.
> >
> 
> Thanks
> 
> >> +if ((name == NULL) || (key_len == 0) || !RETA_SZ_IN_RANGE(reta_sz)) {
> >> +rte_errno = EINVAL;
> >> +return NULL;
> >> +}
> 
> <snip>
> 
> >> +static inline void
> >> +set_bit(uint8_t *ptr, uint32_t bit, uint32_t pos)
> >> +{
> >> +uint32_t byte_idx = pos >> 3;
> >
> > Just as a nit to be consistent with the line below:
> > pos / CHAR_BIT;
> >
> 
> Fixed
> 
> >> +uint32_t bit_idx = (CHAR_BIT - 1) - (pos & (CHAR_BIT - 1));
> >> +uint8_t tmp;
> 
> <snip>
> 
> >> +ent = rte_zmalloc(NULL, sizeof(struct rte_thash_subtuple_helper) +
> >> +sizeof(uint32_t) * (1 << ctx->reta_sz_log), 0);
> >
> > Helper can be used by data-path code (via rte_thash_get_compliment()) right?
> > Then might be better to align it at cache-line.
> >
> 
> Agree, I'll fix it
> 
> >> +if (ent == NULL)
> >> +return -ENOMEM;
> 
> <snip>
> 
> >>   uint32_t
> >> -rte_thash_get_compliment(struct rte_thash_subtuple_helper *h __rte_unused,
> >> -uint32_t hash __rte_unused, uint32_t desired_hash __rte_unused)
> >> +rte_thash_get_compliment(struct rte_thash_subtuple_helper *h,
> >> +uint32_t hash, uint32_t desired_hash)
> >>   {
> >> -return 0;
> >> +return h->compl_table[(hash ^ desired_hash) & h->lsb_msk];
> >>   }
> >
> > Would it make sense to add another-one for multi values:
> > rte_thash_get_compliment(uint32_t hash, const uint32_t desired_hashes[], uint32_t adj_hash[], uint32_t num);
> > So user can get adjustment values for multiple queues at once?
> >
> 
> At the moment I can't find scenarios why do we need to have a bulk
> version for this function

My thought was about case when number of configured
HW queues is less than reta_size.
Let say reta_size==4, but user configured only 3 queues and reta={0,1,2,0}.
In that case for queue 0, both 0 and 3 values would suit. 


  reply	other threads:[~2021-04-12  9:47 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 18:24 [dpdk-dev] [PATCH v1 0/3] Predictable RSS feature Vladimir Medvedkin
2021-03-16 18:24 ` [dpdk-dev] [PATCH v1 1/3] hash: add predictable RSS API Vladimir Medvedkin
2021-03-16 18:24 ` [dpdk-dev] [PATCH v1 2/3] hash: add predictable RSS implementation Vladimir Medvedkin
2021-03-16 18:24 ` [dpdk-dev] [PATCH v1 3/3] test/hash: add additional thash tests Vladimir Medvedkin
2021-04-06 19:50 ` [dpdk-dev] [PATCH v2 0/3] Predictable RSS feature Vladimir Medvedkin
2021-04-08 15:56   ` Stephen Hemminger
2021-04-11 18:51     ` Medvedkin, Vladimir
2021-10-22 20:37       ` Thomas Monjalon
2021-10-24 14:42         ` Vladimir Medvedkin
2021-04-10  0:32   ` Wang, Yipeng1
2021-04-11 18:51     ` Medvedkin, Vladimir
2021-04-11 19:11   ` [dpdk-dev] [PATCH v3 " Vladimir Medvedkin
2021-04-13 13:19     ` [dpdk-dev] [PATCH v4 " Vladimir Medvedkin
2021-04-14 18:04       ` Wang, Yipeng1
2021-04-15  8:29         ` David Marchand
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 0/5] " Vladimir Medvedkin
2021-04-20 21:31         ` Thomas Monjalon
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 1/5] hash: add predictable RSS API Vladimir Medvedkin
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 2/5] hash: add predictable RSS implementation Vladimir Medvedkin
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 3/5] test/hash: add additional thash tests Vladimir Medvedkin
2021-04-29  9:13         ` David Marchand
2021-04-29  9:17           ` Medvedkin, Vladimir
2021-04-29 18:45             ` Stanislaw Kardach
2021-05-04 14:06               ` Medvedkin, Vladimir
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 4/5] doc: add thash documentation Vladimir Medvedkin
2021-04-20 11:25         ` Mcnamara, John
2021-04-19 15:59       ` [dpdk-dev] [PATCH v5 5/5] maintainers: claim maintainership of the hash library Vladimir Medvedkin
2021-04-13 13:19     ` [dpdk-dev] [PATCH v4 1/3] hash: add predictable RSS API Vladimir Medvedkin
2021-04-14 17:06       ` Wang, Yipeng1
2021-04-13 13:19     ` [dpdk-dev] [PATCH v4 2/3] hash: add predictable RSS implementation Vladimir Medvedkin
2021-04-14 17:51       ` Wang, Yipeng1
2021-04-13 13:19     ` [dpdk-dev] [PATCH v4 3/3] test/hash: add additional thash tests Vladimir Medvedkin
2021-04-14 17:56       ` Wang, Yipeng1
2021-04-11 19:11   ` [dpdk-dev] [PATCH v3 1/3] hash: add predictable RSS API Vladimir Medvedkin
2021-04-11 19:11   ` [dpdk-dev] [PATCH v3 2/3] hash: add predictable RSS implementation Vladimir Medvedkin
2021-04-11 19:11   ` [dpdk-dev] [PATCH v3 3/3] test/hash: add additional thash tests Vladimir Medvedkin
2021-04-06 19:50 ` [dpdk-dev] [PATCH v2 1/3] hash: add predictable RSS API Vladimir Medvedkin
2021-04-10  0:05   ` Wang, Yipeng1
2021-04-11 18:52     ` Medvedkin, Vladimir
2021-04-06 19:50 ` [dpdk-dev] [PATCH v2 2/3] hash: add predictable RSS implementation Vladimir Medvedkin
2021-04-07 12:53   ` Ananyev, Konstantin
2021-04-11 18:51     ` Medvedkin, Vladimir
2021-04-12  9:47       ` Ananyev, Konstantin [this message]
2021-04-13 12:28         ` Medvedkin, Vladimir
2021-04-10  0:10   ` Wang, Yipeng1
2021-04-11 18:52     ` Medvedkin, Vladimir
2021-04-06 19:50 ` [dpdk-dev] [PATCH v2 3/3] test/hash: add additional thash tests Vladimir Medvedkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR11MB4491CE573779470E934BE7C49A709@DM6PR11MB4491.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=andrey.chilikin@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ray.kinsella@intel.com \
    --cc=sameh.gobriel@intel.com \
    --cc=vladimir.medvedkin@intel.com \
    --cc=yipeng1.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.