[dpdk-dev,RFC,v1,1/5] ethdev: support rss level on tunnel

Message ID 20171203060812.74932-2-xuemingl@mellanox.com
State RFC, archived
Delegated to: Ferruh Yigit
Headers show

Checks

Context Check Description
ci/Intel-compilation success Compilation OK
ci/checkpatch success coding style OK

Commit Message

Xueming(Steven) Li Dec. 3, 2017, 6:08 a.m.
There was no RSS hash fields level definition on tunnel, implementations
default RSS on tunnel to outer or inner. Adding rss level enable users
to specifiy the tunnel level of RSS hash fields.

0:  outer most,
1:  inner,
-1: inner most(PMD auto detection if nested tunnel specified in fields)

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 lib/librte_ether/rte_flow.h | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Nélio Laranjeiro Dec. 4, 2017, 8:10 a.m. | #1
Hi Xueming,

On Sun, Dec 03, 2017 at 02:08:08PM +0800, Xueming Li wrote:
> There was no RSS hash fields level definition on tunnel, implementations
> default RSS on tunnel to outer or inner. Adding rss level enable users
> to specifiy the tunnel level of RSS hash fields.
> 
> 0:  outer most,
> 1:  inner,
> -1: inner most(PMD auto detection if nested tunnel specified in fields)
> 
> Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> ---
>  lib/librte_ether/rte_flow.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 47c88ea52..41ab91912 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -1078,6 +1078,14 @@ struct rte_flow_action_dup {
>   */
>  struct rte_flow_action_rss {
>  	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?

> +	uint8_t level;
>  	uint16_t num; /**< Number of entries in queue[]. */
>  	uint16_t queue[]; /**< Queues indices to use. */
>  };
> -- 
> 2.13.3
> 

Thanks,
Xueming(Steven) Li Dec. 4, 2017, 9:05 a.m. | #2
> -----Original Message-----

> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]

> Sent: Monday, December 4, 2017 4:11 PM

> To: Xueming(Steven) Li <xuemingl@mellanox.com>

> Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon

> <thomas@monjalon.net>; dev@dpdk.org

> Subject: Re: [RFC v1 1/5] ethdev: support rss level on tunnel

> 

> Hi Xueming,

> 

> On Sun, Dec 03, 2017 at 02:08:08PM +0800, Xueming Li wrote:

> > There was no RSS hash fields level definition on tunnel,

> > implementations default RSS on tunnel to outer or inner. Adding rss

> > level enable users to specifiy the tunnel level of RSS hash fields.

> >

> > 0:  outer most,

> > 1:  inner,

> > -1: inner most(PMD auto detection if nested tunnel specified in

> > fields)

> >

> > Signed-off-by: Xueming Li <xuemingl@mellanox.com>

> > ---

> >  lib/librte_ether/rte_flow.h | 8 ++++++++

> >  1 file changed, 8 insertions(+)

> >

> > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h

> > index 47c88ea52..41ab91912 100644

> > --- a/lib/librte_ether/rte_flow.h

> > +++ b/lib/librte_ether/rte_flow.h

> > @@ -1078,6 +1078,14 @@ struct rte_flow_action_dup {

> >   */

> >  struct rte_flow_action_rss {

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

> 

> > +	uint8_t level;

> >  	uint16_t num; /**< Number of entries in queue[]. */

> >  	uint16_t queue[]; /**< Queues indices to use. */  };

> > --

> > 2.13.3

> >

> 

> Thanks,

> 

> --

> Nélio Laranjeiro

> 6WIND
Nélio Laranjeiro Dec. 4, 2017, 10:32 a.m. | #3
Xueming,

On Mon, Dec 04, 2017 at 09:05:22AM +0000, Xueming(Steven) Li wrote:
> 
> > -----Original Message-----
> > From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Sent: Monday, December 4, 2017 4:11 PM
> > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon
> > <thomas@monjalon.net>; dev@dpdk.org
> > Subject: Re: [RFC v1 1/5] ethdev: support rss level on tunnel
> > 
> > Hi Xueming,
> > 
> > On Sun, Dec 03, 2017 at 02:08:08PM +0800, Xueming Li wrote:
> > > There was no RSS hash fields level definition on tunnel,
> > > implementations default RSS on tunnel to outer or inner. Adding rss
> > > level enable users to specifiy the tunnel level of RSS hash fields.
> > >
> > > 0:  outer most,
> > > 1:  inner,
> > > -1: inner most(PMD auto detection if nested tunnel specified in
> > > fields)
> > >
> > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > ---
> > >  lib/librte_ether/rte_flow.h | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> > > index 47c88ea52..41ab91912 100644
> > > --- a/lib/librte_ether/rte_flow.h
> > > +++ b/lib/librte_ether/rte_flow.h
> > > @@ -1078,6 +1078,14 @@ struct rte_flow_action_dup {
> > >   */
> > >  struct rte_flow_action_rss {
> > >  	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?

Thanks,
Xueming(Steven) Li Dec. 4, 2017, 2:24 p.m. | #4
> -----Original Message-----

> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]

> Sent: Monday, December 4, 2017 6:33 PM

> To: Xueming(Steven) Li <xuemingl@mellanox.com>

> Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon

> <thomas@monjalon.net>; dev@dpdk.org

> Subject: Re: [RFC v1 1/5] ethdev: support rss level on tunnel

> 

> Xueming,

> 

> On Mon, Dec 04, 2017 at 09:05:22AM +0000, Xueming(Steven) Li wrote:

> >

> > > -----Original Message-----

> > > From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]

> > > Sent: Monday, December 4, 2017 4:11 PM

> > > To: Xueming(Steven) Li <xuemingl@mellanox.com>

> > > Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon

> > > <thomas@monjalon.net>; dev@dpdk.org

> > > Subject: Re: [RFC v1 1/5] ethdev: support rss level on tunnel

> > >

> > > Hi Xueming,

> > >

> > > On Sun, Dec 03, 2017 at 02:08:08PM +0800, Xueming Li wrote:

> > > > There was no RSS hash fields level definition on tunnel,

> > > > implementations default RSS on tunnel to outer or inner. Adding

> > > > rss level enable users to specifiy the tunnel level of RSS hash

> fields.

> > > >

> > > > 0:  outer most,

> > > > 1:  inner,

> > > > -1: inner most(PMD auto detection if nested tunnel specified in

> > > > fields)

> > > >

> > > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>

> > > > ---

> > > >  lib/librte_ether/rte_flow.h | 8 ++++++++

> > > >  1 file changed, 8 insertions(+)

> > > >

> > > > diff --git a/lib/librte_ether/rte_flow.h

> > > > b/lib/librte_ether/rte_flow.h index 47c88ea52..41ab91912 100644

> > > > --- a/lib/librte_ether/rte_flow.h

> > > > +++ b/lib/librte_ether/rte_flow.h

> > > > @@ -1078,6 +1078,14 @@ struct rte_flow_action_dup {

> > > >   */

> > > >  struct rte_flow_action_rss {

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

> Thanks,

> 

> --

> Nélio Laranjeiro

> 6WIND
Nélio Laranjeiro Dec. 4, 2017, 3 p.m. | #5
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,

Patch

diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 47c88ea52..41ab91912 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1078,6 +1078,14 @@  struct rte_flow_action_dup {
  */
 struct rte_flow_action_rss {
 	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
+	 */
+	uint8_t level;
 	uint16_t num; /**< Number of entries in queue[]. */
 	uint16_t queue[]; /**< Queues indices to use. */
 };