From: Thomas Monjalon <thomas@monjalon.net>
To: "Xing, Beilei" <beilei.xing@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: "dev@dpdk.org" <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" <arybchenko@solarflare.com>,
"viacheslavo@mellanox.com" <viacheslavo@mellanox.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
"orika@mellanox.com" <orika@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types for IPv6 prefix
Date: Wed, 08 Jul 2020 16:29:10 +0200 [thread overview]
Message-ID: <2222669.ed38JIK7Hh@thomas> (raw)
In-Reply-To: <039ED4275CED7440929022BC67E7061154858537@SHSMSX103.ccr.corp.intel.com>
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?
next prev parent reply other threads:[~2020-07-08 14:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 8:07 [dpdk-dev] [PATCH] net/ice: add RSS support for IPv6 prefix Junfeng Guo
2020-06-16 8:16 ` [dpdk-dev] [PATCH v2 0/3] " Junfeng Guo
2020-06-16 8:16 ` [dpdk-dev] [PATCH v2 1/3] ethdev: add new RSS types " Junfeng Guo
2020-07-06 11:59 ` Zhang, Qi Z
2020-07-07 10:20 ` Ferruh Yigit
2020-07-07 11:06 ` Thomas Monjalon
2020-07-08 9:45 ` Zhang, Qi Z
2020-07-08 9:57 ` Thomas Monjalon
2020-07-08 11:10 ` Zhang, Qi Z
2020-07-08 11:57 ` Thomas Monjalon
2020-07-08 12:05 ` Zhang, Qi Z
2020-07-08 12:26 ` Thomas Monjalon
2020-07-08 12:37 ` Zhang, Qi Z
2020-07-08 14:29 ` Thomas Monjalon [this message]
2020-07-09 0:33 ` Zhang, Qi Z
2020-06-16 8:16 ` [dpdk-dev] [PATCH v2 2/3] app/testpmd: support extended RSS offload types Junfeng Guo
2020-06-16 8:16 ` [dpdk-dev] [PATCH v2 3/3] net/ice: add RSS support for IPv6 prefix Junfeng Guo
2020-07-08 4:36 ` [dpdk-dev] [PATCH v3 0/3] " Junfeng Guo
2020-07-08 4:36 ` [dpdk-dev] [PATCH v3 1/3] ethdev: add new RSS types " Junfeng Guo
2020-07-08 4:36 ` [dpdk-dev] [PATCH v3 2/3] app/testpmd: support extended RSS offload types Junfeng Guo
2020-07-08 4:36 ` [dpdk-dev] [PATCH v3 3/3] net/ice: add RSS support for IPv6 prefix Junfeng Guo
2020-07-08 7:33 ` [dpdk-dev] [PATCH v4 0/3] " Junfeng Guo
2020-07-08 7:33 ` [dpdk-dev] [PATCH v4 1/3] ethdev: add new RSS types " Junfeng Guo
2020-07-08 7:33 ` [dpdk-dev] [PATCH v4 2/3] app/testpmd: support extended RSS offload types Junfeng Guo
2020-07-08 7:33 ` [dpdk-dev] [PATCH v4 3/3] net/ice: add RSS support for IPv6 prefix Junfeng Guo
2020-07-08 8:24 ` [dpdk-dev] [PATCH v4 0/3] " Zhang, Qi Z
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2222669.ed38JIK7Hh@thomas \
--to=thomas@monjalon.net \
--cc=ajit.khaparde@broadcom.com \
--cc=arybchenko@solarflare.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerinj@marvell.com \
--cc=jia.guo@intel.com \
--cc=junfeng.guo@intel.com \
--cc=orika@mellanox.com \
--cc=qi.z.zhang@intel.com \
--cc=simei.su@intel.com \
--cc=viacheslavo@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.