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

[Thomas Monjalon]

08/07/2020 11:45, Zhang, Qi Z:
> 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?

I think you misunderstood this question. I am asking to
change the name ETH_RSS_L3_PRE32 to RTE_ETH_RSS_L3_PRE32

> 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.

Having some space left is not a reason to waste it :)
If I understand well, there is no standard for this API.
You are assigning some bits to some usage.
I don't find it generic and flexible enough.
If you want to limit the size of the match, we should have
a generic syntax to choose how many bits of the IPv6 address
are taken into account for RSS. Or maybe an IPv6 mask.

> 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.

My thought is to discuss how to fit this need in future
and avoid adding few bits of temporary workaround.
API definition is serious and we must avoid temporary half solutions.