From: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
To: "Xueming(Steven) Li" <xuemingl@mellanox.com>
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Thomas Monjalon <thomas@monjalon.net>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC v1 1/5] ethdev: support rss level on tunnel
Date: Mon, 4 Dec 2017 16:00:09 +0100 [thread overview]
Message-ID: <20171204150009.ufxc3uyrorpojre2@laranjeiro-vm.dev.6wind.com> (raw)
In-Reply-To: <AM6PR0502MB407096A95867CF2DBB5B5ACAAC3C0@AM6PR0502MB4070.eurprd05.prod.outlook.com>
On Mon, Dec 04, 2017 at 02:24:53PM +0000, Xueming(Steven) Li wrote:
>
<snip>
> > > > > const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters.
> > */
> > > > > + /**
> > > > > + * RSS on tunnel level:
> > > > > + * 0: outer RSS
> > > > > + * 1: inner RSS
> > > > > + * 2-254: deep inner tunnel level RSS
> > > > > + * -1: inner most level according to flow pattern
> > > > > + */
> > > >
> > > > Not clear enough, some PMD like MLX5 accept rules starting from the
> > > > VXLAN level, the comment "Inner most level according to flow pattern"
> > > > does not inform inside which tunnel the RSS will be done as this
> > > > pattern does not provide any information related to the position of
> > > > the tunnel in the packet.
> > > > What are the expectation for such situation?
> > > Regarding to supported tunnel types, VXLAN, L3VXLAN, GRE or GENEVE as
> > > long as the PMD supports. RTE_PTYPE_TUNNEL_MASK is a good mask of
> > > supported tunnel types.
> >
> > Seems you did not understood my question, if I set a flow rule as
> >
> > flow create 0 ingress vxlan / end action rss level -1 queues 0 1 end /
> > end
> >
> > According to your definition: "inner most level according to flow pattern"
> > in my example, the pattern does not provide any "level", this rule can
> > match the first level as the 254th as well, this leads to an undefined
> > situation when using level = -1.
> >
> > What is your expectation in such situation?
> >
> This rule looks a little confused to users, it covers fowling cases?
> Vxlan
> Gre/vxlan
> Vxlan/vxlan/vxlan
For my understanding, what I expect from this rule is an RSS spreading
on the inner *most* tunnel. If the NIC was recognising at most 4
tunnels in the packet, it would mean RSS on the 4th tunnel, i.e. an
equivalent to:
vxlan / end actions rss level 4 queues 0 1 end / end
> Auto rss level detection will get 1,2,3 for each of above examples from
> Pattern in a left to right order, based on what defined in pattern.
> Users has to define tunnel pattern one by one exactly.
>
> Actually we seldom see real requirement beyond inner tunnel, the auto-
> detection could be abandoned if it conflict with existing definition.
I agree on this last one, if the definition is not clear enough
(multiple interpretation in this case), it is better to not expose such
functionality.
Thanks,
--
Nélio Laranjeiro
6WIND
next prev parent reply other threads:[~2017-12-04 14:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 17:31 [dpdk-dev] [RFC 0/4] tunnel enhancements Xueming Li
2017-11-29 17:31 ` [dpdk-dev] [RFC 1/4] ethdev: support rss level on tunnel Xueming Li
2017-11-30 8:16 ` Nelio Laranjeiro
2017-11-30 8:46 ` Xueming(Steven) Li
2017-11-30 10:14 ` Nelio Laranjeiro
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 0/5] tunnel enhancements Xueming Li
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 1/5] ethdev: support rss level on tunnel Xueming Li
2017-12-04 8:10 ` Nelio Laranjeiro
2017-12-04 9:05 ` Xueming(Steven) Li
2017-12-04 10:32 ` Nelio Laranjeiro
2017-12-04 14:24 ` Xueming(Steven) Li
2017-12-04 15:00 ` Nelio Laranjeiro [this message]
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 2/5] app/testpmd: support rte_flow rss level parsing Xueming Li
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 3/5] ethdev: support GRE and L3VXLAN tunnel type Xueming Li
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 4/5] app/testpmd: support l3vxlan " Xueming Li
2017-12-03 6:08 ` [dpdk-dev] [RFC v1 5/5] mbuf: add L3 VXLAN packet type Xueming Li
2017-11-29 17:31 ` [dpdk-dev] [RFC 2/4] app/testpmd: support rte_flow rss level parsing Xueming Li
2017-11-30 8:18 ` Nelio Laranjeiro
2017-11-30 8:50 ` Xueming(Steven) Li
2017-11-30 10:13 ` Nelio Laranjeiro
2017-11-29 17:31 ` [dpdk-dev] [RFC 3/4] ethdev: support GRE and L3VXLAN tunnel type Xueming Li
2017-11-29 17:31 ` [dpdk-dev] [RFC 4/4] app/testpmd: support l3vxlan " Xueming Li
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=20171204150009.ufxc3uyrorpojre2@laranjeiro-vm.dev.6wind.com \
--to=nelio.laranjeiro@6wind.com \
--cc=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
--cc=xuemingl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).