[dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6 prefix

Zhang, Qi Z qi.z.zhang at intel.com
Wed Jul 8 11:45:22 CEST 2020


Hi Thomas:

Sorry for late reply, see comment inline.


On 2020/7/7 19:06, Thomas Monjalon wrote:
> 16/06/2020 10:16, Junfeng Guo:
>> This patch defines new RSS offload types for IPv6 prefix with 32, 48,
>> 64 bits of both SRC and DST IPv6 address.
>>
>> Signed-off-by: Junfeng Guo <junfeng.guo at intel.com>
>> ---
>>   lib/librte_ethdev/rte_ethdev.h | 51 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 51 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index 631b146bd..5a7ba36d8 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -538,6 +538,9 @@ struct rte_eth_rss_conf {
>>   #define ETH_RSS_L4_DST_ONLY        (1ULL << 60)
>>   #define ETH_RSS_L2_SRC_ONLY        (1ULL << 59)
>>   #define ETH_RSS_L2_DST_ONLY        (1ULL << 58)
>> +#define ETH_RSS_L3_PRE32           (1ULL << 57)
>> +#define ETH_RSS_L3_PRE48           (1ULL << 56)
>> +#define ETH_RSS_L3_PRE64           (1ULL << 55)
> PRE32, 48 and 64 are not obvious.
> Why is it needed?
there is typical usage for NAT64, which use 32 bit prefix for IPv6 
addresses, in this case flows over IPv4 and IPv6 will result in the same 
hash value,
as well as 48, 64, which also have some corresponding use cases,
> At least, please add comments for the values of this API.

sure, we will add more comments.
> Do we want to continue with the RTE_ prefix missing?
> Can't we add the prefix for the new values?
32, 48, 64 are typical usage, and consider suffix pair we may add later, 
it will cost 6 bits
so far we still have 27 bit left,  so it looks like will not be a 
problem in following couple releases.

but anyway use 64 bits to represent RSS inputset can't meet the coming 
complex RSS usage, we may need to figure out some new APIs and abandon 
the old one.
A stacked protocol layer with bit field selector in each layer is under 
consideration, hope we can contribute some RFC at some moment. also feel 
free let us know
your thought.
>
> Note: ethdev maintainers were not Cc'ed.
> This reason is enough to nack the patch.

sure, will send a new version to follow this

Thanks
Qi


>
>
>



More information about the dev mailing list