[dpdk-dev] [RFC 0/4] tunnel enhancements

[dpdk-dev] [RFC 0/4] tunnel enhancements

[Xueming Li]

Some tunnel enhancements:
1. support GRE tunnel type 
2. support L3 VXLAN tunnel type - no inner L2 header
3. introduce RSS tunnel level into rte_flow_action_rss
   RSS on inner or outer tunnel headers
4. implementation of rss tunnel level parsing in testpmd

Xueming Li (4):
  ethdev: support rss level on tunnel
  app/testpmd: support rte_flow rss level parsing
  ethdev: support GRE and L3VXLAN tunnel type
  app/testpmd: support l3vxlan tunnel type

 app/test-pmd/cmdline_flow.c     | 23 ++++++++++++++++++++++-
 lib/librte_ether/rte_eth_ctrl.h |  4 +++-
 lib/librte_ether/rte_ethdev.h   |  2 ++
 lib/librte_ether/rte_flow.c     |  1 +
 lib/librte_ether/rte_flow.h     |  8 ++++++++
 5 files changed, 36 insertions(+), 2 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [RFC 1/4] ethdev: support rss level on tunnel

[Xueming Li]

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 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 47c88ea..c35558c 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1078,6 +1078,7 @@ struct rte_flow_action_dup {
  */
 struct rte_flow_action_rss {
 	const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
+	uint8_t level; /**< RSS on tunnel level, 0:outer most, -1:inner most */
 	uint16_t num; /**< Number of entries in queue[]. */
 	uint16_t queue[]; /**< Queues indices to use. */
 };
-- 
1.8.3.1

[dpdk-dev] [RFC 2/4] app/testpmd: support rte_flow rss level parsing

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 app/test-pmd/cmdline_flow.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index df16d2a..9402eb7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -194,6 +194,7 @@ enum index {
 	ACTION_RSS,
 	ACTION_RSS_QUEUES,
 	ACTION_RSS_QUEUE,
+	ACTION_RSS_LEVEL,
 	ACTION_PF,
 	ACTION_VF,
 	ACTION_VF_ORIGINAL,
@@ -640,6 +641,7 @@ struct parse_action_priv {
 
 static const enum index action_rss[] = {
 	ACTION_RSS_QUEUES,
+	ACTION_RSS_LEVEL,
 	ACTION_NEXT,
 	ZERO,
 };
@@ -1586,6 +1588,13 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
 		.call = parse_vc_action_rss_queue,
 		.comp = comp_vc_action_rss_queue,
 	},
+	[ACTION_RSS_LEVEL] = {
+		.name = "level",
+		.help = "rss on tunnel level",
+		.next = NEXT(action_rss, NEXT_ENTRY(UNSIGNED)),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_rss, level)),
+		.call = parse_vc_conf,
+	},
 	[ACTION_PF] = {
 		.name = "pf",
 		.help = "redirect packets to physical device function",
@@ -1887,6 +1896,7 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
 					       sizeof(double));
 		if ((uint8_t *)item + sizeof(*item) > data)
 			return -1;
+		memset(data, 0, data_size);
 		*item = (struct rte_flow_item){
 			.type = priv->type,
 		};
@@ -1904,6 +1914,9 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
 					       sizeof(double));
 		if ((uint8_t *)action + sizeof(*action) > data)
 			return -1;
+		memset(data, 0, data_size);
+		if (priv->type == RTE_FLOW_ACTION_TYPE_RSS)
+			((struct rte_flow_action_rss *)data)->level = -1;
 		*action = (struct rte_flow_action){
 			.type = priv->type,
 		};
@@ -1911,7 +1924,6 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
 		ctx->object = action;
 		ctx->objmask = NULL;
 	}
-	memset(data, 0, data_size);
 	out->args.vc.data = data;
 	ctx->objdata = data_size;
 	return len;
-- 
1.8.3.1

[dpdk-dev] [RFC 3/4] ethdev: support GRE and L3VXLAN tunnel type

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 lib/librte_ether/rte_eth_ctrl.h | 4 +++-
 lib/librte_ether/rte_ethdev.h   | 2 ++
 lib/librte_ether/rte_flow.c     | 1 +
 lib/librte_ether/rte_flow.h     | 7 +++++++
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 8386904..ce111ad 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -83,7 +83,9 @@
 #define RTE_ETH_FLOW_VXLAN              19 /**< VXLAN protocol based flow */
 #define RTE_ETH_FLOW_GENEVE             20 /**< GENEVE protocol based flow */
 #define RTE_ETH_FLOW_NVGRE              21 /**< NVGRE protocol based flow */
-#define RTE_ETH_FLOW_MAX                22
+#define RTE_ETH_FLOW_L3VXLAN            22 /**< L3-VXLAN protocol based flow */
+#define RTE_ETH_FLOW_GRE                23 /**< GRE protocol based flow */
+#define RTE_ETH_FLOW_MAX                24
 
 /**
  * Feature filter types
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 341c2d6..baacc70 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -453,6 +453,8 @@ struct rte_eth_rss_conf {
 #define ETH_RSS_VXLAN              (1ULL << RTE_ETH_FLOW_VXLAN)
 #define ETH_RSS_GENEVE             (1ULL << RTE_ETH_FLOW_GENEVE)
 #define ETH_RSS_NVGRE              (1ULL << RTE_ETH_FLOW_NVGRE)
+#define ETH_RSS_L3VXLAN            (1ULL << RTE_ETH_FLOW_L3VXLAN)
+#define ETH_RSS_GRE                (1ULL << RTE_ETH_FLOW_GRE)
 
 #define ETH_RSS_IP ( \
 	ETH_RSS_IPV4 | \
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index 6659063..44d8391 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -81,6 +81,7 @@ struct rte_flow_desc_data {
 	MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
 	MK_FLOW_ITEM(E_TAG, sizeof(struct rte_flow_item_e_tag)),
 	MK_FLOW_ITEM(NVGRE, sizeof(struct rte_flow_item_nvgre)),
+	MK_FLOW_ITEM(L3VXLAN, sizeof(struct rte_flow_item_vxlan)),
 };
 
 /** Generate flow_action[] entry. */
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index c35558c..78c6d5c 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -300,6 +300,13 @@ enum rte_flow_item_type {
 	RTE_FLOW_ITEM_TYPE_GRE,
 
 	/**
+	 * Matches a L3-VXLAN header.
+	 *
+	 * See struct rte_flow_item_vxlan.
+	 */
+	RTE_FLOW_ITEM_TYPE_L3VXLAN,
+
+	/**
 	 * [META]
 	 *
 	 * Fuzzy pattern match, expect faster than default.
-- 
1.8.3.1

[dpdk-dev] [RFC 4/4] app/testpmd: support l3vxlan tunnel type

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 app/test-pmd/cmdline_flow.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 9402eb7..762ab2c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -160,6 +160,7 @@ enum index {
 	ITEM_SCTP_TAG,
 	ITEM_SCTP_CKSUM,
 	ITEM_VXLAN,
+	ITEM_L3VXLAN,
 	ITEM_VXLAN_VNI,
 	ITEM_E_TAG,
 	ITEM_E_TAG_GRP_ECID_B,
@@ -453,6 +454,7 @@ struct parse_action_priv {
 	ITEM_TCP,
 	ITEM_SCTP,
 	ITEM_VXLAN,
+	ITEM_L3VXLAN,
 	ITEM_E_TAG,
 	ITEM_NVGRE,
 	ITEM_MPLS,
@@ -1367,6 +1369,13 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
 		.next = NEXT(item_vxlan),
 		.call = parse_vc,
 	},
+	[ITEM_L3VXLAN] = {
+		.name = "l3vxlan",
+		.help = "match L3VXLAN header",
+		.priv = PRIV_ITEM(L3VXLAN, sizeof(struct rte_flow_item_vxlan)),
+		.next = NEXT(item_vxlan),
+		.call = parse_vc,
+	},
 	[ITEM_VXLAN_VNI] = {
 		.name = "vni",
 		.help = "VXLAN identifier",
-- 
1.8.3.1

Re: [dpdk-dev] [RFC 1/4] ethdev: support rss level on tunnel

[Nelio Laranjeiro]

Hi Xueming, please see the comments below,

On Thu, Nov 30, 2017 at 01:31:03AM +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)

This *inner most* is confusing, what does it mean for the following
pattern vxlan / end?
This pattern is valid for any level of the VXLAN according to the NIC
capability.  With an inner most, if the PMD support 4 levels of tunnels
it will need to create the 4 rules to match the user request.
Is this what you expect by this definition?

There is also another question, according to the possible values (0, 1,
-1), it cannot handle more than 1 level explicitly, why such limitation?

> Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> ---
>  lib/librte_ether/rte_flow.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 47c88ea..c35558c 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -1078,6 +1078,7 @@ struct rte_flow_action_dup {
>   */
>  struct rte_flow_action_rss {
>  	const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> +	uint8_t level; /**< RSS on tunnel level, 0:outer most, -1:inner most */
>  	uint16_t num; /**< Number of entries in queue[]. */
>  	uint16_t queue[]; /**< Queues indices to use. */
>  };
> -- 
> 1.8.3.1
> 

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [RFC 2/4] app/testpmd: support rte_flow rss level parsing

[Nelio Laranjeiro]

Hi Xueming,

On Thu, Nov 30, 2017 at 01:31:04AM +0800, Xueming Li wrote:
> Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> ---
>  app/test-pmd/cmdline_flow.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index df16d2a..9402eb7 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -194,6 +194,7 @@ enum index {
>  	ACTION_RSS,
>  	ACTION_RSS_QUEUES,
>  	ACTION_RSS_QUEUE,
> +	ACTION_RSS_LEVEL,
>  	ACTION_PF,
>  	ACTION_VF,
>  	ACTION_VF_ORIGINAL,
> @@ -640,6 +641,7 @@ struct parse_action_priv {
>  
>  static const enum index action_rss[] = {
>  	ACTION_RSS_QUEUES,
> +	ACTION_RSS_LEVEL,
>  	ACTION_NEXT,
>  	ZERO,
>  };
> @@ -1586,6 +1588,13 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
>  		.call = parse_vc_action_rss_queue,
>  		.comp = comp_vc_action_rss_queue,
>  	},
> +	[ACTION_RSS_LEVEL] = {
> +		.name = "level",
> +		.help = "rss on tunnel level",
> +		.next = NEXT(action_rss, NEXT_ENTRY(UNSIGNED)),
> +		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_rss, level)),
> +		.call = parse_vc_conf,
> +	},
>  	[ACTION_PF] = {
>  		.name = "pf",
>  		.help = "redirect packets to physical device function",
> @@ -1887,6 +1896,7 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
>  					       sizeof(double));
>  		if ((uint8_t *)item + sizeof(*item) > data)
>  			return -1;
> +		memset(data, 0, data_size);
>  		*item = (struct rte_flow_item){
>  			.type = priv->type,
>  		};
> @@ -1904,6 +1914,9 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
>  					       sizeof(double));
>  		if ((uint8_t *)action + sizeof(*action) > data)
>  			return -1;
> +		memset(data, 0, data_size);
> +		if (priv->type == RTE_FLOW_ACTION_TYPE_RSS)
> +			((struct rte_flow_action_rss *)data)->level = -1;

I strongly suggest to let the level set to outer, otherwise most of the
PMD will have to refuse such rule.

>  		*action = (struct rte_flow_action){
>  			.type = priv->type,
>  		};
> @@ -1911,7 +1924,6 @@ static int comp_vc_action_rss_queue(struct context *, const struct token *,
>  		ctx->object = action;
>  		ctx->objmask = NULL;
>  	}
> -	memset(data, 0, data_size);
>  	out->args.vc.data = data;
>  	ctx->objdata = data_size;
>  	return len;
> -- 
> 1.8.3.1
> 

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [RFC 1/4] ethdev: support rss level on tunnel

[Xueming(Steven) Li]

Thanks for feedback, comments inline:

> -----Original Message-----
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Thursday, November 30, 2017 4:16 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 1/4] ethdev: support rss level on tunnel
> 
> Hi Xueming, please see the comments below,
> 
> On Thu, Nov 30, 2017 at 01:31:03AM +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)
> 
> This *inner most* is confusing, what does it mean for the following
> pattern vxlan / end?
> This pattern is valid for any level of the VXLAN according to the NIC
> capability.  With an inner most, if the PMD support 4 levels of tunnels it
> will need to create the 4 rules to match the user request.
> Is this what you expect by this definition?
Yes, auto detection according to tunnel spec. Users could always specify a 
concrete value, 4 for this example.

> 
> There is also another question, according to the possible values (0, 1, -
> 1), it cannot handle more than 1 level explicitly, why such limitation?
They are just typical values, any value between 0-255 is acceptable.

> 
> > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > ---
> >  lib/librte_ether/rte_flow.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> > index 47c88ea..c35558c 100644
> > --- a/lib/librte_ether/rte_flow.h
> > +++ b/lib/librte_ether/rte_flow.h
> > @@ -1078,6 +1078,7 @@ struct rte_flow_action_dup {
> >   */
> >  struct rte_flow_action_rss {
> >  	const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> > +	uint8_t level; /**< RSS on tunnel level, 0:outer most, -1:inner most
> > +*/
> >  	uint16_t num; /**< Number of entries in queue[]. */
> >  	uint16_t queue[]; /**< Queues indices to use. */  };
> > --
> > 1.8.3.1
> >
> 
> Thanks,
> 
> --
> Nélio Laranjeiro
> 6WIND

Re: [dpdk-dev] [RFC 2/4] app/testpmd: support rte_flow rss level parsing

[Xueming(Steven) Li]

> -----Original Message-----
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Thursday, November 30, 2017 4:18 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 2/4] app/testpmd: support rte_flow rss level parsing
> 
> Hi Xueming,
> 
> On Thu, Nov 30, 2017 at 01:31:04AM +0800, Xueming Li wrote:
> > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > ---
> >  app/test-pmd/cmdline_flow.c | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index df16d2a..9402eb7 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -194,6 +194,7 @@ enum index {
> >  	ACTION_RSS,
> >  	ACTION_RSS_QUEUES,
> >  	ACTION_RSS_QUEUE,
> > +	ACTION_RSS_LEVEL,
> >  	ACTION_PF,
> >  	ACTION_VF,
> >  	ACTION_VF_ORIGINAL,
> > @@ -640,6 +641,7 @@ struct parse_action_priv {
> >
> >  static const enum index action_rss[] = {
> >  	ACTION_RSS_QUEUES,
> > +	ACTION_RSS_LEVEL,
> >  	ACTION_NEXT,
> >  	ZERO,
> >  };
> > @@ -1586,6 +1588,13 @@ static int comp_vc_action_rss_queue(struct
> context *, const struct token *,
> >  		.call = parse_vc_action_rss_queue,
> >  		.comp = comp_vc_action_rss_queue,
> >  	},
> > +	[ACTION_RSS_LEVEL] = {
> > +		.name = "level",
> > +		.help = "rss on tunnel level",
> > +		.next = NEXT(action_rss, NEXT_ENTRY(UNSIGNED)),
> > +		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_rss, level)),
> > +		.call = parse_vc_conf,
> > +	},
> >  	[ACTION_PF] = {
> >  		.name = "pf",
> >  		.help = "redirect packets to physical device function", @@ -
> 1887,6
> > +1896,7 @@ static int comp_vc_action_rss_queue(struct context *, const
> struct token *,
> >  					       sizeof(double));
> >  		if ((uint8_t *)item + sizeof(*item) > data)
> >  			return -1;
> > +		memset(data, 0, data_size);
> >  		*item = (struct rte_flow_item){
> >  			.type = priv->type,
> >  		};
> > @@ -1904,6 +1914,9 @@ static int comp_vc_action_rss_queue(struct context
> *, const struct token *,
> >  					       sizeof(double));
> >  		if ((uint8_t *)action + sizeof(*action) > data)
> >  			return -1;
> > +		memset(data, 0, data_size);
> > +		if (priv->type == RTE_FLOW_ACTION_TYPE_RSS)
> > +			((struct rte_flow_action_rss *)data)->level = -1;
> 
> I strongly suggest to let the level set to outer, otherwise most of the
> PMD will have to refuse such rule.
Default to outer rss? Would be glad to hear more suggestion on this.

> 
> >  		*action = (struct rte_flow_action){
> >  			.type = priv->type,
> >  		};
> > @@ -1911,7 +1924,6 @@ static int comp_vc_action_rss_queue(struct context
> *, const struct token *,
> >  		ctx->object = action;
> >  		ctx->objmask = NULL;
> >  	}
> > -	memset(data, 0, data_size);
> >  	out->args.vc.data = data;
> >  	ctx->objdata = data_size;
> >  	return len;
> > --
> > 1.8.3.1
> >
> 
> --
> Nélio Laranjeiro
> 6WIND

Re: [dpdk-dev] [RFC 2/4] app/testpmd: support rte_flow rss level parsing

[Nelio Laranjeiro]

On Thu, Nov 30, 2017 at 08:50:13AM +0000, Xueming(Steven) Li wrote:
> 
> 
> > -----Original Message-----
> > From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Sent: Thursday, November 30, 2017 4:18 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 2/4] app/testpmd: support rte_flow rss level parsing
> > 
> > Hi Xueming,
> > 
> > On Thu, Nov 30, 2017 at 01:31:04AM +0800, Xueming Li wrote:
> > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > ---
> > >  app/test-pmd/cmdline_flow.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > > index df16d2a..9402eb7 100644
> > > --- a/app/test-pmd/cmdline_flow.c
> > > +++ b/app/test-pmd/cmdline_flow.c
> > > @@ -194,6 +194,7 @@ enum index {
> > >  	ACTION_RSS,
> > >  	ACTION_RSS_QUEUES,
> > >  	ACTION_RSS_QUEUE,
> > > +	ACTION_RSS_LEVEL,
> > >  	ACTION_PF,
> > >  	ACTION_VF,
> > >  	ACTION_VF_ORIGINAL,
> > > @@ -640,6 +641,7 @@ struct parse_action_priv {
> > >
> > >  static const enum index action_rss[] = {
> > >  	ACTION_RSS_QUEUES,
> > > +	ACTION_RSS_LEVEL,
> > >  	ACTION_NEXT,
> > >  	ZERO,
> > >  };
> > > @@ -1586,6 +1588,13 @@ static int comp_vc_action_rss_queue(struct
> > context *, const struct token *,
> > >  		.call = parse_vc_action_rss_queue,
> > >  		.comp = comp_vc_action_rss_queue,
> > >  	},
> > > +	[ACTION_RSS_LEVEL] = {
> > > +		.name = "level",
> > > +		.help = "rss on tunnel level",
> > > +		.next = NEXT(action_rss, NEXT_ENTRY(UNSIGNED)),
> > > +		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_rss, level)),
> > > +		.call = parse_vc_conf,
> > > +	},
> > >  	[ACTION_PF] = {
> > >  		.name = "pf",
> > >  		.help = "redirect packets to physical device function", @@ -
> > 1887,6
> > > +1896,7 @@ static int comp_vc_action_rss_queue(struct context *, const
> > struct token *,
> > >  					       sizeof(double));
> > >  		if ((uint8_t *)item + sizeof(*item) > data)
> > >  			return -1;
> > > +		memset(data, 0, data_size);
> > >  		*item = (struct rte_flow_item){
> > >  			.type = priv->type,
> > >  		};
> > > @@ -1904,6 +1914,9 @@ static int comp_vc_action_rss_queue(struct context
> > *, const struct token *,
> > >  					       sizeof(double));
> > >  		if ((uint8_t *)action + sizeof(*action) > data)
> > >  			return -1;
> > > +		memset(data, 0, data_size);
> > > +		if (priv->type == RTE_FLOW_ACTION_TYPE_RSS)
> > > +			((struct rte_flow_action_rss *)data)->level = -1;
> > 
> > I strongly suggest to let the level set to outer, otherwise most of the
> > PMD will have to refuse such rule.
> Default to outer rss? Would be glad to hear more suggestion on this.

The point is, not a single NIC will react the same way with testpmd with
such value as default.
NIC with RSS inner capability will start spreading tunnel packets
differently than the other who don't have it.
Default value should be set to have the same default on all NIC.

> > >  		*action = (struct rte_flow_action){
> > >  			.type = priv->type,
> > >  		};
> > > @@ -1911,7 +1924,6 @@ static int comp_vc_action_rss_queue(struct context
> > *, const struct token *,
> > >  		ctx->object = action;
> > >  		ctx->objmask = NULL;
> > >  	}
> > > -	memset(data, 0, data_size);
> > >  	out->args.vc.data = data;
> > >  	ctx->objdata = data_size;
> > >  	return len;
> > > --
> > > 1.8.3.1

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [RFC 1/4] ethdev: support rss level on tunnel

[Nelio Laranjeiro]

On Thu, Nov 30, 2017 at 08:46:51AM +0000, Xueming(Steven) Li wrote:
> Thanks for feedback, comments inline:
> 
> > -----Original Message-----
> > From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Sent: Thursday, November 30, 2017 4:16 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 1/4] ethdev: support rss level on tunnel
> > 
> > Hi Xueming, please see the comments below,
> > 
> > On Thu, Nov 30, 2017 at 01:31:03AM +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)
> > 
> > This *inner most* is confusing, what does it mean for the following
> > pattern vxlan / end?
> > This pattern is valid for any level of the VXLAN according to the NIC
> > capability.  With an inner most, if the PMD support 4 levels of tunnels it
> > will need to create the 4 rules to match the user request.
> > Is this what you expect by this definition?
> Yes, auto detection according to tunnel spec. Users could always specify a 
> concrete value, 4 for this example.

Such value must be used with care to avoid colliding rules, you should
document it.

> > 
> > There is also another question, according to the possible values (0, 1, -
> > 1), it cannot handle more than 1 level explicitly, why such limitation?
> They are just typical values, any value between 0-255 is acceptable.

Not really, according to your answer 255 is reserved for a special
definition i.e. ìnner most.  It does not mean make RSS on the 254th
tunnel.

Please update the documentation of such value with the correct possible
values and create a define for the *special* case, people implementing
such API needs to have a clear explanation on what it does.

> > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > ---
> > >  lib/librte_ether/rte_flow.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> > > index 47c88ea..c35558c 100644
> > > --- a/lib/librte_ether/rte_flow.h
> > > +++ b/lib/librte_ether/rte_flow.h
> > > @@ -1078,6 +1078,7 @@ struct rte_flow_action_dup {
> > >   */
> > >  struct rte_flow_action_rss {
> > >  	const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> > > +	uint8_t level; /**< RSS on tunnel level, 0:outer most, -1:inner most
> > > +*/
> > >  	uint16_t num; /**< Number of entries in queue[]. */
> > >  	uint16_t queue[]; /**< Queues indices to use. */  };
> > > --
> > > 1.8.3.1
> > >
> > 
> > Thanks,
> > 
> > --
> > Nélio Laranjeiro
> > 6WIND

-- 
Nélio Laranjeiro
6WIND

[dpdk-dev] [RFC v1 0/5] tunnel enhancements

[Xueming Li]

Some tunnel enhancements:
1. support GRE tunnel type
2. support L3 VXLAN tunnel type - no inner L2 header
3. introduce RSS tunnel level into rte_flow_action_rss
   RSS on inner or outer tunnel headers
4. implementation of rss tunnel level parsing in testpmd

v2:
1. Change rss default level to 0 in testpmd CLI parsing
2. Add more comments on RSS level
3. Add L3VXLAN to mbuf ptype

Xueming Li (5):
  ethdev: support rss level on tunnel
  app/testpmd: support rte_flow rss level parsing
  ethdev: support GRE and L3VXLAN tunnel type
  app/testpmd: support l3vxlan tunnel type
  mbuf: add L3 VXLAN packet type

 app/test-pmd/cmdline_flow.c      | 18 ++++++++++++++++++
 app/test-pmd/config.c            |  3 +++
 lib/librte_ether/rte_eth_ctrl.h  |  4 +++-
 lib/librte_ether/rte_ethdev.h    |  2 ++
 lib/librte_ether/rte_flow.c      |  1 +
 lib/librte_ether/rte_flow.h      | 15 +++++++++++++++
 lib/librte_mbuf/rte_mbuf_ptype.c |  1 +
 lib/librte_mbuf/rte_mbuf_ptype.h | 13 +++++++++++++
 8 files changed, 56 insertions(+), 1 deletion(-)

-- 
2.13.3

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

[Xueming Li]

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

[dpdk-dev] [RFC v1 2/5] app/testpmd: support rte_flow rss level parsing

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 app/test-pmd/cmdline_flow.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index df16d2ab9..1d1835ad6 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -194,6 +194,7 @@ enum index {
 	ACTION_RSS,
 	ACTION_RSS_QUEUES,
 	ACTION_RSS_QUEUE,
+	ACTION_RSS_LEVEL,
 	ACTION_PF,
 	ACTION_VF,
 	ACTION_VF_ORIGINAL,
@@ -640,6 +641,7 @@ static const enum index action_dup[] = {
 
 static const enum index action_rss[] = {
 	ACTION_RSS_QUEUES,
+	ACTION_RSS_LEVEL,
 	ACTION_NEXT,
 	ZERO,
 };
@@ -1586,6 +1588,13 @@ static const struct token token_list[] = {
 		.call = parse_vc_action_rss_queue,
 		.comp = comp_vc_action_rss_queue,
 	},
+	[ACTION_RSS_LEVEL] = {
+		.name = "level",
+		.help = "rss on tunnel level",
+		.next = NEXT(action_rss, NEXT_ENTRY(UNSIGNED)),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_rss, level)),
+		.call = parse_vc_conf,
+	},
 	[ACTION_PF] = {
 		.name = "pf",
 		.help = "redirect packets to physical device function",
-- 
2.13.3

[dpdk-dev] [RFC v1 3/5] ethdev: support GRE and L3VXLAN tunnel type

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 lib/librte_ether/rte_eth_ctrl.h | 4 +++-
 lib/librte_ether/rte_ethdev.h   | 2 ++
 lib/librte_ether/rte_flow.c     | 1 +
 lib/librte_ether/rte_flow.h     | 7 +++++++
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 838690424..ce111ade2 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -83,7 +83,9 @@ extern "C" {
 #define RTE_ETH_FLOW_VXLAN              19 /**< VXLAN protocol based flow */
 #define RTE_ETH_FLOW_GENEVE             20 /**< GENEVE protocol based flow */
 #define RTE_ETH_FLOW_NVGRE              21 /**< NVGRE protocol based flow */
-#define RTE_ETH_FLOW_MAX                22
+#define RTE_ETH_FLOW_L3VXLAN            22 /**< L3-VXLAN protocol based flow */
+#define RTE_ETH_FLOW_GRE                23 /**< GRE protocol based flow */
+#define RTE_ETH_FLOW_MAX                24
 
 /**
  * Feature filter types
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 341c2d624..baacc7093 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -453,6 +453,8 @@ struct rte_eth_rss_conf {
 #define ETH_RSS_VXLAN              (1ULL << RTE_ETH_FLOW_VXLAN)
 #define ETH_RSS_GENEVE             (1ULL << RTE_ETH_FLOW_GENEVE)
 #define ETH_RSS_NVGRE              (1ULL << RTE_ETH_FLOW_NVGRE)
+#define ETH_RSS_L3VXLAN            (1ULL << RTE_ETH_FLOW_L3VXLAN)
+#define ETH_RSS_GRE                (1ULL << RTE_ETH_FLOW_GRE)
 
 #define ETH_RSS_IP ( \
 	ETH_RSS_IPV4 | \
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index 665906303..44d839110 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -81,6 +81,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
 	MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
 	MK_FLOW_ITEM(E_TAG, sizeof(struct rte_flow_item_e_tag)),
 	MK_FLOW_ITEM(NVGRE, sizeof(struct rte_flow_item_nvgre)),
+	MK_FLOW_ITEM(L3VXLAN, sizeof(struct rte_flow_item_vxlan)),
 };
 
 /** Generate flow_action[] entry. */
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 41ab91912..7f240bf35 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -300,6 +300,13 @@ enum rte_flow_item_type {
 	RTE_FLOW_ITEM_TYPE_GRE,
 
 	/**
+	 * Matches a L3-VXLAN header.
+	 *
+	 * See struct rte_flow_item_vxlan.
+	 */
+	RTE_FLOW_ITEM_TYPE_L3VXLAN,
+
+	/**
 	 * [META]
 	 *
 	 * Fuzzy pattern match, expect faster than default.
-- 
2.13.3

[dpdk-dev] [RFC v1 4/5] app/testpmd: support l3vxlan tunnel type

[Xueming Li]

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 app/test-pmd/cmdline_flow.c | 9 +++++++++
 app/test-pmd/config.c       | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 1d1835ad6..a2ca03c07 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -160,6 +160,7 @@ enum index {
 	ITEM_SCTP_TAG,
 	ITEM_SCTP_CKSUM,
 	ITEM_VXLAN,
+	ITEM_L3VXLAN,
 	ITEM_VXLAN_VNI,
 	ITEM_E_TAG,
 	ITEM_E_TAG_GRP_ECID_B,
@@ -453,6 +454,7 @@ static const enum index next_item[] = {
 	ITEM_TCP,
 	ITEM_SCTP,
 	ITEM_VXLAN,
+	ITEM_L3VXLAN,
 	ITEM_E_TAG,
 	ITEM_NVGRE,
 	ITEM_MPLS,
@@ -1367,6 +1369,13 @@ static const struct token token_list[] = {
 		.next = NEXT(item_vxlan),
 		.call = parse_vc,
 	},
+	[ITEM_L3VXLAN] = {
+		.name = "l3vxlan",
+		.help = "match L3VXLAN header",
+		.priv = PRIV_ITEM(L3VXLAN, sizeof(struct rte_flow_item_vxlan)),
+		.next = NEXT(item_vxlan),
+		.call = parse_vc,
+	},
 	[ITEM_VXLAN_VNI] = {
 		.name = "vni",
 		.help = "VXLAN identifier",
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cd2ac1164..2e2143ce8 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -125,6 +125,7 @@ static const struct rss_type_info rss_type_table[] = {
 	{ "ipv6-udp-ex", ETH_RSS_IPV6_UDP_EX },
 	{ "port", ETH_RSS_PORT },
 	{ "vxlan", ETH_RSS_VXLAN },
+	{ "l3vxlan", ETH_RSS_L3VXLAN },
 	{ "geneve", ETH_RSS_GENEVE },
 	{ "nvgre", ETH_RSS_NVGRE },
 
@@ -965,6 +966,7 @@ static const struct {
 	MK_FLOW_ITEM(TCP, sizeof(struct rte_flow_item_tcp)),
 	MK_FLOW_ITEM(SCTP, sizeof(struct rte_flow_item_sctp)),
 	MK_FLOW_ITEM(VXLAN, sizeof(struct rte_flow_item_vxlan)),
+	MK_FLOW_ITEM(L3VXLAN, sizeof(struct rte_flow_item_vxlan)),
 	MK_FLOW_ITEM(E_TAG, sizeof(struct rte_flow_item_e_tag)),
 	MK_FLOW_ITEM(NVGRE, sizeof(struct rte_flow_item_nvgre)),
 	MK_FLOW_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
@@ -2960,6 +2962,7 @@ flowtype_to_str(uint16_t flow_type)
 		{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
 		{"port", RTE_ETH_FLOW_PORT},
 		{"vxlan", RTE_ETH_FLOW_VXLAN},
+		{"l3vxlan", RTE_ETH_FLOW_L3VXLAN},
 		{"geneve", RTE_ETH_FLOW_GENEVE},
 		{"nvgre", RTE_ETH_FLOW_NVGRE},
 	};
-- 
2.13.3

[dpdk-dev] [RFC v1 5/5] mbuf: add L3 VXLAN packet type

[Xueming Li]

Add new L3 VXLAN packet type, no inner L2 layer comparing to standard
VXLAN

Signed-off-by: Xueming Li <xuemingl@mellanox.com>
---
 lib/librte_mbuf/rte_mbuf_ptype.c |  1 +
 lib/librte_mbuf/rte_mbuf_ptype.h | 13 +++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c b/lib/librte_mbuf/rte_mbuf_ptype.c
index a623226cc..a688879b7 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.c
+++ b/lib/librte_mbuf/rte_mbuf_ptype.c
@@ -92,6 +92,7 @@ const char *rte_get_ptype_tunnel_name(uint32_t ptype)
 	case RTE_PTYPE_TUNNEL_GTPC: return "TUNNEL_GTPC";
 	case RTE_PTYPE_TUNNEL_GTPU: return "TUNNEL_GTPU";
 	case RTE_PTYPE_TUNNEL_ESP: return "TUNNEL_ESP";
+	case RTE_PTYPE_TUNNEL_L3VXLAN: return "TUNNEL_L3VXLAN";
 	default: return "TUNNEL_UNKNOWN";
 	}
 }
diff --git a/lib/librte_mbuf/rte_mbuf_ptype.h b/lib/librte_mbuf/rte_mbuf_ptype.h
index 5c62435ce..82e6d28a2 100644
--- a/lib/librte_mbuf/rte_mbuf_ptype.h
+++ b/lib/librte_mbuf/rte_mbuf_ptype.h
@@ -426,6 +426,19 @@ extern "C" {
  */
 #define RTE_PTYPE_TUNNEL_ESP                0x00009000
 /**
+ * L3 VXLAN (Virtual eXtensible Local Area Network) tunneling packet type.
+ *
+ * Packet format:
+ * <'ether type'=0x0800
+ * | 'version'=4, 'protocol'=17
+ * | 'destination port'=any>
+ * or,
+ * <'ether type'=0x86DD
+ * | 'version'=6, 'next header'=17
+ * | 'destination port'=any>
+ */
+#define RTE_PTYPE_TUNNEL_L3VXLAN            0x0000a000
+/**
  * Mask of tunneling packet types.
  */
 #define RTE_PTYPE_TUNNEL_MASK               0x0000f000
-- 
2.13.3

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

[Nelio Laranjeiro]

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,

-- 
Nélio Laranjeiro
6WIND

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

[Xueming(Steven) Li]

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

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

[Nelio Laranjeiro]

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,

-- 
Nélio Laranjeiro
6WIND

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

[Xueming(Steven) Li]

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

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

[Nelio Laranjeiro]

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