[v2,1/3] ethdev: add new RSS types for IPv6 prefix
Checks
Commit Message
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@intel.com>
---
lib/librte_ethdev/rte_ethdev.h | 51 ++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
Comments
> -----Original Message-----
> From: Guo, Junfeng <junfeng.guo@intel.com>
> Sent: Tuesday, June 16, 2020 4:17 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Guo, Junfeng
> <junfeng.guo@intel.com>; Su, Simei <simei.su@intel.com>
> Subject: [PATCH v2 1/3] ethdev: add new RSS types for IPv6 prefix
>
> 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@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@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)
>
> /**
> * For input set change of hash filter, if SRC_ONLY and DST_ONLY of @@
> -561,6 +564,54 @@ rte_eth_rss_hf_refine(uint64_t rss_hf)
> return rss_hf;
> }
>
> +#define ETH_RSS_IPV6_PRE32 ( \
> + ETH_RSS_IPV6 | \
> + ETH_RSS_L3_PRE32)
> +
> +#define ETH_RSS_IPV6_PRE48 ( \
> + ETH_RSS_IPV6 | \
> + ETH_RSS_L3_PRE48)
> +
> +#define ETH_RSS_IPV6_PRE64 ( \
> + ETH_RSS_IPV6 | \
> + ETH_RSS_L3_PRE64)
> +
> +#define ETH_RSS_IPV6_PRE32_UDP ( \
> + ETH_RSS_NONFRAG_IPV6_UDP | \
> + ETH_RSS_L3_PRE32)
> +
> +#define ETH_RSS_IPV6_PRE48_UDP ( \
> + ETH_RSS_NONFRAG_IPV6_UDP | \
> + ETH_RSS_L3_PRE48)
> +
> +#define ETH_RSS_IPV6_PRE64_UDP ( \
> + ETH_RSS_NONFRAG_IPV6_UDP | \
> + ETH_RSS_L3_PRE64)
> +
> +#define ETH_RSS_IPV6_PRE32_TCP ( \
> + ETH_RSS_NONFRAG_IPV6_TCP | \
> + ETH_RSS_L3_PRE32)
> +
> +#define ETH_RSS_IPV6_PRE48_TCP ( \
> + ETH_RSS_NONFRAG_IPV6_TCP | \
> + ETH_RSS_L3_PRE48)
> +
> +#define ETH_RSS_IPV6_PRE64_TCP ( \
> + ETH_RSS_NONFRAG_IPV6_TCP | \
> + ETH_RSS_L3_PRE64)
> +
> +#define ETH_RSS_IPV6_PRE32_SCTP ( \
> + ETH_RSS_NONFRAG_IPV6_SCTP | \
> + ETH_RSS_L3_PRE32)
> +
> +#define ETH_RSS_IPV6_PRE48_SCTP ( \
> + ETH_RSS_NONFRAG_IPV6_SCTP | \
> + ETH_RSS_L3_PRE48)
> +
> +#define ETH_RSS_IPV6_PRE64_SCTP ( \
> + ETH_RSS_NONFRAG_IPV6_SCTP | \
> + ETH_RSS_L3_PRE64)
> +
> #define ETH_RSS_IP ( \
> ETH_RSS_IPV4 | \
> ETH_RSS_FRAG_IPV4 | \
> --
> 2.17.1
On 6/16/2020 9:16 AM, Junfeng Guo wrote:
> 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@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
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@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?
At least, please add comments for the values of this API.
Do we want to continue with the RTE_ prefix missing?
Can't we add the prefix for the new values?
Note: ethdev maintainers were not Cc'ed.
This reason is enough to nack the patch.
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@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
>
>
>
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@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.
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 8, 2020 5:58 PM
> To: Ye, Xiaolong <xiaolong.ye@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Guo, Junfeng
> <junfeng.guo@intel.com>; Su, Simei <simei.su@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; arybchenko@solarflare.com;
> viacheslavo@mellanox.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; orika@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6
> prefix
>
> 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@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
OK, we are going change all the ETH_RSS_xxx to RTE_ETH_RSS_xxx, or just the new values?
the first option looks make sense to me.
>
> > 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.
Actually IPv6 address prefix is in spec, please check below RFC.
https://tools.ietf.org/html/rfc6052#page-5
So probably we are not wasting bits here, since this is a typical usage that DPDK can provide.
Of cause more description is needed in the code here.
> 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.
Yes, I believe at some moment, a more generic solution is mandatory,
And I think that will not work if we stick on the 64 bits, new API need to be introduced and old one should be abandoned
>
> > 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.
>
>
08/07/2020 13:10, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 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@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
>
> OK, we are going change all the ETH_RSS_xxx to RTE_ETH_RSS_xxx, or just the new values?
> the first option looks make sense to me.
You cannot break compatibility with the existing values,
but you can provide an alias to preserve compatibility.
> > > 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.
>
> Actually IPv6 address prefix is in spec, please check below RFC.
> https://tools.ietf.org/html/rfc6052#page-5
Quoting the RFC:
"
the prefix shall be either the "Well-Known Prefix"
or a "Network-Specific Prefix" unique to the organization
deploying the address translators.
The prefixes can only have one of the following lengths:
32, 40, 48, 56, 64, or 96.
(The Well-Known Prefix is 96 bits long, and can only be used
in the last form of the table.)
"
So 40 and 56 are missing.
> So probably we are not wasting bits here, since this is a typical usage
> that DPDK can provide.
> Of cause more description is needed in the code here.
>
> > 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.
>
> Yes, I believe at some moment, a more generic solution is mandatory,
> And I think that will not work if we stick on the 64 bits, new API need to be introduced and old one should be abandoned
>
> >
> > > 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.
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 8, 2020 7:57 PM
> To: Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Guo, Junfeng
> <junfeng.guo@intel.com>; Su, Simei <simei.su@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; arybchenko@solarflare.com;
> viacheslavo@mellanox.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; orika@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6
> prefix
>
> 08/07/2020 13:10, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 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@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
> >
> > OK, we are going change all the ETH_RSS_xxx to RTE_ETH_RSS_xxx, or just
> the new values?
> > the first option looks make sense to me.
>
> You cannot break compatibility with the existing values, but you can provide
> an alias to preserve compatibility.
I will prefer the rename / alias can be done in a seperate patch for a single purpose.
>
> > > > 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.
> >
> > Actually IPv6 address prefix is in spec, please check below RFC.
> > https://tools.ietf.org/html/rfc6052#page-5
>
> Quoting the RFC:
> "
> the prefix shall be either the "Well-Known Prefix"
> or a "Network-Specific Prefix" unique to the organization
> deploying the address translators.
> The prefixes can only have one of the following lengths:
> 32, 40, 48, 56, 64, or 96.
> (The Well-Known Prefix is 96 bits long, and can only be used
> in the last form of the table.)
> "
>
> So 40 and 56 are missing.
Yes, like to add and lets accelerate the progress to abandon the old APIs :)
>
> > So probably we are not wasting bits here, since this is a typical
> > usage that DPDK can provide.
> > Of cause more description is needed in the code here.
> >
> > > 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.
> >
> > Yes, I believe at some moment, a more generic solution is mandatory,
> > And I think that will not work if we stick on the 64 bits, new API
> > need to be introduced and old one should be abandoned
> >
> > >
> > > > 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.
>
>
08/07/2020 14:05, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 08/07/2020 13:10, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 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@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.
[...]
> > > > > 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.
> > >
> > > Actually IPv6 address prefix is in spec, please check below RFC.
> > > https://tools.ietf.org/html/rfc6052#page-5
> >
> > Quoting the RFC:
> > "
> > the prefix shall be either the "Well-Known Prefix"
> > or a "Network-Specific Prefix" unique to the organization
> > deploying the address translators.
> > The prefixes can only have one of the following lengths:
> > 32, 40, 48, 56, 64, or 96.
> > (The Well-Known Prefix is 96 bits long, and can only be used
> > in the last form of the table.)
> > "
> >
> > So 40 and 56 are missing.
>
> Yes, like to add and lets accelerate the progress to abandon the old APIs :)
Please could list which part of the existing API you would like
to deprecate in future?
> > > So probably we are not wasting bits here, since this is a typical
> > > usage that DPDK can provide.
> > > Of cause more description is needed in the code here.
> > >
> > > > 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.
> > >
> > > Yes, I believe at some moment, a more generic solution is mandatory,
> > > And I think that will not work if we stick on the 64 bits, new API
> > > need to be introduced and old one should be abandoned
> > >
> > > >
> > > > > 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.
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 8, 2020 8:26 PM
> To: Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Guo, Junfeng
> <junfeng.guo@intel.com>; Su, Simei <simei.su@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; arybchenko@solarflare.com;
> viacheslavo@mellanox.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; orika@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6
> prefix
>
> 08/07/2020 14:05, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 08/07/2020 13:10, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 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@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.
> [...]
> > > > > > 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.
> > > >
> > > > Actually IPv6 address prefix is in spec, please check below RFC.
> > > > https://tools.ietf.org/html/rfc6052#page-5
> > >
> > > Quoting the RFC:
> > > "
> > > the prefix shall be either the "Well-Known Prefix"
> > > or a "Network-Specific Prefix" unique to the organization
> > > deploying the address translators.
> > > The prefixes can only have one of the following lengths:
> > > 32, 40, 48, 56, 64, or 96.
> > > (The Well-Known Prefix is 96 bits long, and can only be used
> > > in the last form of the table.)
> > > "
> > >
> > > So 40 and 56 are missing.
> >
> > Yes, like to add and lets accelerate the progress to abandon the old
> > APIs :)
>
> Please could list which part of the existing API you would like to deprecate in
> future?
I think it's a new version of rte_flow_action_rss, we need a more generic way to describe the RSS input set of a flow
But not just a 64 bits type, then all ETH_RSS_xxx will be decoupled from rte_flow.
>
>
> > > > So probably we are not wasting bits here, since this is a typical
> > > > usage that DPDK can provide.
> > > > Of cause more description is needed in the code here.
> > > >
> > > > > 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.
> > > >
> > > > Yes, I believe at some moment, a more generic solution is
> > > > mandatory, And I think that will not work if we stick on the 64
> > > > bits, new API need to be introduced and old one should be
> > > > abandoned
> > > >
> > > > >
> > > > > > 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.
>
>
08/07/2020 14:37, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 08/07/2020 14:05, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 08/07/2020 13:10, Zhang, Qi Z:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 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@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.
> > [...]
> > > > > > > 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.
> > > > >
> > > > > Actually IPv6 address prefix is in spec, please check below RFC.
> > > > > https://tools.ietf.org/html/rfc6052#page-5
> > > >
> > > > Quoting the RFC:
> > > > "
> > > > the prefix shall be either the "Well-Known Prefix"
> > > > or a "Network-Specific Prefix" unique to the organization
> > > > deploying the address translators.
> > > > The prefixes can only have one of the following lengths:
> > > > 32, 40, 48, 56, 64, or 96.
> > > > (The Well-Known Prefix is 96 bits long, and can only be used
> > > > in the last form of the table.)
> > > > "
> > > >
> > > > So 40 and 56 are missing.
> > >
> > > Yes, like to add and lets accelerate the progress to abandon the old
> > > APIs :)
> >
> > Please could list which part of the existing API you would like to deprecate in
> > future?
>
> I think it's a new version of rte_flow_action_rss, we need a more generic way to describe the RSS input set of a flow
> But not just a 64 bits type, then all ETH_RSS_xxx will be decoupled from rte_flow.
I was asking what would you deprecate?
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 8, 2020 10:29 PM
> To: Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Guo, Junfeng
> <junfeng.guo@intel.com>; Su, Simei <simei.su@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; arybchenko@solarflare.com;
> viacheslavo@mellanox.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; orika@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6
> prefix
>
> 08/07/2020 14:37, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 08/07/2020 14:05, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 08/07/2020 13:10, Zhang, Qi Z:
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 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@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.
> > > [...]
> > > > > > > > 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.
> > > > > >
> > > > > > Actually IPv6 address prefix is in spec, please check below RFC.
> > > > > > https://tools.ietf.org/html/rfc6052#page-5
> > > > >
> > > > > Quoting the RFC:
> > > > > "
> > > > > the prefix shall be either the "Well-Known Prefix"
> > > > > or a "Network-Specific Prefix" unique to the organization
> > > > > deploying the address translators.
> > > > > The prefixes can only have one of the following lengths:
> > > > > 32, 40, 48, 56, 64, or 96.
> > > > > (The Well-Known Prefix is 96 bits long, and can only be used
> > > > > in the last form of the table.) "
> > > > >
> > > > > So 40 and 56 are missing.
> > > >
> > > > Yes, like to add and lets accelerate the progress to abandon the
> > > > old APIs :)
> > >
> > > Please could list which part of the existing API you would like to
> > > deprecate in future?
> >
> > I think it's a new version of rte_flow_action_rss, we need a more
> > generic way to describe the RSS input set of a flow But not just a 64 bits
> type, then all ETH_RSS_xxx will be decoupled from rte_flow.
>
> I was asking what would you deprecate?
I think at least those ETH_RSS xxx modifiers from bottom can be deprecated, since they are only be used by rte_flow
>
@@ -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)
/**
* For input set change of hash filter, if SRC_ONLY and DST_ONLY of
@@ -561,6 +564,54 @@ rte_eth_rss_hf_refine(uint64_t rss_hf)
return rss_hf;
}
+#define ETH_RSS_IPV6_PRE32 ( \
+ ETH_RSS_IPV6 | \
+ ETH_RSS_L3_PRE32)
+
+#define ETH_RSS_IPV6_PRE48 ( \
+ ETH_RSS_IPV6 | \
+ ETH_RSS_L3_PRE48)
+
+#define ETH_RSS_IPV6_PRE64 ( \
+ ETH_RSS_IPV6 | \
+ ETH_RSS_L3_PRE64)
+
+#define ETH_RSS_IPV6_PRE32_UDP ( \
+ ETH_RSS_NONFRAG_IPV6_UDP | \
+ ETH_RSS_L3_PRE32)
+
+#define ETH_RSS_IPV6_PRE48_UDP ( \
+ ETH_RSS_NONFRAG_IPV6_UDP | \
+ ETH_RSS_L3_PRE48)
+
+#define ETH_RSS_IPV6_PRE64_UDP ( \
+ ETH_RSS_NONFRAG_IPV6_UDP | \
+ ETH_RSS_L3_PRE64)
+
+#define ETH_RSS_IPV6_PRE32_TCP ( \
+ ETH_RSS_NONFRAG_IPV6_TCP | \
+ ETH_RSS_L3_PRE32)
+
+#define ETH_RSS_IPV6_PRE48_TCP ( \
+ ETH_RSS_NONFRAG_IPV6_TCP | \
+ ETH_RSS_L3_PRE48)
+
+#define ETH_RSS_IPV6_PRE64_TCP ( \
+ ETH_RSS_NONFRAG_IPV6_TCP | \
+ ETH_RSS_L3_PRE64)
+
+#define ETH_RSS_IPV6_PRE32_SCTP ( \
+ ETH_RSS_NONFRAG_IPV6_SCTP | \
+ ETH_RSS_L3_PRE32)
+
+#define ETH_RSS_IPV6_PRE48_SCTP ( \
+ ETH_RSS_NONFRAG_IPV6_SCTP | \
+ ETH_RSS_L3_PRE48)
+
+#define ETH_RSS_IPV6_PRE64_SCTP ( \
+ ETH_RSS_NONFRAG_IPV6_SCTP | \
+ ETH_RSS_L3_PRE64)
+
#define ETH_RSS_IP ( \
ETH_RSS_IPV4 | \
ETH_RSS_FRAG_IPV4 | \