Re: [dpdk-dev] [PATCH v2 1/3] lib/ethdev: add ethdev op to get hash index

[Vamsi Krishna Attunuru <vattunuru@marvell.com>]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ferruh Yigit
> Sent: Tuesday, October 15, 2019 10:17 PM
> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org
> Cc: arybchenko@solarflare.com; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; thomas@monjalon.net
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/ethdev: add ethdev op to get hash
> index
> 
> On 10/15/2019 10:52 AM, vattunuru@marvell.com wrote:
> > From: Vamsi Attunuru <vattunuru@marvell.com>
> >
> > Some networking devices may use custom algos for computing hash
> > indices and spread the packets accordingly.
> >
> > Patch adds an eth_dev op to get the hash index correspond to the given
> > hash value received in the initial packet on the given port.
> >
> > Some of the applications compute hash index from the hash value
> > received in the initial packet and than configure the rxq to lcore
> > mapping to make sure the mapped lcore/rxq would receive the upcoming
> > traffic that has similar hash.
> > Such applications may use these API to get the hash index used by the
> > PMD for spreading those traffic.
> 
> Hi Vamsi,
> 
> Can you please describe this usecase?
> If the application is receiving the packet, it already knows which queue it is
> coming from, what is the benefit of the getting hash index?

Hi Ferruh,

I think the commit msg is incomplete and did not explain the use case clearly, my apologies.
Actual usecase is when application precalculates the hash value using some hashlib for a specific type of packet headers with the same hash key that's configured in the HW, application would compute hash_index as hash % reta_size and predict the packets on the computed queue index. But these hash_index computation might be different from PMD/HW computed index(based it's algo design). To fix those disparity, these API been introduced which can be used during configuration time to have
required lcore-rq mapping.
 

> 
> The concern is adding a new API which is specific to a use case and HW and
> won't be used in long term. That will only create technical dept for us.
> 
> >
> > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> 
> <...>