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

[Ferruh Yigit]

On 10/15/2019 6:28 PM, Vamsi Krishna Attunuru wrote:
> 
> 
>> -----Original Message-----
>> From: dev <dev-bounces at dpdk.org> On Behalf Of Ferruh Yigit
>> Sent: Tuesday, October 15, 2019 10:17 PM
>> To: Vamsi Krishna Attunuru <vattunuru at marvell.com>; dev at dpdk.org
>> Cc: arybchenko at solarflare.com; Jerin Jacob Kollanukkaran
>> <jerinj at marvell.com>; thomas at 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 at marvell.com wrote:
>>> From: Vamsi Attunuru <vattunuru at 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.

Does application tries to predict in which queue a specific flow will land? And
configure RETA table OR do the lcore-queue mapping accordingly?

Not sure if other PMDs need this too but API seems trivial and it doesn't affect
existing code, so no objection from my end for the API. Can you please check the
unit test comments?

>  
> 
>>
>> 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 at marvell.com>
>>
>> <...>
>