[dpdk-dev] [PATCH v3 0/4] ethdev: Additions to support tunnel encap/decap offload

[dpdk-dev] [PATCH v3 0/4] ethdev: Additions to support tunnel encap/decap offload

[Declan Doherty]

This patchset contains the revised proposal to manage virtual
tunnel endpoints hardware accleration based on community
feedback on RFC
(http://dpdk.org/ml/archives/dev/2017-December/084676.html). This
proposal is purely enabled through rte_flow APIs with the
additions of some new features which were previously implemented
by the proposed rte_tep APIs which were proposed in the original
RFC. This patchset ultimately aims to enable the configuration
of inline data path encapsulation and decapsulation of tunnel
endpoint network overlays on accelerated IO devices.

V2:
Split new functions into separate patches, and add additional
documentaiton.

V3:
Extended the description of group counter in documentation.
Renamed VTEP to TUNNEL.
Fixed C99 syntax.

The summary of the additions to the rte_flow are as follows:

- Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP and
RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP to rte_flow to support specfication
of encapsulation and decapsulation of virtual Tunnel Endpoint on
hardware.

- Updates the matching pattern item definition
description to specify that all actions which modify a packet
must be specified in the explicit order they are to be excuted.

- Introduces support for the use of pipeline metadata in
the flow pattern definition and the population of metadata fields
from flow actions.

- Adds group counters to enable statistics to be kept on groups of
flows such as all ingress/egress flows of a tunnel

- Adds group_action to allow a flow termination to be a group/table
within the device.

A high level summary of the proposed usage model is as follows:

1. Decapsulation
1.1. Decapsulation of tunnel outer headers and forward all traffic
     to the same queue/s or port, would have the follow flows
     paramteters, sudo code used here.

struct rte_flow_attr attr = { .ingress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, .type = VxLAN },
	{ .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action  },
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

1.2.

Decapsulation of tunnel outer headers and matching on inner
headers, and forwarding to the same queue/s or port.

1.2.1.

The same scenario as above but either the application
or hardware requires configuration as 2 logically independent
operations (viewing it as 2 logical tables). The first stage
being the flow rule to define the pattern to match the tunnel
and the action to decapsulate the packet, and the second stage
stage table matches the inner header and defines the actions,
forward to port etc.

flow rule for outer header on table 0

struct rte_flow_attr attr = { .ingress = 1, .table = 0 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_GROUP_COUNT, .conf = &tunnel_counter },
	{ .type = RTE_FLOW_ACTION_TYPE_METADATA, .conf = &metadata_action },
	{ .type = RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, .conf = VxLAN },
	{
	  .type = RTE_FLOW_ACTION_TYPE_GROUP,
	  .conf = &group_action = { .id = 1 }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

flow rule for inner header on table 1

struct rte_flow_attr attr = { .ingress = 1, .table = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_METADATA,  .spec = &metadata_item },
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

Note that the metadata action in the flow rule in table 0 is generating
the metadata in the pipeline which is then used in as part as the flow
pattern in table 1 to specify the exact flow to match against. In the
case where exact match rules are being provided by the application
then this metadata could be extracted by the PMD from the flow pattern
for the group 0 rule, the matching metadata will then need to be
explicitly provided by the application in the flow pattern for the flow
rule in group 1. For devices capable of wildcard matching then the hardware
must be capable of extracting the data from the packet as specified by the
mask in the flow action rule in group 0.

2. Encapsulation

Encapsulation of all traffic matching a specific flow pattern to a
specified tunnel and egressing to a particular port.

struct rte_flow_attr attr = { .egress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action_tunnel_encap encap_action = {
	.patterns = {
		{ .type=eth, .item = {} },
		{ .type=ipv4, .item = {} },
		{ .type=udp, .item = {} },
		{ .type=vxlan, .item = {} } }
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_GROUP_COUNT, .conf = &group_count } },
	{ .type = RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, .conf = &encap_action } },
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
};

Declan Doherty (4):
  ethdev: add group counter support to rte_flow
  ethdev: Add tunnel encap/decap actions
  ethdev: Add group action type to rte_flow
  ethdev: Add metadata flow and action items support

 doc/guides/prog_guide/rte_flow.rst      | 220 +++++++++++++++++++++++++++++++-
 lib/librte_ether/rte_ethdev_version.map |   8 ++
 lib/librte_ether/rte_flow.c             |  21 +++
 lib/librte_ether/rte_flow.h             | 195 +++++++++++++++++++++++++++-
 lib/librte_ether/rte_flow_driver.h      |   6 +
 5 files changed, 444 insertions(+), 6 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow

[Declan Doherty]

Add new RTE_FLOW_ACTION_TYPE_GROUP_COUNT action type to enable shared
counters across multiple flows on a single port or across multiple
flows on multiple ports within the same switch domain.

Introduce new API rte_flow_query_group_count to allow querying of group
counters.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst      | 35 +++++++++++++++++++++
 lib/librte_ether/rte_ethdev_version.map |  8 +++++
 lib/librte_ether/rte_flow.c             | 21 +++++++++++++
 lib/librte_ether/rte_flow.h             | 56 ++++++++++++++++++++++++++++++++-
 lib/librte_ether/rte_flow_driver.h      |  6 ++++
 5 files changed, 125 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 961943d..fd33d19 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1698,6 +1698,41 @@ Return values:
 
 - 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
 
+
+Group Count Query
+~~~~~~~~~~~~~~~~~
+
+Query group counter which can be associated with multiple flows on a specified
+port.
+
+This function allows retrieving of group counters. A group counter is a
+counter which can be shared among multiple flows on a single port or among
+multiple flows on multiple ports within the same switch domain. Data is
+gathered by special actions which must be present in the flow rule
+definition.
+
+.. code-block:: c
+
+   int
+   rte_flow_query_group_count(uint16_t port_id,
+			   uint32_t group_counter_id,
+			   struct rte_flow_query_count *count,
+               struct rte_flow_error *error);
+
+Arguments:
+
+- ``port_id``: port identifier of Ethernet device.
+- ``group_counter_id``: group counter identifier.
+- ``count``: group counter parameters.
+- ``error``: perform verbose error reporting if not NULL. PMDs initialize
+  this structure in case of error only.
+
+Return values:
+
+- 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
+
+
+
 Isolated mode
 -------------
 
diff --git a/lib/librte_ether/rte_ethdev_version.map b/lib/librte_ether/rte_ethdev_version.map
index 34df6c8..cff6807 100644
--- a/lib/librte_ether/rte_ethdev_version.map
+++ b/lib/librte_ether/rte_ethdev_version.map
@@ -229,3 +229,11 @@ EXPERIMENTAL {
 	rte_mtr_stats_update;
 
 } DPDK_17.11;
+
+
+EXPERIMENTAL {
+	global:
+
+	rte_flow_query_group_count
+
+} DPDK_18.05;
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index 38f2d27..e10b1d0 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -418,3 +418,24 @@ rte_flow_copy(struct rte_flow_desc *desc, size_t len,
 	}
 	return 0;
 }
+
+int __rte_experimental
+rte_flow_query_group_count(uint16_t port_id,
+	uint32_t group_count_id,
+	struct rte_flow_query_count *count,
+	struct rte_flow_error *error)
+{
+	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+	const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
+
+	if (!ops)
+		return -rte_errno;
+	if (likely(!!ops->query_group_count))
+		return flow_err(port_id,
+				ops->query_group_count(dev, group_count_id,
+						       count, error),
+				error);
+	return rte_flow_error_set(error, ENOSYS,
+				  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+				  NULL, rte_strerror(ENOSYS));
+}
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 13e4202..7d1f89d 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1010,7 +1010,19 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_security.
 	 */
-	RTE_FLOW_ACTION_TYPE_SECURITY
+	RTE_FLOW_ACTION_TYPE_SECURITY,
+
+	/**
+	 * Enable a shared flow group counter for flow. Group counters can be
+	 * associated with multiples flows on the same port or on port within
+	 * the same switch domain if supported by that device.
+	 *
+	 * Group counters can be retrieved and reset through
+	 * rte_flow_query_group_count()
+	 *
+	 * See struct rte_flow_action_group_count.
+	 */
+	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
 };
 
 /**
@@ -1149,6 +1161,18 @@ struct rte_flow_action_security {
 };
 
 /**
+ * RTE_FLOW_ACTION_TYPE_GROUP_COUNT
+ *
+ * A packet/byte counter which can be shared across a group of flows programmed
+ * on the same port/switch domain.
+ *
+ * Non-terminating by default.
+ */
+struct rte_flow_action_group_count {
+	uint32_t id;
+};
+
+/**
  * Definition of a single action.
  *
  * A list of actions is terminated by a END action.
@@ -1476,6 +1500,36 @@ rte_flow_copy(struct rte_flow_desc *fd, size_t len,
 	      const struct rte_flow_item *items,
 	      const struct rte_flow_action *actions);
 
+
+/**
+ * Get hit/bytes count for group counter.
+ *
+ * A group counter is a counter which can be shared among multiple flows on a
+ * single port or among multiple flows on multiple ports within the same
+ * switch domain.
+ *
+ * In the case of ports within the same switch domain a global name space is
+ * assumed for group_count_id value.
+ *
+ * @param[in]	port_id
+ *   Port identifier of Ethernet device.
+ * @param[in]	group_count_id
+ *   Group counter identifier to query
+ * @param[out]	count
+ *   Group counter value
+ * @param[out]	error
+ *   Perform verbose error reporting if not NULL. PMDs initialize this
+ *   structure in case of error only.
+ *
+ * @return
+ *   Negative error code (errno value) and rte_errno is set.
+ */
+int __rte_experimental
+rte_flow_query_group_count(uint16_t port_id,
+			   uint32_t group_count_id,
+			   struct rte_flow_query_count *count,
+			   struct rte_flow_error *error);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
index 7778c8e..ef09465 100644
--- a/lib/librte_ether/rte_flow_driver.h
+++ b/lib/librte_ether/rte_flow_driver.h
@@ -96,6 +96,12 @@ struct rte_flow_ops {
 		(struct rte_eth_dev *,
 		 int,
 		 struct rte_flow_error *);
+	/** See rte_flow_query_group_count(). */
+	int (*query_group_count)
+		(struct rte_eth_dev *,
+		 uint32_t,
+		 struct rte_flow_query_count *,
+		 struct rte_flow_error *);
 };
 
 /**
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow

[Adrien Mazarguil]

On Fri, Apr 06, 2018 at 01:24:00PM +0100, Declan Doherty wrote:
> Add new RTE_FLOW_ACTION_TYPE_GROUP_COUNT action type to enable shared
> counters across multiple flows on a single port or across multiple
> flows on multiple ports within the same switch domain.
> 
> Introduce new API rte_flow_query_group_count to allow querying of group
> counters.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

Both features are definitely needed, however I suggest to enhance the
existing action type and query function instead, given the rte_flow ABI
won't be maintained for the 18.05 release [1].

Counters and query support were defined as a kind of PoC in preparation for
future requirements back in DPDK 17.02 and so far few PMDs have implemented
the query callback (mlx5 and failsafe, and the latter isn't really a PMD).

Due to the behavior change of action lists [2], providing an action type as
a query parameter is not specific enough anymore, for instance if a list
contains multiple COUNT, the application should be able to tell which needs
to be queried.

Therefore I suggest to redefine the query function as follows:

 int
 rte_flow_query(uint16_t port_id,
                struct rte_flow *flow,
                const struct rte_flow_action *action,
                void *data,
                struct rte_flow_error *error);

Third argument is an action definition with the same configuration (if any)
as previously defined in the action list originally used to create the flow
rule (not necessarily the same pointer, only the contents matter).

It means two perfectly identical actions can't be distinguished, and that's
how group counters will work.

Instead of adding a new action type to distinguish groups, a configuration
structure is added to the existing RTE_FLOW_ACTION_TYPE_COUNT, with
non-shared counters as a default behavior:

 struct rte_flow_action_count {
         uint32_t shared:1; /**< Share counter ID with other flow rules. */
         uint32_t reserved:31; /**< Reserved, must be zero. */
         uint32_t id; /**< Counter ID. */
 };

Doing so will impact some existing code in mlx5 and librte_flow_classify,
but that shouldn't be much of an issue.

Keep in mind testpmd and its documentation must be updated as well.

Thoughts?

A few nits below for the sake of commenting.

[1] "Flow API overhaul for switch offloads"
    http://dpdk.org/ml/archives/dev/2018-April/095774.html
[2] "ethdev: alter behavior of flow API actions"
    http://dpdk.org/ml/archives/dev/2018-April/095779.html

> ---
>  doc/guides/prog_guide/rte_flow.rst      | 35 +++++++++++++++++++++
>  lib/librte_ether/rte_ethdev_version.map |  8 +++++
>  lib/librte_ether/rte_flow.c             | 21 +++++++++++++
>  lib/librte_ether/rte_flow.h             | 56 ++++++++++++++++++++++++++++++++-
>  lib/librte_ether/rte_flow_driver.h      |  6 ++++
>  5 files changed, 125 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 961943d..fd33d19 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1698,6 +1698,41 @@ Return values:
>  
>  - 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
>  
> +

Unnecessary empty line.

> +Group Count Query
> +~~~~~~~~~~~~~~~~~
> +
> +Query group counter which can be associated with multiple flows on a specified
> +port.
> +
> +This function allows retrieving of group counters. A group counter is a
> +counter which can be shared among multiple flows on a single port or among
> +multiple flows on multiple ports within the same switch domain. Data is
> +gathered by special actions which must be present in the flow rule
> +definition.
> +
> +.. code-block:: c
> +
> +   int
> +   rte_flow_query_group_count(uint16_t port_id,
> +			   uint32_t group_counter_id,
> +			   struct rte_flow_query_count *count,
> +               struct rte_flow_error *error);
> +
> +Arguments:
> +
> +- ``port_id``: port identifier of Ethernet device.
> +- ``group_counter_id``: group counter identifier.
> +- ``count``: group counter parameters.
> +- ``error``: perform verbose error reporting if not NULL. PMDs initialize
> +  this structure in case of error only.
> +
> +Return values:
> +
> +- 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
> +
> +
> +

More unnecessary empty lines.

>  Isolated mode
>  -------------
>  
> diff --git a/lib/librte_ether/rte_ethdev_version.map b/lib/librte_ether/rte_ethdev_version.map
> index 34df6c8..cff6807 100644
> --- a/lib/librte_ether/rte_ethdev_version.map
> +++ b/lib/librte_ether/rte_ethdev_version.map
> @@ -229,3 +229,11 @@ EXPERIMENTAL {
>  	rte_mtr_stats_update;
>  
>  } DPDK_17.11;
> +
> +

One more.

> +EXPERIMENTAL {
> +	global:
> +
> +	rte_flow_query_group_count
> +
> +} DPDK_18.05;
> diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
> index 38f2d27..e10b1d0 100644
> --- a/lib/librte_ether/rte_flow.c
> +++ b/lib/librte_ether/rte_flow.c
> @@ -418,3 +418,24 @@ rte_flow_copy(struct rte_flow_desc *desc, size_t len,
>  	}
>  	return 0;
>  }
> +
> +int __rte_experimental
> +rte_flow_query_group_count(uint16_t port_id,
> +	uint32_t group_count_id,
> +	struct rte_flow_query_count *count,
> +	struct rte_flow_error *error)

This function lacks a short documentation comment (see rte_flow_query()).

> +{
> +	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> +	const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> +	if (!ops)
> +		return -rte_errno;
> +	if (likely(!!ops->query_group_count))
> +		return flow_err(port_id,
> +				ops->query_group_count(dev, group_count_id,
> +						       count, error),
> +				error);
> +	return rte_flow_error_set(error, ENOSYS,
> +				  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> +				  NULL, rte_strerror(ENOSYS));
> +}
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 13e4202..7d1f89d 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -1010,7 +1010,19 @@ enum rte_flow_action_type {
>  	 *
>  	 * See struct rte_flow_action_security.
>  	 */
> -	RTE_FLOW_ACTION_TYPE_SECURITY
> +	RTE_FLOW_ACTION_TYPE_SECURITY,
> +
> +	/**
> +	 * Enable a shared flow group counter for flow. Group counters can be
> +	 * associated with multiples flows on the same port or on port within
> +	 * the same switch domain if supported by that device.
> +	 *
> +	 * Group counters can be retrieved and reset through
> +	 * rte_flow_query_group_count()
> +	 *
> +	 * See struct rte_flow_action_group_count.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_GROUP_COUNT

Don't forget the trailing comma.

>  };
>  
>  /**
> @@ -1149,6 +1161,18 @@ struct rte_flow_action_security {
>  };
>  
>  /**
> + * RTE_FLOW_ACTION_TYPE_GROUP_COUNT
> + *
> + * A packet/byte counter which can be shared across a group of flows programmed
> + * on the same port/switch domain.
> + *
> + * Non-terminating by default.
> + */
> +struct rte_flow_action_group_count {
> +	uint32_t id;
> +};
> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> @@ -1476,6 +1500,36 @@ rte_flow_copy(struct rte_flow_desc *fd, size_t len,
>  	      const struct rte_flow_item *items,
>  	      const struct rte_flow_action *actions);
>  
> +

Caught another empty line.

> +/**
> + * Get hit/bytes count for group counter.
> + *
> + * A group counter is a counter which can be shared among multiple flows on a
> + * single port or among multiple flows on multiple ports within the same
> + * switch domain.
> + *
> + * In the case of ports within the same switch domain a global name space is
> + * assumed for group_count_id value.
> + *
> + * @param[in]	port_id
> + *   Port identifier of Ethernet device.
> + * @param[in]	group_count_id
> + *   Group counter identifier to query
> + * @param[out]	count
> + *   Group counter value
> + * @param[out]	error
> + *   Perform verbose error reporting if not NULL. PMDs initialize this
> + *   structure in case of error only.
> + *
> + * @return
> + *   Negative error code (errno value) and rte_errno is set.
> + */
> +int __rte_experimental
> +rte_flow_query_group_count(uint16_t port_id,
> +			   uint32_t group_count_id,
> +			   struct rte_flow_query_count *count,
> +			   struct rte_flow_error *error);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
> index 7778c8e..ef09465 100644
> --- a/lib/librte_ether/rte_flow_driver.h
> +++ b/lib/librte_ether/rte_flow_driver.h
> @@ -96,6 +96,12 @@ struct rte_flow_ops {
>  		(struct rte_eth_dev *,
>  		 int,
>  		 struct rte_flow_error *);
> +	/** See rte_flow_query_group_count(). */
> +	int (*query_group_count)
> +		(struct rte_eth_dev *,
> +		 uint32_t,
> +		 struct rte_flow_query_count *,
> +		 struct rte_flow_error *);
>  };
>  
>  /**
> -- 
> 2.7.4
> 

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow

[Mohammad Abdul Awal]

Hi Adrien,


On 06/04/2018 21:26, Adrien Mazarguil wrote:
> On Fri, Apr 06, 2018 at 01:24:00PM +0100, Declan Doherty wrote:
>> Add new RTE_FLOW_ACTION_TYPE_GROUP_COUNT action type to enable shared
>> counters across multiple flows on a single port or across multiple
>> flows on multiple ports within the same switch domain.
>>
>> Introduce new API rte_flow_query_group_count to allow querying of group
>> counters.
>>
>> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> Both features are definitely needed, however I suggest to enhance the
> existing action type and query function instead, given the rte_flow ABI
> won't be maintained for the 18.05 release [1].
>
> Counters and query support were defined as a kind of PoC in preparation for
> future requirements back in DPDK 17.02 and so far few PMDs have implemented
> the query callback (mlx5 and failsafe, and the latter isn't really a PMD).
>
> Due to the behavior change of action lists [2], providing an action type as
> a query parameter is not specific enough anymore, for instance if a list
> contains multiple COUNT, the application should be able to tell which needs
> to be queried.
>
> Therefore I suggest to redefine the query function as follows:
>
>   int
>   rte_flow_query(uint16_t port_id,
>                  struct rte_flow *flow,
>                  const struct rte_flow_action *action,
>                  void *data,
>                  struct rte_flow_error *error);
>
> Third argument is an action definition with the same configuration (if any)
> as previously defined in the action list originally used to create the flow
> rule (not necessarily the same pointer, only the contents matter).
>
> It means two perfectly identical actions can't be distinguished, and that's
> how group counters will work.
> Instead of adding a new action type to distinguish groups, a configuration
> structure is added to the existing RTE_FLOW_ACTION_TYPE_COUNT, with
> non-shared counters as a default behavior:
>
>   struct rte_flow_action_count {
>           uint32_t shared:1; /**< Share counter ID with other flow rules. */
>           uint32_t reserved:31; /**< Reserved, must be zero. */
>           uint32_t id; /**< Counter ID. */
>   };
>
> Doing so will impact some existing code in mlx5 and librte_flow_classify,
> but that shouldn't be much of an issue.
>
> Keep in mind testpmd and its documentation must be updated as well.
>
> Thoughts?
Please correct me if I am wrong but I think we are talking two different 
things here.
If I understood you correctly, you are proposing to pass a list of 
actions (instead if a action type) in the third parameter to perform 
multiple actions in the same query call. Lets take an example for 100 
ingress flows. So, if we want to query the counter for all the flows, we 
can get them by a single query providing a list (of size 100) of 
action_count in the 3rd param.

On the other hand, we are saying that all the flows are belongs to same 
tunnel end-point (we are talking only 1 TEP here), then the PMD will be 
responsible to increment the counter of TEP for matching all the flows 
(100 flows). So, using one group query by passing one action_count in 
3rd param, we can get the count of the TEP.

This case is generic enough for sure for simple flows but may not be 
suitable for tunnel cases, as application needs to track the counters 
for all the flows, and needs to build the list of action each time the 
flows added/deleted.

>
> A few nits below for the sake of commenting.
>
> [1] "Flow API overhaul for switch offloads"
>      http://dpdk.org/ml/archives/dev/2018-April/095774.html
> [2] "ethdev: alter behavior of flow API actions"
>      http://dpdk.org/ml/archives/dev/2018-April/095779.html
>
>> ---
>>   doc/guides/prog_guide/rte_flow.rst      | 35 +++++++++++++++++++++
>>   lib/librte_ether/rte_ethdev_version.map |  8 +++++
>>   lib/librte_ether/rte_flow.c             | 21 +++++++++++++
>>   lib/librte_ether/rte_flow.h             | 56 ++++++++++++++++++++++++++++++++-
>>   lib/librte_ether/rte_flow_driver.h      |  6 ++++
>>   5 files changed, 125 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index 961943d..fd33d19 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -1698,6 +1698,41 @@ Return values:
>>   
>>   - 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
>>   
>> +
> Unnecessary empty line.
I will take into account all the comments.

Regards,
Awal.

>
>> +Group Count Query
>> +~~~~~~~~~~~~~~~~~
>> +
>> +Query group counter which can be associated with multiple flows on a specified
>> +port.
>> +
>> +This function allows retrieving of group counters. A group counter is a
>> +counter which can be shared among multiple flows on a single port or among
>> +multiple flows on multiple ports within the same switch domain. Data is
>> +gathered by special actions which must be present in the flow rule
>> +definition.
>> +
>> +.. code-block:: c
>> +
>> +   int
>> +   rte_flow_query_group_count(uint16_t port_id,
>> +			   uint32_t group_counter_id,
>> +			   struct rte_flow_query_count *count,
>> +               struct rte_flow_error *error);
>> +
>> +Arguments:
>> +
>> +- ``port_id``: port identifier of Ethernet device.
>> +- ``group_counter_id``: group counter identifier.
>> +- ``count``: group counter parameters.
>> +- ``error``: perform verbose error reporting if not NULL. PMDs initialize
>> +  this structure in case of error only.
>> +
>> +Return values:
>> +
>> +- 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
>> +
>> +
>> +
> More unnecessary empty lines.
>
>>   Isolated mode
>>   -------------
>>   
>> diff --git a/lib/librte_ether/rte_ethdev_version.map b/lib/librte_ether/rte_ethdev_version.map
>> index 34df6c8..cff6807 100644
>> --- a/lib/librte_ether/rte_ethdev_version.map
>> +++ b/lib/librte_ether/rte_ethdev_version.map
>> @@ -229,3 +229,11 @@ EXPERIMENTAL {
>>   	rte_mtr_stats_update;
>>   
>>   } DPDK_17.11;
>> +
>> +
> One more.
>
>> +EXPERIMENTAL {
>> +	global:
>> +
>> +	rte_flow_query_group_count
>> +
>> +} DPDK_18.05;
>> diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
>> index 38f2d27..e10b1d0 100644
>> --- a/lib/librte_ether/rte_flow.c
>> +++ b/lib/librte_ether/rte_flow.c
>> @@ -418,3 +418,24 @@ rte_flow_copy(struct rte_flow_desc *desc, size_t len,
>>   	}
>>   	return 0;
>>   }
>> +
>> +int __rte_experimental
>> +rte_flow_query_group_count(uint16_t port_id,
>> +	uint32_t group_count_id,
>> +	struct rte_flow_query_count *count,
>> +	struct rte_flow_error *error)
> This function lacks a short documentation comment (see rte_flow_query()).
>
>> +{
>> +	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>> +	const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
>> +
>> +	if (!ops)
>> +		return -rte_errno;
>> +	if (likely(!!ops->query_group_count))
>> +		return flow_err(port_id,
>> +				ops->query_group_count(dev, group_count_id,
>> +						       count, error),
>> +				error);
>> +	return rte_flow_error_set(error, ENOSYS,
>> +				  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
>> +				  NULL, rte_strerror(ENOSYS));
>> +}
>> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
>> index 13e4202..7d1f89d 100644
>> --- a/lib/librte_ether/rte_flow.h
>> +++ b/lib/librte_ether/rte_flow.h
>> @@ -1010,7 +1010,19 @@ enum rte_flow_action_type {
>>   	 *
>>   	 * See struct rte_flow_action_security.
>>   	 */
>> -	RTE_FLOW_ACTION_TYPE_SECURITY
>> +	RTE_FLOW_ACTION_TYPE_SECURITY,
>> +
>> +	/**
>> +	 * Enable a shared flow group counter for flow. Group counters can be
>> +	 * associated with multiples flows on the same port or on port within
>> +	 * the same switch domain if supported by that device.
>> +	 *
>> +	 * Group counters can be retrieved and reset through
>> +	 * rte_flow_query_group_count()
>> +	 *
>> +	 * See struct rte_flow_action_group_count.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
> Don't forget the trailing comma.
>
>>   };
>>   
>>   /**
>> @@ -1149,6 +1161,18 @@ struct rte_flow_action_security {
>>   };
>>   
>>   /**
>> + * RTE_FLOW_ACTION_TYPE_GROUP_COUNT
>> + *
>> + * A packet/byte counter which can be shared across a group of flows programmed
>> + * on the same port/switch domain.
>> + *
>> + * Non-terminating by default.
>> + */
>> +struct rte_flow_action_group_count {
>> +	uint32_t id;
>> +};
>> +
>> +/**
>>    * Definition of a single action.
>>    *
>>    * A list of actions is terminated by a END action.
>> @@ -1476,6 +1500,36 @@ rte_flow_copy(struct rte_flow_desc *fd, size_t len,
>>   	      const struct rte_flow_item *items,
>>   	      const struct rte_flow_action *actions);
>>   
>> +
> Caught another empty line.
>
>> +/**
>> + * Get hit/bytes count for group counter.
>> + *
>> + * A group counter is a counter which can be shared among multiple flows on a
>> + * single port or among multiple flows on multiple ports within the same
>> + * switch domain.
>> + *
>> + * In the case of ports within the same switch domain a global name space is
>> + * assumed for group_count_id value.
>> + *
>> + * @param[in]	port_id
>> + *   Port identifier of Ethernet device.
>> + * @param[in]	group_count_id
>> + *   Group counter identifier to query
>> + * @param[out]	count
>> + *   Group counter value
>> + * @param[out]	error
>> + *   Perform verbose error reporting if not NULL. PMDs initialize this
>> + *   structure in case of error only.
>> + *
>> + * @return
>> + *   Negative error code (errno value) and rte_errno is set.
>> + */
>> +int __rte_experimental
>> +rte_flow_query_group_count(uint16_t port_id,
>> +			   uint32_t group_count_id,
>> +			   struct rte_flow_query_count *count,
>> +			   struct rte_flow_error *error);
>> +
>>   #ifdef __cplusplus
>>   }
>>   #endif
>> diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
>> index 7778c8e..ef09465 100644
>> --- a/lib/librte_ether/rte_flow_driver.h
>> +++ b/lib/librte_ether/rte_flow_driver.h
>> @@ -96,6 +96,12 @@ struct rte_flow_ops {
>>   		(struct rte_eth_dev *,
>>   		 int,
>>   		 struct rte_flow_error *);
>> +	/** See rte_flow_query_group_count(). */
>> +	int (*query_group_count)
>> +		(struct rte_eth_dev *,
>> +		 uint32_t,
>> +		 struct rte_flow_query_count *,
>> +		 struct rte_flow_error *);
>>   };
>>   
>>   /**
>> -- 
>> 2.7.4
>>

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow

[Adrien Mazarguil]

Hi Mohammad,

On Mon, Apr 09, 2018 at 03:22:45PM +0100, Mohammad Abdul Awal wrote:
> Hi Adrien,
> 
> 
> On 06/04/2018 21:26, Adrien Mazarguil wrote:
> > On Fri, Apr 06, 2018 at 01:24:00PM +0100, Declan Doherty wrote:
> > > Add new RTE_FLOW_ACTION_TYPE_GROUP_COUNT action type to enable shared
> > > counters across multiple flows on a single port or across multiple
> > > flows on multiple ports within the same switch domain.
> > > 
> > > Introduce new API rte_flow_query_group_count to allow querying of group
> > > counters.
> > > 
> > > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > Both features are definitely needed, however I suggest to enhance the
> > existing action type and query function instead, given the rte_flow ABI
> > won't be maintained for the 18.05 release [1].
> > 
> > Counters and query support were defined as a kind of PoC in preparation for
> > future requirements back in DPDK 17.02 and so far few PMDs have implemented
> > the query callback (mlx5 and failsafe, and the latter isn't really a PMD).
> > 
> > Due to the behavior change of action lists [2], providing an action type as
> > a query parameter is not specific enough anymore, for instance if a list
> > contains multiple COUNT, the application should be able to tell which needs
> > to be queried.
> > 
> > Therefore I suggest to redefine the query function as follows:
> > 
> >   int
> >   rte_flow_query(uint16_t port_id,
> >                  struct rte_flow *flow,
> >                  const struct rte_flow_action *action,
> >                  void *data,
> >                  struct rte_flow_error *error);
> > 
> > Third argument is an action definition with the same configuration (if any)
> > as previously defined in the action list originally used to create the flow
> > rule (not necessarily the same pointer, only the contents matter).
> > 
> > It means two perfectly identical actions can't be distinguished, and that's
> > how group counters will work.
> > Instead of adding a new action type to distinguish groups, a configuration
> > structure is added to the existing RTE_FLOW_ACTION_TYPE_COUNT, with
> > non-shared counters as a default behavior:
> > 
> >   struct rte_flow_action_count {
> >           uint32_t shared:1; /**< Share counter ID with other flow rules. */
> >           uint32_t reserved:31; /**< Reserved, must be zero. */
> >           uint32_t id; /**< Counter ID. */
> >   };
> > 
> > Doing so will impact some existing code in mlx5 and librte_flow_classify,
> > but that shouldn't be much of an issue.
> > 
> > Keep in mind testpmd and its documentation must be updated as well.
> > 
> > Thoughts?
> Please correct me if I am wrong but I think we are talking two different
> things here.
> If I understood you correctly, you are proposing to pass a list of actions
> (instead if a action type) in the third parameter to perform multiple
> actions in the same query call. Lets take an example for 100 ingress flows.
> So, if we want to query the counter for all the flows, we can get them by a
> single query providing a list (of size 100) of action_count in the 3rd
> param.

Whoa no! I'm only suggesting a pointer to a single action as a replacement
for the basic action type, not a *list* of actions. I hope this addresses
all concerns :)

The fact the action in question would refer to a shared counter (see struct
above) with a given ID would be enough to make all counters with the same ID
refer to the same internal PMD object.

> On the other hand, we are saying that all the flows are belongs to same
> tunnel end-point (we are talking only 1 TEP here), then the PMD will be
> responsible to increment the counter of TEP for matching all the flows (100
> flows). So, using one group query by passing one action_count in 3rd param,
> we can get the count of the TEP.
> 
> This case is generic enough for sure for simple flows but may not be
> suitable for tunnel cases, as application needs to track the counters for
> all the flows, and needs to build the list of action each time the flows
> added/deleted.

I think we're on the same page. I'm only suggesting to define a
configuration structure for the COUNT action (which currently doesn't take
any) as a replacement for GROUP_COUNT, and tweak the query callback to be
able to tell a specific counter to query instead of adding a new query
callback and leaving the existing one broken by design.

> > A few nits below for the sake of commenting.
> > 
> > [1] "Flow API overhaul for switch offloads"
> >      http://dpdk.org/ml/archives/dev/2018-April/095774.html
> > [2] "ethdev: alter behavior of flow API actions"
> >      http://dpdk.org/ml/archives/dev/2018-April/095779.html

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Declan Doherty]

Add new flow action types and associated action data structures to
support the encapsulation and decapsulation of the virtual tunnel
endpoints.

The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching
flow to be encapsulated in the virtual tunnel endpoint overlay
defined in the tunnel_encap action data.

The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual
tunnel endpoint overlays up to and including the first instance of
the flow item type defined in the tunnel_decap action data for the
matching flows.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 77 ++++++++++++++++++++++++++++++++--
 lib/librte_ether/rte_flow.h        | 84 ++++++++++++++++++++++++++++++++++++--
 2 files changed, 155 insertions(+), 6 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index fd33d19..106fb93 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -997,9 +997,11 @@ Actions
 
 Each possible action is represented by a type. Some have associated
 configuration structures. Several actions combined in a list can be assigned
-to a flow rule. That list is not ordered.
+to a flow rule. That list is not ordered, with the exception of  actions which
+modify the packet itself, these packet modification actions must be specified
+in the explicit order in which they are to be executed.
 
-They fall in three categories:
+They fall in four categories:
 
 - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
   processing matched packets by subsequent flow rules, unless overridden
@@ -1008,8 +1010,11 @@ They fall in three categories:
 - Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for
   additional processing by subsequent flow rules.
 
+- Non-terminating meta actions that do not affect the fate of packets but result
+  in modification of the packet itself (SECURITY, TUNNEL_ENCAP, TUNNEL_DECAP).
+
 - Other non-terminating meta actions that do not affect the fate of packets
-  (END, VOID, MARK, FLAG, COUNT, SECURITY).
+  (END, VOID, MARK, FLAG, COUNT).
 
 When several actions are combined in a flow rule, they should all have
 different types (e.g. dropping a packet twice is not possible).
@@ -1486,6 +1491,72 @@ fields in the pattern items.
    | 1     | END      |
    +-------+----------+
 
+
+Action: ``TUNNEL_ENCAP``
+^^^^^^^^^^^^^^^^^^^^^^
+
+Performs an encapsulation action by encapsulating the flows matched by the
+pattern items according to the network overlay defined in the
+``rte_flow_action_tunnel_encap`` pattern items.
+
+This action modifies the payload of matched flows. The pattern items specified
+in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
+set of overlay headers, from the Ethernet header up to the overlay header. The
+pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_tunnel_encap:
+
+.. table:: TUNNEL_ENCAP
+
+   +-------------+---------------------------------------------+
+   | Field       | Value                                       |
+   +=============+=============================================+
+   | ``pattern`` | Virtual tunnel end-point pattern definition |
+   +-------------+---------------------------------------------+
+
+
+.. _table_rte_flow_action_tunnel_encap_example:
+
+.. table:: IPv4 VxLAN flow pattern example.
+
+   +-------+--------------------------+------------+
+   | Index | Flow Item Type           | Flow Item  |
+   +=======+==========================+============+
+   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
+   +-------+--------------------------+------------+
+   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
+   +-------+--------------------------+------------+
+   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
+   +-------+--------------------------+------------+
+   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
+   +-------+--------------------------+------------+
+   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
+   +-------+--------------------------+------------+
+
+
+Action: ``TUNNEL_DECAP``
+^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a decapsulation action by stripping all headers of the virtual tunnel
+end-point overlay up to the header defined by the flow item type of flows
+matched by the pattern items.
+
+This action modifies the payload of matched flows. The flow item type specified
+in the ``rte_flow_action_tunnel_decap`` action structure must defined a valid
+set of overlay header type.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_tunnel_decap:
+
+   +---------------+----------------------------------------------+
+   | Field         | Value                                        |
+   +===============+==============================================+
+   | ``item type`` | Item type of tunnel end-point to decapsulate |
+   +---------------+----------------------------------------------+
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 7d1f89d..6d94423 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -854,14 +854,17 @@ struct rte_flow_item {
 	const void *mask; /**< Bit-mask applied to spec and last. */
 };
 
+
 /**
  * Action types.
  *
  * Each possible action is represented by a type. Some have associated
  * configuration structures. Several actions combined in a list can be
- * affected to a flow rule. That list is not ordered.
+ * affected to a flow rule. That list is not ordered, with the exception of
+ * actions which modify the packet itself, these packet modification actions
+ * must be specified in the explicit order in which they are to be executed.
  *
- * They fall in three categories:
+ * They fall in four categories:
  *
  * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
  *   processing matched packets by subsequent flow rules, unless overridden
@@ -870,6 +873,10 @@ struct rte_flow_item {
  * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
  *   for additional processing by subsequent flow rules.
  *
+ * - Non terminating meta actions that do not affect the fate of
+ *   packets but result in modification of the packet itself (SECURITY,
+ *   TUNNEL_ENCAP, TUNNEL_DECAP).
+ *
  * - Other non terminating meta actions that do not affect the fate of
  *   packets (END, VOID, MARK, FLAG, COUNT).
  *
@@ -1022,7 +1029,42 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_group_count.
 	 */
-	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
+	RTE_FLOW_ACTION_TYPE_GROUP_COUNT,
+	/**
+	 * Encapsulate flow with tunnel defined in
+	 * rte_flow_action_tunnel_encap structure.
+	 *
+	 * See struct rte_flow_action_tunnel_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP,
+
+	/**
+	 * Decapsulate all the headers of the tunnel
+	 *
+	 * See struct rte_flow_action_tunnel_decap.
+	 */
+	RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
+
+	/**
+	 * Redirects packets to the logical group of the current device.
+	 *
+	 * In a logical hierarchy of groups, which can be used to represent a
+	 * physical of logical chaining of flow tables, this action allows the
+	 * terminating action to be a logical group of the same device.
+	 *
+	 * See struct rte_flow_action_group.
+	 */
+	RTE_FLOW_ACTION_TYPE_GROUP,
+
+	/**
+	 * [META]
+	 *
+	 * Set specific metadata field associated with packet which is then
+	 * available to further pipeline stages.
+	 *
+	 * See struct rte_flow_action_metadata.
+	 */
+	RTE_FLOW_ACTION_TYPE_METADATA
 };
 
 /**
@@ -1173,6 +1215,42 @@ struct rte_flow_action_group_count {
 };
 
 /**
+ * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
+ *
+ * Virtual tunnel end-point encapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_tunnel_encap {
+	struct rte_flow_action_item {
+		enum rte_flow_item_type type;
+		/**< Flow item type. */
+		const void *item;
+		/**< Flow item definition which points to the data of
+		 * corresponding rte_flow_item_type.
+		 */
+	} *pattern;
+	/**<
+	 * Tunnel pattern specification (list terminated by the END pattern
+	 * item).
+	 */
+};
+
+/**
+ * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
+ *
+ * Virtual tunnel end-point decapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_tunnel_decap {
+	enum rte_flow_item_type type;
+	/**<
+	 * Flow item type of virtual tunnel end-point to be decapsulated
+	 */
+};
+
+/**
  * Definition of a single action.
  *
  * A list of actions is terminated by a END action.
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Adrien Mazarguil]

On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote:
> Add new flow action types and associated action data structures to
> support the encapsulation and decapsulation of the virtual tunnel
> endpoints.
> 
> The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching
> flow to be encapsulated in the virtual tunnel endpoint overlay
> defined in the tunnel_encap action data.
> 
> The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual
> tunnel endpoint overlays up to and including the first instance of
> the flow item type defined in the tunnel_decap action data for the
> matching flows.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

This generic approach looks flexible enough to cover the use cases that
immediately come to mind (VLAN, VXLAN), its design is sound.

However, while I'm aware it's not a concern at this point, it won't be able
to deal with stateful tunnel or encapsulation types (e.g. IPsec or TCP)
which will require additional meta data or some run-time assistance from the
application.

Eventually for more complex use cases, dedicated encap/decap actions will
have to appear, so the issue I wanted to raise before going further is this:

Going generic inevitably trades some of the usability; flat structures
dedicated to VXLAN encap/decap with only the needed info to get the job done
would likely be easier to implement in PMDs and use in applications. Any
number of such actions can be added to rte_flow without ABI impact.

If VXLAN is the only use case at this point, my suggestion would be to go
with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP) actions, with fixed
L2/L3/L4/L5 header definitions to prepend according to RFC 7348.

Now we can start with the generic approach, see how it fares and add
dedicated encap/decap later as needed.

More comments below.

> ---
>  doc/guides/prog_guide/rte_flow.rst | 77 ++++++++++++++++++++++++++++++++--
>  lib/librte_ether/rte_flow.h        | 84 ++++++++++++++++++++++++++++++++++++--
>  2 files changed, 155 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index fd33d19..106fb93 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -997,9 +997,11 @@ Actions
>  
>  Each possible action is represented by a type. Some have associated
>  configuration structures. Several actions combined in a list can be assigned
> -to a flow rule. That list is not ordered.
> +to a flow rule. That list is not ordered, with the exception of  actions which
> +modify the packet itself, these packet modification actions must be specified
> +in the explicit order in which they are to be executed.
>  
> -They fall in three categories:
> +They fall in four categories:
>  
>  - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>    processing matched packets by subsequent flow rules, unless overridden
> @@ -1008,8 +1010,11 @@ They fall in three categories:
>  - Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for
>    additional processing by subsequent flow rules.
>  
> +- Non-terminating meta actions that do not affect the fate of packets but result
> +  in modification of the packet itself (SECURITY, TUNNEL_ENCAP, TUNNEL_DECAP).
> +
>  - Other non-terminating meta actions that do not affect the fate of packets
> -  (END, VOID, MARK, FLAG, COUNT, SECURITY).
> +  (END, VOID, MARK, FLAG, COUNT).

The above changes are not necessary anymore [1][2].

[1] "ethdev: clarify flow API pattern items and actions"
    https://dpdk.org/ml/archives/dev/2018-April/095776.html
[2] "ethdev: alter behavior of flow API actions"
    https://dpdk.org/ml/archives/dev/2018-April/095779.html

>  When several actions are combined in a flow rule, they should all have
>  different types (e.g. dropping a packet twice is not possible).
> @@ -1486,6 +1491,72 @@ fields in the pattern items.
>     | 1     | END      |
>     +-------+----------+
>  
> +

Nit: titles in this file are separated by a single empty line.

> +Action: ``TUNNEL_ENCAP``
> +^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs an encapsulation action by encapsulating the flows matched by the
> +pattern items according to the network overlay defined in the
> +``rte_flow_action_tunnel_encap`` pattern items.
> +
> +This action modifies the payload of matched flows. The pattern items specified
> +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
> +set of overlay headers, from the Ethernet header up to the overlay header. The
> +pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type.

Regarding the use of a pattern list, if you consider PMDs are already
iterating on a list of actions when encountering
RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it adds yet another inner loop.

How about making each encountered RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP provide
exactly one item instead (in encap, i.e. reverse order)?

In which case perhaps "GENERIC" would be a better fit than "TUNNEL".

> +
> +- Non-terminating by default.

There's no such property anymore [2].

> +
> +.. _table_rte_flow_action_tunnel_encap:
> +
> +.. table:: TUNNEL_ENCAP
> +
> +   +-------------+---------------------------------------------+
> +   | Field       | Value                                       |
> +   +=============+=============================================+
> +   | ``pattern`` | Virtual tunnel end-point pattern definition |
> +   +-------------+---------------------------------------------+
> +
> +
> +.. _table_rte_flow_action_tunnel_encap_example:
> +
> +.. table:: IPv4 VxLAN flow pattern example.

VxLAN => VXLAN

> +
> +   +-------+--------------------------+------------+
> +   | Index | Flow Item Type           | Flow Item  |
> +   +=======+==========================+============+
> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
> +   +-------+--------------------------+------------+
> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
> +   +-------+--------------------------+------------+
> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
> +   +-------+--------------------------+------------+
> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
> +   +-------+--------------------------+------------+
> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
> +   +-------+--------------------------+------------+

One possible issue is that it relies on objects normally found on the
pattern side of flow rules. Those are supposed to match something, they are
not intended for packet header generation. While their "spec" and "mask"
fields might make sense in this context, the "last" field is odd.

You must define them without leaving anything open for interpretation by
PMDs and users alike. Defining things as "undefined" is fine as long as it's
covered.

> +
> +

Nit: only one empty line necessary here.

> +Action: ``TUNNEL_DECAP``
> +^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs a decapsulation action by stripping all headers of the virtual tunnel
> +end-point overlay up to the header defined by the flow item type of flows
> +matched by the pattern items.

Not necessarily, for instance if one guarantees that flowing traffic only
consists of decap'able packets. You must avoid mandatory dependencies
between patterns and actions since they are normally unrelated.

What you can document on the other hand is that the behavior is undefined
when processing traffic on which the action can't be applied. This is
how RSS level is documented [3].

[3] https://dpdk.org/ml/archives/dev/2018-April/095783.html

> +
> +This action modifies the payload of matched flows. The flow item type specified
> +in the ``rte_flow_action_tunnel_decap`` action structure must defined a valid
> +set of overlay header type.
> +
> +- Non-terminating by default.

See [2].

> +
> +.. _table_rte_flow_action_tunnel_decap:
> +
> +   +---------------+----------------------------------------------+
> +   | Field         | Value                                        |
> +   +===============+==============================================+
> +   | ``item type`` | Item type of tunnel end-point to decapsulate |
> +   +---------------+----------------------------------------------+

"item type" should be the exact name used in the structure.

> +
>  Negative types
>  ~~~~~~~~~~~~~~
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 7d1f89d..6d94423 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -854,14 +854,17 @@ struct rte_flow_item {
>  	const void *mask; /**< Bit-mask applied to spec and last. */
>  };
>  
> +

Unnecessary empty line.

>  /**
>   * Action types.
>   *
>   * Each possible action is represented by a type. Some have associated
>   * configuration structures. Several actions combined in a list can be
> - * affected to a flow rule. That list is not ordered.
> + * affected to a flow rule. That list is not ordered, with the exception of
> + * actions which modify the packet itself, these packet modification actions
> + * must be specified in the explicit order in which they are to be executed.
>   *
> - * They fall in three categories:
> + * They fall in four categories:
>   *
>   * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>   *   processing matched packets by subsequent flow rules, unless overridden
> @@ -870,6 +873,10 @@ struct rte_flow_item {
>   * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
>   *   for additional processing by subsequent flow rules.
>   *
> + * - Non terminating meta actions that do not affect the fate of
> + *   packets but result in modification of the packet itself (SECURITY,
> + *   TUNNEL_ENCAP, TUNNEL_DECAP).
> + *

Same comment as above [1][2].

>   * - Other non terminating meta actions that do not affect the fate of
>   *   packets (END, VOID, MARK, FLAG, COUNT).
>   *
> @@ -1022,7 +1029,42 @@ enum rte_flow_action_type {
>  	 *
>  	 * See struct rte_flow_action_group_count.
>  	 */
> -	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
> +	RTE_FLOW_ACTION_TYPE_GROUP_COUNT,

An empty line would have been needed here (if we agree about no more
GROUP_COUNT.)

> +	/**
> +	 * Encapsulate flow with tunnel defined in
> +	 * rte_flow_action_tunnel_encap structure.
> +	 *
> +	 * See struct rte_flow_action_tunnel_encap.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP,
> +
> +	/**
> +	 * Decapsulate all the headers of the tunnel
> +	 *
> +	 * See struct rte_flow_action_tunnel_decap.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
> +
> +	/**
> +	 * Redirects packets to the logical group of the current device.
> +	 *
> +	 * In a logical hierarchy of groups, which can be used to represent a
> +	 * physical of logical chaining of flow tables, this action allows the
> +	 * terminating action to be a logical group of the same device.
> +	 *
> +	 * See struct rte_flow_action_group.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_GROUP,
> +
> +	/**
> +	 * [META]
> +	 *
> +	 * Set specific metadata field associated with packet which is then
> +	 * available to further pipeline stages.
> +	 *
> +	 * See struct rte_flow_action_metadata.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_METADATA

These two actions should be part of the next patch, I won't comment them
here.

>  };
>  
>  /**
> @@ -1173,6 +1215,42 @@ struct rte_flow_action_group_count {
>  };
>  
>  /**
> + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
> + *
> + * Virtual tunnel end-point encapsulation action data.
> + *
> + * Non-terminating action by default.

See [2].

> + */
> +struct rte_flow_action_tunnel_encap {
> +	struct rte_flow_action_item {
> +		enum rte_flow_item_type type;
> +		/**< Flow item type. */
> +		const void *item;
> +		/**< Flow item definition which points to the data of
> +		 * corresponding rte_flow_item_type.
> +		 */

I see it's a new action type, albeit a bit confusing (there is no
RTE_FLOW_ACTION_TYPE_ITEM).

I suggest the standard pattern item type since you're going with enum
rte_flow_item_type anyway. Keep in mind you need some kind of mask to tell
what fields are relevant. An application might otherwise want to encap with
unsupported properties (e.g. specific IPv4 ToS field and whatnot).

How about a single "struct rte_flow_pattern_item item", neither const and
neither a pointer. It's generic enough, enclosed spec/last/mask pointers
take care of the specifics. You just need to define what's supposed to
happen when "last" is set.

> +	} *pattern;
> +	/**<
> +	 * Tunnel pattern specification (list terminated by the END pattern
> +	 * item).
> +	 */

As previously suggested, how about a single item per encap?

> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
> + *
> + * Virtual tunnel end-point decapsulation action data.
> + *
> + * Non-terminating action by default.
> + */
> +struct rte_flow_action_tunnel_decap {
> +	enum rte_flow_item_type type;
> +	/**<
> +	 * Flow item type of virtual tunnel end-point to be decapsulated
> +	 */
> +};

Note that contrary to ENCAP, DECAP wouldn't necessarily need repeated
actions to peel each layer off. The current definition is fine.

> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> -- 
> 2.7.4
> 

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Mohammad Abdul Awal]

On 06/04/2018 21:26, Adrien Mazarguil wrote:
> On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote:
>> Add new flow action types and associated action data structures to
>> support the encapsulation and decapsulation of the virtual tunnel
>> endpoints.
>>
>> The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching
>> flow to be encapsulated in the virtual tunnel endpoint overlay
>> defined in the tunnel_encap action data.
>>
>> The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual
>> tunnel endpoint overlays up to and including the first instance of
>> the flow item type defined in the tunnel_decap action data for the
>> matching flows.
>>
>> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> This generic approach looks flexible enough to cover the use cases that
> immediately come to mind (VLAN, VXLAN), its design is sound.
>
> However, while I'm aware it's not a concern at this point, it won't be able
> to deal with stateful tunnel or encapsulation types (e.g. IPsec or TCP)
> which will require additional meta data or some run-time assistance from the
> application.
>
> Eventually for more complex use cases, dedicated encap/decap actions will
> have to appear, so the issue I wanted to raise before going further is this:
>
> Going generic inevitably trades some of the usability; flat structures
> dedicated to VXLAN encap/decap with only the needed info to get the job done
> would likely be easier to implement in PMDs and use in applications. Any
> number of such actions can be added to rte_flow without ABI impact.
>
> If VXLAN is the only use case at this point, my suggestion would be to go
> with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP) actions, with fixed
> L2/L3/L4/L5 header definitions to prepend according to RFC 7348.
We can go this way and this will increase the action for more and more 
tunneling protocols being added. Current proposal is already a generic 
approach which specifies as a tunnel for all the tunneling protocols.

> Now we can start with the generic approach, see how it fares and add
> dedicated encap/decap later as needed.
>
> More comments below.
>
>> ---
>>   doc/guides/prog_guide/rte_flow.rst | 77 ++++++++++++++++++++++++++++++++--
>>   lib/librte_ether/rte_flow.h        | 84 ++++++++++++++++++++++++++++++++++++--
>>   2 files changed, 155 insertions(+), 6 deletions(-)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index fd33d19..106fb93 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -997,9 +997,11 @@ Actions
>>   
>>   Each possible action is represented by a type. Some have associated
>>   configuration structures. Several actions combined in a list can be assigned
>> -to a flow rule. That list is not ordered.
>> +to a flow rule. That list is not ordered, with the exception of  actions which
>> +modify the packet itself, these packet modification actions must be specified
>> +in the explicit order in which they are to be executed.
>>   
>> -They fall in three categories:
>> +They fall in four categories:
>>   
>>   - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>>     processing matched packets by subsequent flow rules, unless overridden
>> @@ -1008,8 +1010,11 @@ They fall in three categories:
>>   - Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for
>>     additional processing by subsequent flow rules.
>>   
>> +- Non-terminating meta actions that do not affect the fate of packets but result
>> +  in modification of the packet itself (SECURITY, TUNNEL_ENCAP, TUNNEL_DECAP).
>> +
>>   - Other non-terminating meta actions that do not affect the fate of packets
>> -  (END, VOID, MARK, FLAG, COUNT, SECURITY).
>> +  (END, VOID, MARK, FLAG, COUNT).
> The above changes are not necessary anymore [1][2].
>
> [1] "ethdev: clarify flow API pattern items and actions"
>      https://dpdk.org/ml/archives/dev/2018-April/095776.html
> [2] "ethdev: alter behavior of flow API actions"
>      https://dpdk.org/ml/archives/dev/2018-April/095779.html
OK, we can undo some changes here.
>
>>   When several actions are combined in a flow rule, they should all have
>>   different types (e.g. dropping a packet twice is not possible).
>> @@ -1486,6 +1491,72 @@ fields in the pattern items.
>>      | 1     | END      |
>>      +-------+----------+
>>   
>> +
> Nit: titles in this file are separated by a single empty line.
Fixed.
>
>> +Action: ``TUNNEL_ENCAP``
>> +^^^^^^^^^^^^^^^^^^^^^^
>> +
>> +Performs an encapsulation action by encapsulating the flows matched by the
>> +pattern items according to the network overlay defined in the
>> +``rte_flow_action_tunnel_encap`` pattern items.
>> +
>> +This action modifies the payload of matched flows. The pattern items specified
>> +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
>> +set of overlay headers, from the Ethernet header up to the overlay header. The
>> +pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type.
> Regarding the use of a pattern list, if you consider PMDs are already
> iterating on a list of actions when encountering
> RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it adds yet another inner loop.
We understand that it is implementation specifics. If we do not go for 
another inner loop, all the bundling need to be handled in the same 
function, which seems more clumsy to me. This also breaks the tunnel 
endpoint concept.
>
> How about making each encountered RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP provide
> exactly one item instead (in encap, i.e. reverse order)?
Again, if we have tunnel action, security action, and other actions, all 
the processing and tracking need to be done in one function. Now we will 
need ETH_ENCAP/DECAP, UDP_ENCAP/DECAP, NVGRE_ENCAP/DECAP, etc.
>
> In which case perhaps "GENERIC" would be a better fit than "TUNNEL".
>
>> +
>> +- Non-terminating by default.
> There's no such property anymore [2].
Removed.
>
>> +
>> +.. _table_rte_flow_action_tunnel_encap:
>> +
>> +.. table:: TUNNEL_ENCAP
>> +
>> +   +-------------+---------------------------------------------+
>> +   | Field       | Value                                       |
>> +   +=============+=============================================+
>> +   | ``pattern`` | Virtual tunnel end-point pattern definition |
>> +   +-------------+---------------------------------------------+
>> +
>> +
>> +.. _table_rte_flow_action_tunnel_encap_example:
>> +
>> +.. table:: IPv4 VxLAN flow pattern example.
> VxLAN => VXLAN
Fixed.
>
>> +
>> +   +-------+--------------------------+------------+
>> +   | Index | Flow Item Type           | Flow Item  |
>> +   +=======+==========================+============+
>> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
>> +   +-------+--------------------------+------------+
>> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
>> +   +-------+--------------------------+------------+
>> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
>> +   +-------+--------------------------+------------+
>> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
>> +   +-------+--------------------------+------------+
>> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
>> +   +-------+--------------------------+------------+
> One possible issue is that it relies on objects normally found on the
> pattern side of flow rules. Those are supposed to match something, they are
> not intended for packet header generation. While their "spec" and "mask"
> fields might make sense in this context, the "last" field is odd.
>
> You must define them without leaving anything open for interpretation by
> PMDs and users alike. Defining things as "undefined" is fine as long as it's
> covered.
Please note that the "void *item" in the 
"rte_flow_action_tunnel_encap.pattern" points to the data structure 
defined for the corresponding rte_flow_item_type instead of a 
rte_flow_item structure. As an example, for the rte_flow_item_eth type, 
the "void *item" will point to a "struct rte_flow_item_eth" instance. 
Thats why we have defined struct rte_flow_action_item inside struct 
rte_flow_action_tunnel_encap. So, no question of spec, mask, last anymore.

>
>> +
>> +
> Nit: only one empty line necessary here.
Fixed.
>
>> +Action: ``TUNNEL_DECAP``
>> +^^^^^^^^^^^^^^^^^^^^^^
>> +
>> +Performs a decapsulation action by stripping all headers of the virtual tunnel
>> +end-point overlay up to the header defined by the flow item type of flows
>> +matched by the pattern items.
> Not necessarily, for instance if one guarantees that flowing traffic only
> consists of decap'able packets. You must avoid mandatory dependencies
> between patterns and actions since they are normally unrelated.
>
> What you can document on the other hand is that the behavior is undefined
> when processing traffic on which the action can't be applied. This is
> how RSS level is documented [3].
>
> [3] https://dpdk.org/ml/archives/dev/2018-April/095783.html
Fixed per your suggestion.
>
>> +
>> +This action modifies the payload of matched flows. The flow item type specified
>> +in the ``rte_flow_action_tunnel_decap`` action structure must defined a valid
>> +set of overlay header type.
>> +
>> +- Non-terminating by default.
> See [2].
Removed.
>
>> +
>> +.. _table_rte_flow_action_tunnel_decap:
>> +
>> +   +---------------+----------------------------------------------+
>> +   | Field         | Value                                        |
>> +   +===============+==============================================+
>> +   | ``item type`` | Item type of tunnel end-point to decapsulate |
>> +   +---------------+----------------------------------------------+
> "item type" should be the exact name used in the structure.
Fixed.
>
>> +
>>   Negative types
>>   ~~~~~~~~~~~~~~
>>   
>> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
>> index 7d1f89d..6d94423 100644
>> --- a/lib/librte_ether/rte_flow.h
>> +++ b/lib/librte_ether/rte_flow.h
>> @@ -854,14 +854,17 @@ struct rte_flow_item {
>>   	const void *mask; /**< Bit-mask applied to spec and last. */
>>   };
>>   
>> +
> Unnecessary empty line.
Fixed.
>
>>   /**
>>    * Action types.
>>    *
>>    * Each possible action is represented by a type. Some have associated
>>    * configuration structures. Several actions combined in a list can be
>> - * affected to a flow rule. That list is not ordered.
>> + * affected to a flow rule. That list is not ordered, with the exception of
>> + * actions which modify the packet itself, these packet modification actions
>> + * must be specified in the explicit order in which they are to be executed.
>>    *
>> - * They fall in three categories:
>> + * They fall in four categories:
>>    *
>>    * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>>    *   processing matched packets by subsequent flow rules, unless overridden
>> @@ -870,6 +873,10 @@ struct rte_flow_item {
>>    * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
>>    *   for additional processing by subsequent flow rules.
>>    *
>> + * - Non terminating meta actions that do not affect the fate of
>> + *   packets but result in modification of the packet itself (SECURITY,
>> + *   TUNNEL_ENCAP, TUNNEL_DECAP).
>> + *
> Same comment as above [1][2].
Will be revised and undo.
>
>>    * - Other non terminating meta actions that do not affect the fate of
>>    *   packets (END, VOID, MARK, FLAG, COUNT).
>>    *
>> @@ -1022,7 +1029,42 @@ enum rte_flow_action_type {
>>   	 *
>>   	 * See struct rte_flow_action_group_count.
>>   	 */
>> -	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
>> +	RTE_FLOW_ACTION_TYPE_GROUP_COUNT,
> An empty line would have been needed here (if we agree about no more
> GROUP_COUNT.)
Fixed.
>
>> +	/**
>> +	 * Encapsulate flow with tunnel defined in
>> +	 * rte_flow_action_tunnel_encap structure.
>> +	 *
>> +	 * See struct rte_flow_action_tunnel_encap.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP,
>> +
>> +	/**
>> +	 * Decapsulate all the headers of the tunnel
>> +	 *
>> +	 * See struct rte_flow_action_tunnel_decap.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
>> +
>> +	/**
>> +	 * Redirects packets to the logical group of the current device.
>> +	 *
>> +	 * In a logical hierarchy of groups, which can be used to represent a
>> +	 * physical of logical chaining of flow tables, this action allows the
>> +	 * terminating action to be a logical group of the same device.
>> +	 *
>> +	 * See struct rte_flow_action_group.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_GROUP,
>> +
>> +	/**
>> +	 * [META]
>> +	 *
>> +	 * Set specific metadata field associated with packet which is then
>> +	 * available to further pipeline stages.
>> +	 *
>> +	 * See struct rte_flow_action_metadata.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_METADATA
> These two actions should be part of the next patch, I won't comment them
> here.
It was my mistake. I will fix them.
>
>>   };
>>   
>>   /**
>> @@ -1173,6 +1215,42 @@ struct rte_flow_action_group_count {
>>   };
>>   
>>   /**
>> + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
>> + *
>> + * Virtual tunnel end-point encapsulation action data.
>> + *
>> + * Non-terminating action by default.
> See [2].
Fixed.
>
>> + */
>> +struct rte_flow_action_tunnel_encap {
>> +	struct rte_flow_action_item {
>> +		enum rte_flow_item_type type;
>> +		/**< Flow item type. */
>> +		const void *item;
>> +		/**< Flow item definition which points to the data of
>> +		 * corresponding rte_flow_item_type.
>> +		 */
> I see it's a new action type, albeit a bit confusing (there is no
> RTE_FLOW_ACTION_TYPE_ITEM).
>
> I suggest the standard pattern item type since you're going with enum
> rte_flow_item_type anyway. Keep in mind you need some kind of mask to tell
> what fields are relevant. An application might otherwise want to encap with
> unsupported properties (e.g. specific IPv4 ToS field and whatnot).
>
> How about a single "struct rte_flow_pattern_item item", neither const and
> neither a pointer. It's generic enough, enclosed spec/last/mask pointers
> take care of the specifics. You just need to define what's supposed to
> happen when "last" is set.
Please see the comment above regarding this field.

>
>> +	} *pattern;
>> +	/**<
>> +	 * Tunnel pattern specification (list terminated by the END pattern
>> +	 * item).
>> +	 */
> As previously suggested, how about a single item per encap?
Please see the comment above regarding this field.
>
>> +};
>> +
>> +/**
>> + * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
>> + *
>> + * Virtual tunnel end-point decapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_tunnel_decap {
>> +	enum rte_flow_item_type type;
>> +	/**<
>> +	 * Flow item type of virtual tunnel end-point to be decapsulated
>> +	 */
>> +};
> Note that contrary to ENCAP, DECAP wouldn't necessarily need repeated
> actions to peel each layer off. The current definition is fine.
To clarify, the the decap is upto the PMD to remove all the header for a 
specified type. For example, for

rte_flow_item_type type=RTE_FLOW_ITEM_TYPE_VXLAN, the PMD will peel off (ETH, IPV4, UDP, VXLAN) header all together.

>
>> +
>> +/**
>>    * Definition of a single action.
>>    *
>>    * A list of actions is terminated by a END action.
>> -- 
>> 2.7.4
>>

Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Adrien Mazarguil]

On Mon, Apr 09, 2018 at 05:10:35PM +0100, Mohammad Abdul Awal wrote:
> On 06/04/2018 21:26, Adrien Mazarguil wrote:
> > On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote:
> > > Add new flow action types and associated action data structures to
> > > support the encapsulation and decapsulation of the virtual tunnel
> > > endpoints.
> > > 
> > > The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching
> > > flow to be encapsulated in the virtual tunnel endpoint overlay
> > > defined in the tunnel_encap action data.
> > > 
> > > The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual
> > > tunnel endpoint overlays up to and including the first instance of
> > > the flow item type defined in the tunnel_decap action data for the
> > > matching flows.
> > > 
> > > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > This generic approach looks flexible enough to cover the use cases that
> > immediately come to mind (VLAN, VXLAN), its design is sound.
> > 
> > However, while I'm aware it's not a concern at this point, it won't be able
> > to deal with stateful tunnel or encapsulation types (e.g. IPsec or TCP)
> > which will require additional meta data or some run-time assistance from the
> > application.
> > 
> > Eventually for more complex use cases, dedicated encap/decap actions will
> > have to appear, so the issue I wanted to raise before going further is this:
> > 
> > Going generic inevitably trades some of the usability; flat structures
> > dedicated to VXLAN encap/decap with only the needed info to get the job done
> > would likely be easier to implement in PMDs and use in applications. Any
> > number of such actions can be added to rte_flow without ABI impact.
> > 
> > If VXLAN is the only use case at this point, my suggestion would be to go
> > with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP) actions, with fixed
> > L2/L3/L4/L5 header definitions to prepend according to RFC 7348.
> We can go this way and this will increase the action for more and more
> tunneling protocols being added. Current proposal is already a generic
> approach which specifies as a tunnel for all the tunneling protocols.

Right, on the other hand there are not that many standard encapsulations
offloaded by existing devices. rte_flow could easily handle dedicated
actions for each of them without problem.

My point is that many of those (will eventually) have their own quirks to
manage when doing encap/decap, it's not just a matter of prepending or
removing a bunch of header definitions, otherwise we could as well let
applications simply provide an arbitrary buffer to prepend.

Consider that the "generic" part is already built into rte_flow as the way
patterns and action are handled. Adding another generic layer on top of that
could make things more inconvenient than necessary to applications (my main
concern).

You'd need another layer of validation/error reporting machinery to properly
let applications know they cannot encap VXLAN on top of TCP on top of
QinQinQinQinQ for instance. Either a single bounded encapsulation definition
or a combination at the action list level is needed to avoid that.

> > Now we can start with the generic approach, see how it fares and add
> > dedicated encap/decap later as needed.
> > 
> > More comments below.
<snip>
> > > +Action: ``TUNNEL_ENCAP``
> > > +^^^^^^^^^^^^^^^^^^^^^^
> > > +
> > > +Performs an encapsulation action by encapsulating the flows matched by the
> > > +pattern items according to the network overlay defined in the
> > > +``rte_flow_action_tunnel_encap`` pattern items.
> > > +
> > > +This action modifies the payload of matched flows. The pattern items specified
> > > +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
> > > +set of overlay headers, from the Ethernet header up to the overlay header. The
> > > +pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type.
> > Regarding the use of a pattern list, if you consider PMDs are already
> > iterating on a list of actions when encountering
> > RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it adds yet another inner loop.
> We understand that it is implementation specifics. If we do not go for
> another inner loop, all the bundling need to be handled in the same
> function, which seems more clumsy to me. This also breaks the tunnel
> endpoint concept.
> > 
> > How about making each encountered RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP provide
> > exactly one item instead (in encap, i.e. reverse order)?
> Again, if we have tunnel action, security action, and other actions, all the
> processing and tracking need to be done in one function. Now we will need
> ETH_ENCAP/DECAP, UDP_ENCAP/DECAP, NVGRE_ENCAP/DECAP, etc.

Well, the number of DECAP actions doesn't need to perfectly reflect that of
ENCAP since it implies all preceding layers. No problem with that.

Regarding multiple dedicated actions, my suggestion was for a single generic
one as in this patch, but each instance on the ENCAP side would deal with a
single protocol layer, instead of having a single ENCAP action with multiple
inner layers (and thus an inner loop).

PMDs also gain the ability to precisely report which encap step fails by
making rte_flow_error point to the problematic object to ease debugging of
flow rules on the application side.

Why would that break the tunnel idea and more importantly, how would it
prevent PMD developers from splitting their processing into multiple
functions?

> > 
> > In which case perhaps "GENERIC" would be a better fit than "TUNNEL".
> > 
<snip>
> > > +
> > > +   +-------+--------------------------+------------+
> > > +   | Index | Flow Item Type           | Flow Item  |
> > > +   +=======+==========================+============+
> > > +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
> > > +   +-------+--------------------------+------------+
> > > +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
> > > +   +-------+--------------------------+------------+
> > > +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
> > > +   +-------+--------------------------+------------+
> > > +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
> > > +   +-------+--------------------------+------------+
> > > +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
> > > +   +-------+--------------------------+------------+
> > One possible issue is that it relies on objects normally found on the
> > pattern side of flow rules. Those are supposed to match something, they are
> > not intended for packet header generation. While their "spec" and "mask"
> > fields might make sense in this context, the "last" field is odd.
> > 
> > You must define them without leaving anything open for interpretation by
> > PMDs and users alike. Defining things as "undefined" is fine as long as it's
> > covered.
> Please note that the "void *item" in the
> "rte_flow_action_tunnel_encap.pattern" points to the data structure defined
> for the corresponding rte_flow_item_type instead of a rte_flow_item
> structure. As an example, for the rte_flow_item_eth type, the "void *item"
> will point to a "struct rte_flow_item_eth" instance. Thats why we have
> defined struct rte_flow_action_item inside struct
> rte_flow_action_tunnel_encap. So, no question of spec, mask, last anymore.

Right, I noticed that after commenting its structure definition below.

I think I won't be the only one confused by this approach, also because a
mask is needed in addition to a specification structure, otherwise how do
you plan to tell what fields are relevant in application-provided protocol
headers?

An application might set unusual IPv4/UDP/VXLAN fields and expect them to be
part of the encapsulated traffic. Without a mask, a PMD must take headers
verbatim, and I don't think many devices are ready for that yet.

Hence my other suggestion: defining inflexible $PROTOCOL_(ENCAP|DECAP)
actions that do not allow more than what's defined by official RFCs for
$PROTOCOL.

<snip>
> > > + */
> > > +struct rte_flow_action_tunnel_encap {
> > > +	struct rte_flow_action_item {
> > > +		enum rte_flow_item_type type;
> > > +		/**< Flow item type. */
> > > +		const void *item;
> > > +		/**< Flow item definition which points to the data of
> > > +		 * corresponding rte_flow_item_type.
> > > +		 */
> > I see it's a new action type, albeit a bit confusing (there is no
> > RTE_FLOW_ACTION_TYPE_ITEM).
> > 
> > I suggest the standard pattern item type since you're going with enum
> > rte_flow_item_type anyway. Keep in mind you need some kind of mask to tell
> > what fields are relevant. An application might otherwise want to encap with
> > unsupported properties (e.g. specific IPv4 ToS field and whatnot).
> > 
> > How about a single "struct rte_flow_pattern_item item", neither const and
> > neither a pointer. It's generic enough, enclosed spec/last/mask pointers
> > take care of the specifics. You just need to define what's supposed to
> > happen when "last" is set.
> Please see the comment above regarding this field.

Point still stands, if you need to distinguish spec and mask, a more
complete structure is needed. Instead of adding a new (confusing) type, you
should use rte_flow_item and define what happens when "last" is set.

You should define it as reserved for now, any non-NULL value is an
error. This field might also be useful later.

<snip>
> > > +};
> > > +
> > > +/**
> > > + * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
> > > + *
> > > + * Virtual tunnel end-point decapsulation action data.
> > > + *
> > > + * Non-terminating action by default.
> > > + */
> > > +struct rte_flow_action_tunnel_decap {
> > > +	enum rte_flow_item_type type;
> > > +	/**<
> > > +	 * Flow item type of virtual tunnel end-point to be decapsulated
> > > +	 */
> > > +};
> > Note that contrary to ENCAP, DECAP wouldn't necessarily need repeated
> > actions to peel each layer off. The current definition is fine.
> To clarify, the the decap is upto the PMD to remove all the header for a
> specified type. For example, for
> 
> rte_flow_item_type type=RTE_FLOW_ITEM_TYPE_VXLAN, the PMD will peel off (ETH, IPV4, UDP, VXLAN) header all together.

Yep, that's fine, whether we use multiple actions or a single one doing
multiple things, a single DECAP can peel them off all at once :)

> > 
> > > +
> > > +/**
> > >    * Definition of a single action.
> > >    *
> > >    * A list of actions is terminated by a END action.
> > > -- 
> > > 2.7.4
> > > 

If the reasons I gave did not manage to convince you about choosing between
either fixed (VLAN|VXLAN)_(ENCAP|DECAP) actions or generic encap/decap
actions that deal with a single protocol layer at once instead of the
proposed approach, I'm ready to try it out as an experimental API (all new
objects tagged as experimental) *if* you address the lack of mask, which
remains an open issue.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Shahaf Shuler]

Hi,

Adding small comment on top of Adrien's

Tuesday, April 10, 2018 1:20 PM, Adrien Mazarguil:
> On Mon, Apr 09, 2018 at 05:10:35PM +0100, Mohammad Abdul Awal wrote:
> > On 06/04/2018 21:26, Adrien Mazarguil wrote:
> > > On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote:
> > > > Add new flow action types and associated action data structures to
> > > > support the encapsulation and decapsulation of the virtual tunnel
> > > > endpoints.
> > > >
> > > > The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the
> > > > matching flow to be encapsulated in the virtual tunnel endpoint
> > > > overlay defined in the tunnel_encap action data.
> > > >
> > > > The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all
> > > > virtual tunnel endpoint overlays up to and including the first
> > > > instance of the flow item type defined in the tunnel_decap action
> > > > data for the matching flows.
> > > >
> > > > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > > This generic approach looks flexible enough to cover the use cases
> > > that immediately come to mind (VLAN, VXLAN), its design is sound.
> > >
> > > However, while I'm aware it's not a concern at this point, it won't
> > > be able to deal with stateful tunnel or encapsulation types (e.g.
> > > IPsec or TCP) which will require additional meta data or some
> > > run-time assistance from the application.
> > >
> > > Eventually for more complex use cases, dedicated encap/decap actions
> > > will have to appear, so the issue I wanted to raise before going further is
> this:
> > >
> > > Going generic inevitably trades some of the usability; flat
> > > structures dedicated to VXLAN encap/decap with only the needed info
> > > to get the job done would likely be easier to implement in PMDs and
> > > use in applications. Any number of such actions can be added to rte_flow
> without ABI impact.
> > >
> > > If VXLAN is the only use case at this point, my suggestion would be
> > > to go with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP)
> actions,
> > > with fixed
> > > L2/L3/L4/L5 header definitions to prepend according to RFC 7348.
> > We can go this way and this will increase the action for more and more
> > tunneling protocols being added. Current proposal is already a generic
> > approach which specifies as a tunnel for all the tunneling protocols.
> 
> Right, on the other hand there are not that many standard encapsulations
> offloaded by existing devices. rte_flow could easily handle dedicated actions
> for each of them without problem.
> 
> My point is that many of those (will eventually) have their own quirks to
> manage when doing encap/decap, it's not just a matter of prepending or
> removing a bunch of header definitions, otherwise we could as well let
> applications simply provide an arbitrary buffer to prepend.
> 
> Consider that the "generic" part is already built into rte_flow as the way
> patterns and action are handled. Adding another generic layer on top of that
> could make things more inconvenient than necessary to applications (my
> main concern).
> 
> You'd need another layer of validation/error reporting machinery to properly
> let applications know they cannot encap VXLAN on top of TCP on top of
> QinQinQinQinQ for instance. Either a single bounded encapsulation definition
> or a combination at the action list level is needed to avoid that.
> 
> > > Now we can start with the generic approach, see how it fares and add
> > > dedicated encap/decap later as needed.
> > >
> > > More comments below.
> <snip>
> > > > +Action: ``TUNNEL_ENCAP``
> > > > +^^^^^^^^^^^^^^^^^^^^^^

The ENCAP/DECAP doesn't have to be in the context of tunnel.
For example - let's take GRE - application may want to decap the GRE and encap it with L2. The L2 encapsulation is not related to any tunnel. 
Same for the other direction - VM sends Eth frame, and we want to decap the Eth and encap with GRE.

I think those action should be free from the tunnel association and just provide flow items we want to encap/decap or in a more generic way offset to the packet headers and buffer to encap (not sure how many devices supports that, may be overkill at this point). 

> > > > +
> > > > +Performs an encapsulation action by encapsulating the flows
> > > > +matched by the pattern items according to the network overlay
> > > > +defined in the ``rte_flow_action_tunnel_encap`` pattern items.
> > > > +
> > > > +This action modifies the payload of matched flows. The pattern
> > > > +items specified in the ``rte_flow_action_tunnel_encap`` action
> > > > +structure must defined a valid set of overlay headers, from the
> > > > +Ethernet header up to the overlay header. The pattern must be
> terminated with the RTE_FLOW_ITEM_TYPE_END item type.
> > > Regarding the use of a pattern list, if you consider PMDs are
> > > already iterating on a list of actions when encountering
> > > RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it adds yet another inner
> loop.
> > We understand that it is implementation specifics. If we do not go for
> > another inner loop, all the bundling need to be handled in the same
> > function, which seems more clumsy to me. This also breaks the tunnel
> > endpoint concept.
> > >
> > > How about making each encountered
> RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
> > > provide exactly one item instead (in encap, i.e. reverse order)?
> > Again, if we have tunnel action, security action, and other actions,
> > all the processing and tracking need to be done in one function. Now
> > we will need ETH_ENCAP/DECAP, UDP_ENCAP/DECAP,
> NVGRE_ENCAP/DECAP, etc.
> 
> Well, the number of DECAP actions doesn't need to perfectly reflect that of
> ENCAP since it implies all preceding layers. No problem with that.
> 
> Regarding multiple dedicated actions, my suggestion was for a single generic
> one as in this patch, but each instance on the ENCAP side would deal with a
> single protocol layer, instead of having a single ENCAP action with multiple
> inner layers (and thus an inner loop).
> 
> PMDs also gain the ability to precisely report which encap step fails by making
> rte_flow_error point to the problematic object to ease debugging of flow
> rules on the application side.
> 
> Why would that break the tunnel idea and more importantly, how would it
> prevent PMD developers from splitting their processing into multiple
> functions?
> 
> > >
> > > In which case perhaps "GENERIC" would be a better fit than "TUNNEL".
> > >
> <snip>
> > > > +
> > > > +   +-------+--------------------------+------------+
> > > > +   | Index | Flow Item Type           | Flow Item  |
> > > > +   +=======+==========================+============+
> > > > +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
> > > > +   +-------+--------------------------+------------+
> > > > +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
> > > > +   +-------+--------------------------+------------+
> > > > +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
> > > > +   +-------+--------------------------+------------+
> > > > +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
> > > > +   +-------+--------------------------+------------+
> > > > +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
> > > > +   +-------+--------------------------+------------+
> > > One possible issue is that it relies on objects normally found on
> > > the pattern side of flow rules. Those are supposed to match
> > > something, they are not intended for packet header generation. While
> their "spec" and "mask"
> > > fields might make sense in this context, the "last" field is odd.
> > >
> > > You must define them without leaving anything open for
> > > interpretation by PMDs and users alike. Defining things as
> > > "undefined" is fine as long as it's covered.
> > Please note that the "void *item" in the
> > "rte_flow_action_tunnel_encap.pattern" points to the data structure
> > defined for the corresponding rte_flow_item_type instead of a
> > rte_flow_item structure. As an example, for the rte_flow_item_eth type,
> the "void *item"
> > will point to a "struct rte_flow_item_eth" instance. Thats why we have
> > defined struct rte_flow_action_item inside struct
> > rte_flow_action_tunnel_encap. So, no question of spec, mask, last
> anymore.
> 
> Right, I noticed that after commenting its structure definition below.
> 
> I think I won't be the only one confused by this approach, also because a
> mask is needed in addition to a specification structure, otherwise how do you
> plan to tell what fields are relevant in application-provided protocol headers?
> 
> An application might set unusual IPv4/UDP/VXLAN fields and expect them to
> be part of the encapsulated traffic. Without a mask, a PMD must take
> headers verbatim, and I don't think many devices are ready for that yet.
> 
> Hence my other suggestion: defining inflexible $PROTOCOL_(ENCAP|DECAP)
> actions that do not allow more than what's defined by official RFCs for
> $PROTOCOL.
> 
> <snip>
> > > > + */
> > > > +struct rte_flow_action_tunnel_encap {
> > > > +	struct rte_flow_action_item {
> > > > +		enum rte_flow_item_type type;
> > > > +		/**< Flow item type. */
> > > > +		const void *item;
> > > > +		/**< Flow item definition which points to the data of
> > > > +		 * corresponding rte_flow_item_type.
> > > > +		 */
> > > I see it's a new action type, albeit a bit confusing (there is no
> > > RTE_FLOW_ACTION_TYPE_ITEM).
> > >
> > > I suggest the standard pattern item type since you're going with
> > > enum rte_flow_item_type anyway. Keep in mind you need some kind of
> > > mask to tell what fields are relevant. An application might
> > > otherwise want to encap with unsupported properties (e.g. specific IPv4
> ToS field and whatnot).
> > >
> > > How about a single "struct rte_flow_pattern_item item", neither
> > > const and neither a pointer. It's generic enough, enclosed
> > > spec/last/mask pointers take care of the specifics. You just need to
> > > define what's supposed to happen when "last" is set.
> > Please see the comment above regarding this field.
> 
> Point still stands, if you need to distinguish spec and mask, a more complete
> structure is needed. Instead of adding a new (confusing) type, you should
> use rte_flow_item and define what happens when "last" is set.
> 
> You should define it as reserved for now, any non-NULL value is an error. This
> field might also be useful later.
> 
> <snip>
> > > > +};
> > > > +
> > > > +/**
> > > > + * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
> > > > + *
> > > > + * Virtual tunnel end-point decapsulation action data.
> > > > + *
> > > > + * Non-terminating action by default.
> > > > + */
> > > > +struct rte_flow_action_tunnel_decap {
> > > > +	enum rte_flow_item_type type;
> > > > +	/**<
> > > > +	 * Flow item type of virtual tunnel end-point to be decapsulated
> > > > +	 */
> > > > +};
> > > Note that contrary to ENCAP, DECAP wouldn't necessarily need
> > > repeated actions to peel each layer off. The current definition is fine.
> > To clarify, the the decap is upto the PMD to remove all the header for
> > a specified type. For example, for
> >
> > rte_flow_item_type type=RTE_FLOW_ITEM_TYPE_VXLAN, the PMD will
> peel off (ETH, IPV4, UDP, VXLAN) header all together.
> 
> Yep, that's fine, whether we use multiple actions or a single one doing
> multiple things, a single DECAP can peel them off all at once :)
> 
> > >
> > > > +
> > > > +/**
> > > >    * Definition of a single action.
> > > >    *
> > > >    * A list of actions is terminated by a END action.
> > > > --
> > > > 2.7.4
> > > >
> 
> If the reasons I gave did not manage to convince you about choosing
> between
> either fixed (VLAN|VXLAN)_(ENCAP|DECAP) actions or generic encap/decap
> actions that deal with a single protocol layer at once instead of the
> proposed approach, I'm ready to try it out as an experimental API (all new
> objects tagged as experimental) *if* you address the lack of mask, which
> remains an open issue.
> 
> --
> Adrien Mazarguil
> 6WIND

Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions

[Doherty, Declan]

On 06/04/2018 9:26 PM, Adrien Mazarguil wrote:
> On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote:
>> Add new flow action types and associated action data structures to
>> support the encapsulation and decapsulation of the virtual tunnel
>> endpoints.
>>
>> The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching
>> flow to be encapsulated in the virtual tunnel endpoint overlay
>> defined in the tunnel_encap action data.
>>
>> The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual
>> tunnel endpoint overlays up to and including the first instance of
>> the flow item type defined in the tunnel_decap action data for the
>> matching flows.
>>
>> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> 
> This generic approach looks flexible enough to cover the use cases that
> immediately come to mind (VLAN, VXLAN), its design is sound.
> 
> However, while I'm aware it's not a concern at this point, it won't be able
> to deal with stateful tunnel or encapsulation types (e.g. IPsec or TCP)
> which will require additional meta data or some run-time assistance from the
> application.
> 
> Eventually for more complex use cases, dedicated encap/decap actions will
> have to appear, so the issue I wanted to raise before going further is this:
> 
> Going generic inevitably trades some of the usability; flat structures
> dedicated to VXLAN encap/decap with only the needed info to get the job done
> would likely be easier to implement in PMDs and use in applications. Any
> number of such actions can be added to rte_flow without ABI impact.
> 
> If VXLAN is the only use case at this point, my suggestion would be to go
> with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP) actions, with fixed
> L2/L3/L4/L5 header definitions to prepend according to RFC 7348.
> 
> Now we can start with the generic approach, see how it fares and add
> dedicated encap/decap later as needed.
> 
> More comments below.
> 

I understand where your coming from here now, I think the best approach 
to take is as you say to have the explicit 
RTE_FLOW_ACTION_TYPE_(PROTOCOL)_(ENCAP|DECAP) actions and make it 
explicit in the action description that it operates within the 
constraints of the corresponding RFC. I'll cover VXLAN and NVGRE as 
that's what we have been testing with today, as you point it will be 
easy to add new protocol encap/decaps without breaking ABI. Also I think 
having a explicit decap action for each protocol makes the overall usage 
model simpler as it negates the need for action data.

>> ---
>>   doc/guides/prog_guide/rte_flow.rst | 77 ++++++++++++++++++++++++++++++++--
>>   lib/librte_ether/rte_flow.h        | 84 ++++++++++++++++++++++++++++++++++++--
>>   2 files changed, 155 insertions(+), 6 deletions(-)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index fd33d19..106fb93 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -997,9 +997,11 @@ Actions
>>   
>>   Each possible action is represented by a type. Some have associated
>>   configuration structures. Several actions combined in a list can be assigned
>> -to a flow rule. That list is not ordered.
>> +to a flow rule. That list is not ordered, with the exception of  actions which
>> +modify the packet itself, these packet modification actions must be specified
>> +in the explicit order in which they are to be executed.
>>   
>> -They fall in three categories:
>> +They fall in four categories:
>>   
>>   - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>>     processing matched packets by subsequent flow rules, unless overridden
>> @@ -1008,8 +1010,11 @@ They fall in three categories:
>>   - Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for
>>     additional processing by subsequent flow rules.
>>   
>> +- Non-terminating meta actions that do not affect the fate of packets but result
>> +  in modification of the packet itself (SECURITY, TUNNEL_ENCAP, TUNNEL_DECAP).
>> +
>>   - Other non-terminating meta actions that do not affect the fate of packets
>> -  (END, VOID, MARK, FLAG, COUNT, SECURITY).
>> +  (END, VOID, MARK, FLAG, COUNT).
> 
> The above changes are not necessary anymore [1][2].
> 
> [1] "ethdev: clarify flow API pattern items and actions"
>      https://dpdk.org/ml/archives/dev/2018-April/095776.html
> [2] "ethdev: alter behavior of flow API actions"
>      https://dpdk.org/ml/archives/dev/2018-April/095779.html
> 

ok, I'll remove theses in the next version

>>   When several actions are combined in a flow rule, they should all have
>>   different types (e.g. dropping a packet twice is not possible).
>> @@ -1486,6 +1491,72 @@ fields in the pattern items.
>>      | 1     | END      |
>>      +-------+----------+
>>   
>> +
> 
> Nit: titles in this file are separated by a single empty line.
> 
>> +Action: ``TUNNEL_ENCAP``
>> +^^^^^^^^^^^^^^^^^^^^^^
>> +
>> +Performs an encapsulation action by encapsulating the flows matched by the
>> +pattern items according to the network overlay defined in the
>> +``rte_flow_action_tunnel_encap`` pattern items.
>> +
>> +This action modifies the payload of matched flows. The pattern items specified
>> +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
>> +set of overlay headers, from the Ethernet header up to the overlay header. The
>> +pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type.
> 
> Regarding the use of a pattern list, if you consider PMDs are already
> iterating on a list of actions when encountering
> RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it adds yet another inner loop.
> 
> How about making each encountered RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP provide
> exactly one item instead (in encap, i.e. reverse order)?
> 
> In which case perhaps "GENERIC" would be a better fit than "TUNNEL".
> 

Personally after trying all of these approach I prefer the the protocol 
specific full encap/decap model you suggested above.

>> +
>> +- Non-terminating by default.
> 
> There's no such property anymore [2].
> 
>> +
>> +.. _table_rte_flow_action_tunnel_encap:
>> +
>> +.. table:: TUNNEL_ENCAP
>> +
>> +   +-------------+---------------------------------------------+
>> +   | Field       | Value                                       |
>> +   +=============+=============================================+
>> +   | ``pattern`` | Virtual tunnel end-point pattern definition |
>> +   +-------------+---------------------------------------------+
>> +
>> +
>> +.. _table_rte_flow_action_tunnel_encap_example:
>> +
>> +.. table:: IPv4 VxLAN flow pattern example.
> 
> VxLAN => VXLAN
> 
>> +
>> +   +-------+--------------------------+------------+
>> +   | Index | Flow Item Type           | Flow Item  |
>> +   +=======+==========================+============+
>> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | eth item   |
>> +   +-------+--------------------------+------------+
>> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | ipv4 item  |
>> +   +-------+--------------------------+------------+
>> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | udp item   |
>> +   +-------+--------------------------+------------+
>> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | vxlan item |
>> +   +-------+--------------------------+------------+
>> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL       |
>> +   +-------+--------------------------+------------+
> 
> One possible issue is that it relies on objects normally found on the
> pattern side of flow rules. Those are supposed to match something, they are
> not intended for packet header generation. While their "spec" and "mask"
> fields might make sense in this context, the "last" field is odd.
> 
> You must define them without leaving anything open for interpretation by
> PMDs and users alike. Defining things as "undefined" is fine as long as it's
> covered.
> 
>> +
>> +
> 
> Nit: only one empty line necessary here.
> 
>> +Action: ``TUNNEL_DECAP``
>> +^^^^^^^^^^^^^^^^^^^^^^
>> +
>> +Performs a decapsulation action by stripping all headers of the virtual tunnel
>> +end-point overlay up to the header defined by the flow item type of flows
>> +matched by the pattern items.
> 
> Not necessarily, for instance if one guarantees that flowing traffic only
> consists of decap'able packets. You must avoid mandatory dependencies
> between patterns and actions since they are normally unrelated.
> 
> What you can document on the other hand is that the behavior is undefined
> when processing traffic on which the action can't be applied. This is
> how RSS level is documented [3].
> 
> [3] https://dpdk.org/ml/archives/dev/2018-April/095783.html
> 
>> +
>> +This action modifies the payload of matched flows. The flow item type specified
>> +in the ``rte_flow_action_tunnel_decap`` action structure must defined a valid
>> +set of overlay header type.
>> +
>> +- Non-terminating by default.
> 
> See [2].
> 
>> +
>> +.. _table_rte_flow_action_tunnel_decap:
>> +
>> +   +---------------+----------------------------------------------+
>> +   | Field         | Value                                        |
>> +   +===============+==============================================+
>> +   | ``item type`` | Item type of tunnel end-point to decapsulate |
>> +   +---------------+----------------------------------------------+
> 
> "item type" should be the exact name used in the structure.
> 
>> +
>>   Negative types
>>   ~~~~~~~~~~~~~~
>>   
>> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
>> index 7d1f89d..6d94423 100644
>> --- a/lib/librte_ether/rte_flow.h
>> +++ b/lib/librte_ether/rte_flow.h
>> @@ -854,14 +854,17 @@ struct rte_flow_item {
>>   	const void *mask; /**< Bit-mask applied to spec and last. */
>>   };
>>   
>> +
> 
> Unnecessary empty line.
> 
>>   /**
>>    * Action types.
>>    *
>>    * Each possible action is represented by a type. Some have associated
>>    * configuration structures. Several actions combined in a list can be
>> - * affected to a flow rule. That list is not ordered.
>> + * affected to a flow rule. That list is not ordered, with the exception of
>> + * actions which modify the packet itself, these packet modification actions
>> + * must be specified in the explicit order in which they are to be executed.
>>    *
>> - * They fall in three categories:
>> + * They fall in four categories:
>>    *
>>    * - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent
>>    *   processing matched packets by subsequent flow rules, unless overridden
>> @@ -870,6 +873,10 @@ struct rte_flow_item {
>>    * - Non terminating actions (PASSTHRU, DUP) that leave matched packets up
>>    *   for additional processing by subsequent flow rules.
>>    *
>> + * - Non terminating meta actions that do not affect the fate of
>> + *   packets but result in modification of the packet itself (SECURITY,
>> + *   TUNNEL_ENCAP, TUNNEL_DECAP).
>> + *
> 
> Same comment as above [1][2].
> 
>>    * - Other non terminating meta actions that do not affect the fate of
>>    *   packets (END, VOID, MARK, FLAG, COUNT).
>>    *
>> @@ -1022,7 +1029,42 @@ enum rte_flow_action_type {
>>   	 *
>>   	 * See struct rte_flow_action_group_count.
>>   	 */
>> -	RTE_FLOW_ACTION_TYPE_GROUP_COUNT
>> +	RTE_FLOW_ACTION_TYPE_GROUP_COUNT,
> 
> An empty line would have been needed here (if we agree about no more
> GROUP_COUNT.)
> 
>> +	/**
>> +	 * Encapsulate flow with tunnel defined in
>> +	 * rte_flow_action_tunnel_encap structure.
>> +	 *
>> +	 * See struct rte_flow_action_tunnel_encap.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP,
>> +
>> +	/**
>> +	 * Decapsulate all the headers of the tunnel
>> +	 *
>> +	 * See struct rte_flow_action_tunnel_decap.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
>> +
>> +	/**
>> +	 * Redirects packets to the logical group of the current device.
>> +	 *
>> +	 * In a logical hierarchy of groups, which can be used to represent a
>> +	 * physical of logical chaining of flow tables, this action allows the
>> +	 * terminating action to be a logical group of the same device.
>> +	 *
>> +	 * See struct rte_flow_action_group.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_GROUP,
>> +
>> +	/**
>> +	 * [META]
>> +	 *
>> +	 * Set specific metadata field associated with packet which is then
>> +	 * available to further pipeline stages.
>> +	 *
>> +	 * See struct rte_flow_action_metadata.
>> +	 */
>> +	RTE_FLOW_ACTION_TYPE_METADATA
> 
> These two actions should be part of the next patch, I won't comment them
> here.
> 

sorry that was a rebase issue.

>>   };
>>   
>>   /**
>> @@ -1173,6 +1215,42 @@ struct rte_flow_action_group_count {
>>   };
>>   
>>   /**
>> + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
>> + *
>> + * Virtual tunnel end-point encapsulation action data.
>> + *
>> + * Non-terminating action by default.
> 
> See [2].
> 
>> + */
>> +struct rte_flow_action_tunnel_encap {
>> +	struct rte_flow_action_item {
>> +		enum rte_flow_item_type type;
>> +		/**< Flow item type. */
>> +		const void *item;
>> +		/**< Flow item definition which points to the data of
>> +		 * corresponding rte_flow_item_type.
>> +		 */
> 
> I see it's a new action type, albeit a bit confusing (there is no
> RTE_FLOW_ACTION_TYPE_ITEM).
> 
> I suggest the standard pattern item type since you're going with enum
> rte_flow_item_type anyway. Keep in mind you need some kind of mask to tell
> what fields are relevant. An application might otherwise want to encap with
> unsupported properties (e.g. specific IPv4 ToS field and whatnot).
> sure, that makes sense.

> How about a single "struct rte_flow_pattern_item item", neither const and
> neither a pointer. It's generic enough, enclosed spec/last/mask pointers
> take care of the specifics. You just need to define what's supposed to
> happen when "last" is set.

I think that a note to make it explicit that the last item is 
unused/ignored in the encap case should be sufficient.

> 
>> +	} *pattern;
>> +	/**<
>> +	 * Tunnel pattern specification (list terminated by the END pattern
>> +	 * item).
>> +	 */
> 
> As previously suggested, how about a single item per encap?
> 

For the encap case I still prefer a single definition as an array of 
flow items. I think it will make it easier to verify a valid pattern has 
all the required elements in terms of the protocol encapsulation being 
specified. I see how it could work the other way too, but the validity 
of the pattern definition comes from the action, not from any specific 
item in the pattern. I think that the error reporting is verbose enough 
to allow PMDs to specify exactly why a pattern is invalid for an action. 
For instance if you missed the UDP item in a VXLAN encap action 
definition, in the single item per encap model you would get the error 
on the IP item, but it may actually be perfectly valid, the error is 
that you missed the UDP item.


>> +};
>> +
>> +/**
>> + * RTE_FLOW_ACTION_TYP_TUNNEL_DECAP
>> + *
>> + * Virtual tunnel end-point decapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_tunnel_decap {
>> +	enum rte_flow_item_type type;
>> +	/**<
>> +	 * Flow item type of virtual tunnel end-point to be decapsulated
>> +	 */
>> +};
> 
> Note that contrary to ENCAP, DECAP wouldn't necessarily need repeated
> actions to peel each layer off. The current definition is fine.
> 
>> +
>> +/**
>>    * Definition of a single action.
>>    *
>>    * A list of actions is terminated by a END action.
>> -- 
>> 2.7.4
>>
> 

[dpdk-dev] [PATCH v3 3/4] ethdev: Add group action type to rte_flow

[Declan Doherty]

Add group action type which defines a terminating action which
allows a matched flow to be redirect to a group. This allows logical
flow table hierarchies to be managed through rte_flow.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 23 +++++++++++++++++++++++
 lib/librte_ether/rte_flow.h        | 15 +++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 106fb93..2f0a47a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1557,6 +1557,29 @@ set of overlay header type.
    | ``item type`` | Item type of tunnel end-point to decapsulate |
    +---------------+----------------------------------------------+
 
+
+Action: ``GROUP``
+^^^^^^^^^^^^^^^^^
+
+Redirects packets to a group on the current device.
+
+In a hierarchy of groups, which can be used to represent physical or logical
+flow tables on the device, this action allows the terminating action to be a
+group on that device.
+
+- Terminating by default.
+
+.. _table_rte_flow_action_group:
+
+.. table:: GROUP
+
+   +--------------+---------------------------------+
+   | Field        | Value                           |
+   +==============+=================================+
+   | ``id``       | Group ID to redirect packets to |
+   +--------------+---------------------------------+
+
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 6d94423..968a23b 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1251,6 +1251,21 @@ struct rte_flow_action_tunnel_decap {
 };
 
 /**
+ * RTE_FLOW_ACTION_TYPE_GROUP
+ *
+ * Redirects packets to a group on the current device.
+ *
+ * In a hierarchy of groups, which can be used to represent physical or logical
+ * flow tables on the device, this action allows the terminating action to be a
+ * group on that device.
+ *
+ * Terminating by default.
+ */
+struct rte_flow_action_group {
+	uint32_t id;
+};
+
+/**
  * Definition of a single action.
  *
  * A list of actions is terminated by a END action.
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 3/4] ethdev: Add group action type to rte_flow

[Adrien Mazarguil]

On Fri, Apr 06, 2018 at 01:24:02PM +0100, Declan Doherty wrote:
> Add group action type which defines a terminating action which
> allows a matched flow to be redirect to a group. This allows logical
> flow table hierarchies to be managed through rte_flow.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

OK, I'm wondering if perhaps with the addition of this action, we should
redefine groups as unlinked by default?

Currently traffic enters through the flow rule with the lowest priority of
the group with the lowest ID and iterates through subsequent flow rules and
groups until matched by a flow rule without PASSTHRU (according to latest
definition [1]).

This would make jumps between groups always explicit, not necessarily a bad
idea given no PMD implements groups as of yet. Thoughts?

Also as a rather fundamental API addition, I suggest to add it after
RTE_FLOW_ACTION_TYPE_PASSTHRU. It's OK because ABI is already broken. You
just need to mention it in the commit log [1].

Another suggestion would be to rename it "JUMP" (reasons below).

[1] "ethdev: alter behavior of flow API actions"
    http://dpdk.org/ml/archives/dev/2018-April/095779.html

> ---
>  doc/guides/prog_guide/rte_flow.rst | 23 +++++++++++++++++++++++
>  lib/librte_ether/rte_flow.h        | 15 +++++++++++++++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 106fb93..2f0a47a 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1557,6 +1557,29 @@ set of overlay header type.
>     | ``item type`` | Item type of tunnel end-point to decapsulate |
>     +---------------+----------------------------------------------+
>  
> +

Unnecessary empty line.

> +Action: ``GROUP``
> +^^^^^^^^^^^^^^^^^
> +
> +Redirects packets to a group on the current device.
> +
> +In a hierarchy of groups, which can be used to represent physical or logical
> +flow tables on the device, this action allows the terminating action to be a
> +group on that device.
> +
> +- Terminating by default.

Keep in mind there's no such thing as a terminating action anymore [1].

> +
> +.. _table_rte_flow_action_group:
> +
> +.. table:: GROUP
> +
> +   +--------------+---------------------------------+
> +   | Field        | Value                           |
> +   +==============+=================================+
> +   | ``id``       | Group ID to redirect packets to |
> +   +--------------+---------------------------------+

"Field" column can be shrunk somewhat.

> +
> +
>  Negative types
>  ~~~~~~~~~~~~~~
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 6d94423..968a23b 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -1251,6 +1251,21 @@ struct rte_flow_action_tunnel_decap {
>  };
>  
>  /**
> + * RTE_FLOW_ACTION_TYPE_GROUP

Its addition to enum rte_flow_action_type should be part of this commit.

> + *
> + * Redirects packets to a group on the current device.
> + *
> + * In a hierarchy of groups, which can be used to represent physical or logical
> + * flow tables on the device, this action allows the terminating action to be a
> + * group on that device.
> + *
> + * Terminating by default.

See [1].

> + */
> +struct rte_flow_action_group {
> +	uint32_t id;

Assuming this structure is named rte_flow_action_jump, naming this field
"group" would match the attribute of the same name.

> +};
> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> -- 
> 2.7.4
> 

Don't forget testpmd code and documentation update.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v3 3/4] ethdev: Add group action type to rte_flow

[Doherty, Declan]

On 06/04/2018 9:26 PM, Adrien Mazarguil wrote:
> On Fri, Apr 06, 2018 at 01:24:02PM +0100, Declan Doherty wrote:
>> Add group action type which defines a terminating action which
>> allows a matched flow to be redirect to a group. This allows logical
>> flow table hierarchies to be managed through rte_flow.
>>
>> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> 
> OK, I'm wondering if perhaps with the addition of this action, we should
> redefine groups as unlinked by default?

Sure that makes sense to me, as in a device with multiple groups I would 
image that you are more likely to have a tree hierarchy of groups, based 
on something like packet types, rather than a straight priority ordering.
> 
> Currently traffic enters through the flow rule with the lowest priority of
> the group with the lowest ID and iterates through subsequent flow rules and
> groups until matched by a flow rule without PASSTHRU (according to latest
> definition [1]).
> 
> This would make jumps between groups always explicit, not necessarily a bad
> idea given no PMD implements groups as of yet. Thoughts?

I think this is a good idea, as in the case with multiple groups which 
support the same packet time, there may be some flows which could 
potentially hit on many groups, but should be directed to a specific 
group. If group matching was always resolved in a strict priority it 
would result on a hit on an incorrect group. I think making it explicit 
from the start makes sense.

One issue is that groups will need to be populated with a specific rule 
to allow flow to fall through to the next priority group if no match is 
found on the default group.

This just requires changes to the API comments, correct? Do you want to 
capture those in [1] or would you like me to make them with this patch?

> 
> Also as a rather fundamental API addition, I suggest to add it after
> RTE_FLOW_ACTION_TYPE_PASSTHRU. It's OK because ABI is already broken. You
> just need to mention it in the commit log [1].

no problem, will do.

> 
> Another suggestion would be to rename it "JUMP" (reasons below).

I have no issue with changing the action name to JUMP
> 
> [1] "ethdev: alter behavior of flow API actions"
>      http://dpdk.org/ml/archives/dev/2018-April/095779.html
> 
>> ---
>>   doc/guides/prog_guide/rte_flow.rst | 23 +++++++++++++++++++++++
>>   lib/librte_ether/rte_flow.h        | 15 +++++++++++++++
>>   2 files changed, 38 insertions(+)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index 106fb93..2f0a47a 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -1557,6 +1557,29 @@ set of overlay header type.
>>      | ``item type`` | Item type of tunnel end-point to decapsulate |
>>      +---------------+----------------------------------------------+
>>   
>> +
> 
> Unnecessary empty line.
> 
>> +Action: ``GROUP``
>> +^^^^^^^^^^^^^^^^^
>> +
>> +Redirects packets to a group on the current device.
>> +
>> +In a hierarchy of groups, which can be used to represent physical or logical
>> +flow tables on the device, this action allows the terminating action to be a
>> +group on that device.
>> +
>> +- Terminating by default.
> 
> Keep in mind there's no such thing as a terminating action anymore [1].
> 
>> +
>> +.. _table_rte_flow_action_group:
>> +
>> +.. table:: GROUP
>> +
>> +   +--------------+---------------------------------+
>> +   | Field        | Value                           |
>> +   +==============+=================================+
>> +   | ``id``       | Group ID to redirect packets to |
>> +   +--------------+---------------------------------+
> 
> "Field" column can be shrunk somewhat.
> 
>> +
>> +
>>   Negative types
>>   ~~~~~~~~~~~~~~
>>   
>> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
>> index 6d94423..968a23b 100644
>> --- a/lib/librte_ether/rte_flow.h
>> +++ b/lib/librte_ether/rte_flow.h
>> @@ -1251,6 +1251,21 @@ struct rte_flow_action_tunnel_decap {
>>   };
>>   
>>   /**
>> + * RTE_FLOW_ACTION_TYPE_GROUP
> 
> Its addition to enum rte_flow_action_type should be part of this commit.
> 
that was a rebasing issue, I'll fix in next revision

>> + *
>> + * Redirects packets to a group on the current device.
>> + *
>> + * In a hierarchy of groups, which can be used to represent physical or logical
>> + * flow tables on the device, this action allows the terminating action to be a
>> + * group on that device.
>> + *
>> + * Terminating by default.
> 
> See [1].
> 
>> + */
>> +struct rte_flow_action_group {
>> +	uint32_t id;
> 
> Assuming this structure is named rte_flow_action_jump, naming this field
> "group" would match the attribute of the same name.
> 
>> +};
>> +
>> +/**
>>    * Definition of a single action.
>>    *
>>    * A list of actions is terminated by a END action.
>> -- 
>> 2.7.4
>>
> 
> Don't forget testpmd code and documentation update.
> 

[dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support

[Declan Doherty]

Introduces a new action type RTE_FLOW_ACTION_TYPE_METADATA which enables
metadata extraction from a packet into a specified metadata container
for consumption on further pipeline stages or for propagation to the host
interface.

As complementary function to the new metadata action type this patch also
introduces a new flow item type which enables flow patterns to specify a
specific metadata container as a matching criteria for a flow rule.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 85 ++++++++++++++++++++++++++++++++++++++
 lib/librte_ether/rte_flow.h        | 42 +++++++++++++++++++
 2 files changed, 127 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2f0a47a..9b2b0e3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1580,6 +1580,91 @@ group on that device.
    +--------------+---------------------------------+
 
 
+
+Action: ``METADATA``
+^^^^^^^^^^^^^^^^^^^^
+
+Action extracts data from packet into user specified metadata field in pipeline
+for use in downstream processing stages or for propagation to host interface.
+
+The pattern mask is used to define the data which is to be extracted from the
+packet. The mask pattern types defined in the action metadata pattern must
+match the flow pattern definitions up to the last flow item from which data is
+to be extracted.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_metadata:
+
+.. table:: METADATA
+
+   +--------------+---------------------------+
+   | Field        | Value                     |
+   +==============+===========================+
+   | ``id``       | Metadata field Identifier |
+   +--------------+---------------------------+
+   | ``pattern``  | Extraction mask pattern   |
+   +--------------+---------------------------+
+
+The example below demonstrates how the extraction mask to extract the source/
+destination IPv4 address, the UDP destination port and and the VxLAN VNI can be
+specified.
+
+.. _table_rte_flow_action_metadata_example:
+
+.. table:: IPv4 VxLAN metadata extraction
+
+   +-------+--------------------------+-----------------------------------+
+   | Index | Flow Item Type           | Flow Mask                         |
+   +=======+==========================+===================================+
+   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
+   |       |                          +-----------------------------------+
+   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
+   |       |                          +-----------------------------------+
+   |       |                          | .type = RTE_BE16(0x0)             |
+   +-------+--------------------------+-----------------------------------+
+   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0xffffffff)  |
+   |       |                          +-----------------------------------+
+   |       |                          | .dst_addr = RTE_BE32(0xffffffff)  |
+   +-------+--------------------------+-----------------------------------+
+   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
+   |       |                          +-----------------------------------+
+   |       |                          | .dst_port = RTE_BE16(0xffff)      |
+   +-------+--------------------------+-----------------------------------+
+   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
+   +-------+--------------------------+-----------------------------------+
+   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
+   +-------+--------------------------+-----------------------------------+
+
+If only the VxLAN VNI extraction was required then the extraction mask would be
+as follows.
+
+.. _table_rte_flow_action_metadata_example_2:
+
+.. table::  VxLAN VNI metadata extraction
+
+   +-------+--------------------------+-----------------------------------+
+   | Index | Flow Item Type           | Flow Mask                         |
+   +=======+==========================+===================================+
+   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
+   |       |                          +-----------------------------------+
+   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
+   |       |                          +-----------------------------------+
+   |       |                          | .type = RTE_BE16(0x0)             |
+   +-------+--------------------------+-----------------------------------+
+   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0x0)         |
+   |       |                          +-----------------------------------+
+   |       |                          | .dst_addr = RTE_BE32(0x0)         |
+   +-------+--------------------------+-----------------------------------+
+   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
+   |       |                          +-----------------------------------+
+   |       |                          | .dst_port = RTE_BE16(0x0)         |
+   +-------+--------------------------+-----------------------------------+
+   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
+   +-------+--------------------------+-----------------------------------+
+   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
+   +-------+--------------------------+-----------------------------------+
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 968a23b..f75dee7 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -323,6 +323,13 @@ enum rte_flow_item_type {
 	 * See struct rte_flow_item_geneve.
 	 */
 	RTE_FLOW_ITEM_TYPE_GENEVE,
+
+	/**
+	 * Matches specified pipeline metadata field.
+	 *
+	 * See struct rte_flow_item_metadata.
+	 */
+	RTE_FLOW_ITEM_TYPE_METADATA
 };
 
 /**
@@ -815,6 +822,17 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
 #endif
 
 /**
+ * RTE_FLOW_ITEM_TYPE_METADATA
+ *
+ * Allow arbitrary pipeline metadata to be used in specification flow pattern
+ */
+struct rte_flow_item_metadata {
+	uint32_t id;		/**< field identifier */
+	uint32_t size;		/**< field size */
+	uint8_t *bytes;		/**< field value */
+};
+
+/**
  * Matching pattern item definition.
  *
  * A pattern is formed by stacking items starting from the lowest protocol
@@ -1266,6 +1284,30 @@ struct rte_flow_action_group {
 };
 
 /**
+ * RTE_FLOW_ACTION_TYPE_METADATA
+ *
+ * Action extracts data from packet into specified metadata field in pipeline
+ * for use in downstream processing stages or for propagation to host interface.
+ *
+ * Pattern mask is use to define the extraction data for packet. The mask
+ * pattern types defined in the action metadata pattern must match the flow
+ * pattern definitions up to the last item from which data is to be extracted.
+ *
+ * Non-terminating by default.
+ */
+struct rte_flow_action_metadata {
+	uint32_t id;		/**< field identifier */
+
+	struct rte_flow_action_mask_item {
+		enum rte_flow_item_type type;
+		/**< Flow item type. */
+		const void *mask;
+		/**< Flow item mask. */
+	} *pattern;
+	/** metadata extraction pattern mask specification */
+};
+
+/**
  * Definition of a single action.
  *
  * A list of actions is terminated by a END action.
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support

[Adrien Mazarguil]

On Fri, Apr 06, 2018 at 01:24:03PM +0100, Declan Doherty wrote:
> Introduces a new action type RTE_FLOW_ACTION_TYPE_METADATA which enables
> metadata extraction from a packet into a specified metadata container
> for consumption on further pipeline stages or for propagation to the host
> interface.
> 
> As complementary function to the new metadata action type this patch also
> introduces a new flow item type which enables flow patterns to specify a
> specific metadata container as a matching criteria for a flow rule.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

Is there already HW support for extraction and subsequent matching?

Otherwise it looks overkill. If it's meant to be implemented in software by
PMDs, isn't the existing MARK action with arbitrary value good enough?
All it needs is a corresponding MARK pattern item (which reminds me I forgot
to add it...)

My suggestion would be to submit this new item/action combo at the same
time as the first actual PMD implementation. In the meantime I think a much
simpler MARK pattern item could satisfy the most pressing needs.

> ---
>  doc/guides/prog_guide/rte_flow.rst | 85 ++++++++++++++++++++++++++++++++++++++
>  lib/librte_ether/rte_flow.h        | 42 +++++++++++++++++++
>  2 files changed, 127 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 2f0a47a..9b2b0e3 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1580,6 +1580,91 @@ group on that device.
>     +--------------+---------------------------------+
>  
>  
> +

You keep adding these empty lines :)

> +Action: ``METADATA``
> +^^^^^^^^^^^^^^^^^^^^
> +
> +Action extracts data from packet into user specified metadata field in pipeline
> +for use in downstream processing stages or for propagation to host interface.
> +
> +The pattern mask is used to define the data which is to be extracted from the
> +packet. The mask pattern types defined in the action metadata pattern must
> +match the flow pattern definitions up to the last flow item from which data is
> +to be extracted.
> +
> +- Non-terminating by default.

Usual comment [1] regarding this property.

[1] "ethdev: alter behavior of flow API actions"
    http://dpdk.org/ml/archives/dev/2018-April/095779.html

> +
> +.. _table_rte_flow_action_metadata:
> +
> +.. table:: METADATA
> +
> +   +--------------+---------------------------+
> +   | Field        | Value                     |
> +   +==============+===========================+
> +   | ``id``       | Metadata field Identifier |
> +   +--------------+---------------------------+
> +   | ``pattern``  | Extraction mask pattern   |
> +   +--------------+---------------------------+
> +
> +The example below demonstrates how the extraction mask to extract the source/
> +destination IPv4 address, the UDP destination port and and the VxLAN VNI can be
> +specified.
> +
> +.. _table_rte_flow_action_metadata_example:
> +
> +.. table:: IPv4 VxLAN metadata extraction
> +
> +   +-------+--------------------------+-----------------------------------+
> +   | Index | Flow Item Type           | Flow Mask                         |
> +   +=======+==========================+===================================+
> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .type = RTE_BE16(0x0)             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0xffffffff)  |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_addr = RTE_BE32(0xffffffff)  |
> +   +-------+--------------------------+-----------------------------------+
> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_port = RTE_BE16(0xffff)      |
> +   +-------+--------------------------+-----------------------------------+
> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
> +   +-------+--------------------------+-----------------------------------+
> +
> +If only the VxLAN VNI extraction was required then the extraction mask would be
> +as follows.

VxLAN => VXLAN

> +
> +.. _table_rte_flow_action_metadata_example_2:
> +
> +.. table::  VxLAN VNI metadata extraction
> +
> +   +-------+--------------------------+-----------------------------------+
> +   | Index | Flow Item Type           | Flow Mask                         |
> +   +=======+==========================+===================================+
> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .type = RTE_BE16(0x0)             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_addr = RTE_BE32(0x0)         |
> +   +-------+--------------------------+-----------------------------------+
> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_port = RTE_BE16(0x0)         |
> +   +-------+--------------------------+-----------------------------------+
> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
> +   +-------+--------------------------+-----------------------------------+
> +
>  Negative types
>  ~~~~~~~~~~~~~~
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 968a23b..f75dee7 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -323,6 +323,13 @@ enum rte_flow_item_type {
>  	 * See struct rte_flow_item_geneve.
>  	 */
>  	RTE_FLOW_ITEM_TYPE_GENEVE,
> +
> +	/**
> +	 * Matches specified pipeline metadata field.
> +	 *
> +	 * See struct rte_flow_item_metadata.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_METADATA

Please add the trailing comma to ease subsequent contributions.

>  };
>  
>  /**
> @@ -815,6 +822,17 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
>  #endif
>  
>  /**
> + * RTE_FLOW_ITEM_TYPE_METADATA
> + *
> + * Allow arbitrary pipeline metadata to be used in specification flow pattern
> + */
> +struct rte_flow_item_metadata {
> +	uint32_t id;		/**< field identifier */
> +	uint32_t size;		/**< field size */
> +	uint8_t *bytes;		/**< field value */
> +};

One last nit regarding this definition (assuming we keep it), please remove
extra spacing before comments (no alignment) and add caps to format it like
the rest of that file.

> +
> +/**
>   * Matching pattern item definition.
>   *
>   * A pattern is formed by stacking items starting from the lowest protocol
> @@ -1266,6 +1284,30 @@ struct rte_flow_action_group {
>  };
>  
>  /**
> + * RTE_FLOW_ACTION_TYPE_METADATA

Definition in enum rte_flow_action_type should be part of this commit.

> + *
> + * Action extracts data from packet into specified metadata field in pipeline
> + * for use in downstream processing stages or for propagation to host interface.
> + *
> + * Pattern mask is use to define the extraction data for packet. The mask
> + * pattern types defined in the action metadata pattern must match the flow
> + * pattern definitions up to the last item from which data is to be extracted.
> + *
> + * Non-terminating by default.
> + */
> +struct rte_flow_action_metadata {
> +	uint32_t id;		/**< field identifier */
> +
> +	struct rte_flow_action_mask_item {
> +		enum rte_flow_item_type type;
> +		/**< Flow item type. */
> +		const void *mask;
> +		/**< Flow item mask. */
> +	} *pattern;
> +	/** metadata extraction pattern mask specification */
> +};

Same comment as in prior commit regarding this structure. You should use
struct rte_flow_item directly, except this time a pointer to a pattern
with multiple items seems warranted.

> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> -- 
> 2.7.4
> 

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support

[Doherty, Declan]

On 06/04/2018 9:27 PM, Adrien Mazarguil wrote:
> On Fri, Apr 06, 2018 at 01:24:03PM +0100, Declan Doherty wrote:
>> Introduces a new action type RTE_FLOW_ACTION_TYPE_METADATA which enables
>> metadata extraction from a packet into a specified metadata container
>> for consumption on further pipeline stages or for propagation to the host
>> interface.
>>
>> As complementary function to the new metadata action type this patch also
>> introduces a new flow item type which enables flow patterns to specify a
>> specific metadata container as a matching criteria for a flow rule.
>>
>> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> 
> Is there already HW support for extraction and subsequent matching?
> > Otherwise it looks overkill. If it's meant to be implemented in 
software by
> PMDs, isn't the existing MARK action with arbitrary value good enough?
> All it needs is a corresponding MARK pattern item (which reminds me I forgot
> to add it...)
> 
> My suggestion would be to submit this new item/action combo at the same
> time as the first actual PMD implementation. In the meantime I think a much
> simpler MARK pattern item could satisfy the most pressing needs.
>

I admit this was a bit future looking :) and probably overkill for what 
is needed today. I'll add the suggested MARK pattern item which will be 
enough to handle the OVS-DPDK tunnel encap/decap requirements.

>> ---
>>   doc/guides/prog_guide/rte_flow.rst | 85 ++++++++++++++++++++++++++++++++++++++
>>   lib/librte_ether/rte_flow.h        | 42 +++++++++++++++++++
>>   2 files changed, 127 insertions(+)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index 2f0a47a..9b2b0e3 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -1580,6 +1580,91 @@ group on that device.
>>      +--------------+---------------------------------+
>>   
>>   
>> +
> 
> You keep adding these empty lines :)

sorry.... what can I say I love whitespace :D

> 
>> +Action: ``METADATA``
>> +^^^^^^^^^^^^^^^^^^^^
>> +
>> +Action extracts data from packet into user specified metadata field in pipeline
>> +for use in downstream processing stages or for propagation to host interface.
>> +
>> +The pattern mask is used to define the data which is to be extracted from the
>> +packet. The mask pattern types defined in the action metadata pattern must
>> +match the flow pattern definitions up to the last flow item from which data is
>> +to be extracted.
>> +
>> +- Non-terminating by default.
> 
> Usual comment [1] regarding this property.
> 
> [1] "ethdev: alter behavior of flow API actions"
>      http://dpdk.org/ml/archives/dev/2018-April/095779.html
> 
>> +
>> +.. _table_rte_flow_action_metadata:
>> +
>> +.. table:: METADATA
>> +
>> +   +--------------+---------------------------+
>> +   | Field        | Value                     |
>> +   +==============+===========================+
>> +   | ``id``       | Metadata field Identifier |
>> +   +--------------+---------------------------+
>> +   | ``pattern``  | Extraction mask pattern   |
>> +   +--------------+---------------------------+
>> +
>> +The example below demonstrates how the extraction mask to extract the source/
>> +destination IPv4 address, the UDP destination port and and the VxLAN VNI can be
>> +specified.
>> +
>> +.. _table_rte_flow_action_metadata_example:
>> +
>> +.. table:: IPv4 VxLAN metadata extraction
>> +
>> +   +-------+--------------------------+-----------------------------------+
>> +   | Index | Flow Item Type           | Flow Mask                         |
>> +   +=======+==========================+===================================+
>> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .type = RTE_BE16(0x0)             |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0xffffffff)  |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .dst_addr = RTE_BE32(0xffffffff)  |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .dst_port = RTE_BE16(0xffff)      |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
>> +   +-------+--------------------------+-----------------------------------+
>> +
>> +If only the VxLAN VNI extraction was required then the extraction mask would be
>> +as follows.
> 
> VxLAN => VXLAN
> 
>> +
>> +.. _table_rte_flow_action_metadata_example_2:
>> +
>> +.. table::  VxLAN VNI metadata extraction
>> +
>> +   +-------+--------------------------+-----------------------------------+
>> +   | Index | Flow Item Type           | Flow Mask                         |
>> +   +=======+==========================+===================================+
>> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .type = RTE_BE16(0x0)             |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0x0)         |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .dst_addr = RTE_BE32(0x0)         |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
>> +   |       |                          +-----------------------------------+
>> +   |       |                          | .dst_port = RTE_BE16(0x0)         |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
>> +   +-------+--------------------------+-----------------------------------+
>> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
>> +   +-------+--------------------------+-----------------------------------+
>> +
>>   Negative types
>>   ~~~~~~~~~~~~~~
>>   
>> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
>> index 968a23b..f75dee7 100644
>> --- a/lib/librte_ether/rte_flow.h
>> +++ b/lib/librte_ether/rte_flow.h
>> @@ -323,6 +323,13 @@ enum rte_flow_item_type {
>>   	 * See struct rte_flow_item_geneve.
>>   	 */
>>   	RTE_FLOW_ITEM_TYPE_GENEVE,
>> +
>> +	/**
>> +	 * Matches specified pipeline metadata field.
>> +	 *
>> +	 * See struct rte_flow_item_metadata.
>> +	 */
>> +	RTE_FLOW_ITEM_TYPE_METADATA
> 
> Please add the trailing comma to ease subsequent contributions.
> 
>>   };
>>   
>>   /**
>> @@ -815,6 +822,17 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
>>   #endif
>>   
>>   /**
>> + * RTE_FLOW_ITEM_TYPE_METADATA
>> + *
>> + * Allow arbitrary pipeline metadata to be used in specification flow pattern
>> + */
>> +struct rte_flow_item_metadata {
>> +	uint32_t id;		/**< field identifier */
>> +	uint32_t size;		/**< field size */
>> +	uint8_t *bytes;		/**< field value */
>> +};
> 
> One last nit regarding this definition (assuming we keep it), please remove
> extra spacing before comments (no alignment) and add caps to format it like
> the rest of that file.
> 
>> +
>> +/**
>>    * Matching pattern item definition.
>>    *
>>    * A pattern is formed by stacking items starting from the lowest protocol
>> @@ -1266,6 +1284,30 @@ struct rte_flow_action_group {
>>   };
>>   
>>   /**
>> + * RTE_FLOW_ACTION_TYPE_METADATA
> 
> Definition in enum rte_flow_action_type should be part of this commit.
> 
>> + *
>> + * Action extracts data from packet into specified metadata field in pipeline
>> + * for use in downstream processing stages or for propagation to host interface.
>> + *
>> + * Pattern mask is use to define the extraction data for packet. The mask
>> + * pattern types defined in the action metadata pattern must match the flow
>> + * pattern definitions up to the last item from which data is to be extracted.
>> + *
>> + * Non-terminating by default.
>> + */
>> +struct rte_flow_action_metadata {
>> +	uint32_t id;		/**< field identifier */
>> +
>> +	struct rte_flow_action_mask_item {
>> +		enum rte_flow_item_type type;
>> +		/**< Flow item type. */
>> +		const void *mask;
>> +		/**< Flow item mask. */
>> +	} *pattern;
>> +	/** metadata extraction pattern mask specification */
>> +};
> 
> Same comment as in prior commit regarding this structure. You should use
> struct rte_flow_item directly, except this time a pointer to a pattern
> with multiple items seems warranted.
> 
>> +
>> +/**
>>    * Definition of a single action.
>>    *
>>    * A list of actions is terminated by a END action.
>> -- 
>> 2.7.4
>>
> 

Re: [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support

[Xueming(Steven) Li]

Hi Declan,

Is there a mapping between maetadata and mbuf field(s), or the lifecycle of metadata supposed to 
be in middle of flows?

There might be another use case that set metadata to a constant, is this covered?

Thanks,
Xueming

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Declan Doherty
> Sent: Friday, April 6, 2018 8:24 PM
> To: dev@dpdk.org
> Cc: Declan Doherty <declan.doherty@intel.com>
> Subject: [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support
> 
> Introduces a new action type RTE_FLOW_ACTION_TYPE_METADATA which enables metadata extraction from a
> packet into a specified metadata container for consumption on further pipeline stages or for
> propagation to the host interface.
> 
> As complementary function to the new metadata action type this patch also introduces a new flow item
> type which enables flow patterns to specify a specific metadata container as a matching criteria for a
> flow rule.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 85 ++++++++++++++++++++++++++++++++++++++
>  lib/librte_ether/rte_flow.h        | 42 +++++++++++++++++++
>  2 files changed, 127 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 2f0a47a..9b2b0e3 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1580,6 +1580,91 @@ group on that device.
>     +--------------+---------------------------------+
> 
> 
> +
> +Action: ``METADATA``
> +^^^^^^^^^^^^^^^^^^^^
> +
> +Action extracts data from packet into user specified metadata field in
> +pipeline for use in downstream processing stages or for propagation to host interface.
> +
> +The pattern mask is used to define the data which is to be extracted
> +from the packet. The mask pattern types defined in the action metadata
> +pattern must match the flow pattern definitions up to the last flow
> +item from which data is to be extracted.
> +
> +- Non-terminating by default.
> +
> +.. _table_rte_flow_action_metadata:
> +
> +.. table:: METADATA
> +
> +   +--------------+---------------------------+
> +   | Field        | Value                     |
> +   +==============+===========================+
> +   | ``id``       | Metadata field Identifier |
> +   +--------------+---------------------------+
> +   | ``pattern``  | Extraction mask pattern   |
> +   +--------------+---------------------------+
> +
> +The example below demonstrates how the extraction mask to extract the
> +source/ destination IPv4 address, the UDP destination port and and the
> +VxLAN VNI can be specified.
> +
> +.. _table_rte_flow_action_metadata_example:
> +
> +.. table:: IPv4 VxLAN metadata extraction
> +
> +   +-------+--------------------------+-----------------------------------+
> +   | Index | Flow Item Type           | Flow Mask                         |
> +   +=======+==========================+===================================+
> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .type = RTE_BE16(0x0)             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0xffffffff)  |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_addr = RTE_BE32(0xffffffff)  |
> +   +-------+--------------------------+-----------------------------------+
> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_port = RTE_BE16(0xffff)      |
> +   +-------+--------------------------+-----------------------------------+
> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
> +
> + +-------+--------------------------+----------------------------------
> + -+
> +
> +If only the VxLAN VNI extraction was required then the extraction mask
> +would be as follows.
> +
> +.. _table_rte_flow_action_metadata_example_2:
> +
> +.. table::  VxLAN VNI metadata extraction
> +
> +   +-------+--------------------------+-----------------------------------+
> +   | Index | Flow Item Type           | Flow Mask                         |
> +   +=======+==========================+===================================+
> +   | 0     | RTE_FLOW_ITEM_TYPE_ETH   | .dst = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .src = "\x00\x00\x00\x00\x00\x00" |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .type = RTE_BE16(0x0)             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 1     | RTE_FLOW_ITEM_TYPE_IPV4  | .src_addr = RTE_BE32(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_addr = RTE_BE32(0x0)         |
> +   +-------+--------------------------+-----------------------------------+
> +   | 2     | RTE_FLOW_ITEM_TYPE_UDP   | .src_port = RTE_BE16(0x0)         |
> +   |       |                          +-----------------------------------+
> +   |       |                          | .dst_port = RTE_BE16(0x0)         |
> +   +-------+--------------------------+-----------------------------------+
> +   | 3     | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff"             |
> +   +-------+--------------------------+-----------------------------------+
> +   | 4     | RTE_FLOW_ITEM_TYPE_END   | NULL                              |
> +
> + +-------+--------------------------+----------------------------------
> + -+
> +
>  Negative types
>  ~~~~~~~~~~~~~~
> 
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h index 968a23b..f75dee7 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -323,6 +323,13 @@ enum rte_flow_item_type {
>  	 * See struct rte_flow_item_geneve.
>  	 */
>  	RTE_FLOW_ITEM_TYPE_GENEVE,
> +
> +	/**
> +	 * Matches specified pipeline metadata field.
> +	 *
> +	 * See struct rte_flow_item_metadata.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_METADATA
>  };
> 
>  /**
> @@ -815,6 +822,17 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {  #endif
> 
>  /**
> + * RTE_FLOW_ITEM_TYPE_METADATA
> + *
> + * Allow arbitrary pipeline metadata to be used in specification flow
> +pattern  */ struct rte_flow_item_metadata {
> +	uint32_t id;		/**< field identifier */
> +	uint32_t size;		/**< field size */
> +	uint8_t *bytes;		/**< field value */
> +};
> +
> +/**
>   * Matching pattern item definition.
>   *
>   * A pattern is formed by stacking items starting from the lowest protocol @@ -1266,6 +1284,30 @@
> struct rte_flow_action_group {  };
> 
>  /**
> + * RTE_FLOW_ACTION_TYPE_METADATA
> + *
> + * Action extracts data from packet into specified metadata field in
> +pipeline
> + * for use in downstream processing stages or for propagation to host interface.
> + *
> + * Pattern mask is use to define the extraction data for packet. The
> +mask
> + * pattern types defined in the action metadata pattern must match the
> +flow
> + * pattern definitions up to the last item from which data is to be extracted.
> + *
> + * Non-terminating by default.
> + */
> +struct rte_flow_action_metadata {
> +	uint32_t id;		/**< field identifier */
> +
> +	struct rte_flow_action_mask_item {
> +		enum rte_flow_item_type type;
> +		/**< Flow item type. */
> +		const void *mask;
> +		/**< Flow item mask. */
> +	} *pattern;
> +	/** metadata extraction pattern mask specification */ };
> +
> +/**
>   * Definition of a single action.
>   *
>   * A list of actions is terminated by a END action.
> --
> 2.7.4

[dpdk-dev] [PATCH v4 0/6] additions to support tunnel encap/decap

[Declan Doherty]

This patchset contains the revised proposal to manage virtual
tunnel endpoints hardware accleration based on community
feedback on RFC

(http://dpdk.org/ml/archives/dev/2017-December/084676.html). This

proposal is purely enabled through rte_flow APIs with the
additions of some new features which were previously implemented
by the proposed rte_tep APIs which were proposed in the original
RFC. This patchset ultimately aims to enable the configuration
of inline data path encapsulation and decapsulation of tunnel
endpoint network overlays on accelerated IO devices.

V2:

Split new functions into separate patches, and add additional
documentaiton.

V3:

Extended the description of group counter in documentation.
Renamed VTEP to TUNNEL.
Fixed C99 syntax.

V4:
- Modify encap/decap actions to be protocol specific
- rename group action type to jump
- add mark flow item type in place of metadata flow/action types
- add count action data structure
- modify query API to accept rte_flow_action structure in place of
  rte_flow_actio_type enumeration to support specification and
  querying of multiple actions of the same type


The summary of the additions to the rte_flow are as follows:

- Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP and
RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP to rte_flow to support specfication
of encapsulation and decapsulation of virtual Tunnel Endpoint on
hardware.

- Updates the matching pattern item definition
description to specify that all actions which modify a packet
must be specified in the explicit order they are to be excuted.

- Introduces support for the use of pipeline metadata in
the flow pattern definition and the population of metadata fields
from flow actions.

- Adds group counters to enable statistics to be kept on groups of
flows such as all ingress/egress flows of a tunnel

- Adds group_action to allow a flow termination to be a group/table
within the device.

A high level summary of the proposed usage model is as follows:

1. Decapsulation

1.1. Decapsulation of tunnel outer headers and forward all traffic
     to the same queue/s or port, would have the follow flows
     paramteters, sudo code used here.


struct rte_flow_attr attr = { .ingress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, .type = VxLAN },
	{ .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action  },
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

1.2.

Decapsulation of tunnel outer headers and matching on inner
headers, and forwarding to the same queue/s or port.


1.2.1.

The same scenario as above but either the application
or hardware requires configuration as 2 logically independent
operations (viewing it as 2 logical tables). The first stage
being the flow rule to define the pattern to match the tunnel
and the action to decapsulate the packet, and the second stage
stage table matches the inner header and defines the actions,
forward to port etc.

flow rule for outer header on table 0

struct rte_flow_attr attr = { .ingress = 1, .table = 0 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_item_count shared_couter = {
	.shared = 1,
	.id = {}
}

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &shared_counter },
	{ .type = RTE_FLOW_ACTION_TYPE_MARK, .conf = &mark_action },
	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP },
	{
	  .type = RTE_FLOW_ACTION_TYPE_JUMP,
	  .conf = { .group = 1 }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

flow rule for inner header on table 1

struct rte_flow_attr attr = { .ingress = 1, .table = 1 };

struct rte_flow_item_mark mark_item = { id = X };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_MARK,  .spec = &mark_item },
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};



struct rte_flow_action actions[] = {
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

Note that the metadata action in the flow rule in table 0 is generating
the metadata in the pipeline which is then used in as part as the flow
pattern in table 1 to specify the exact flow to match against. In the
case where exact match rules are being provided by the application
then this metadata could be extracted by the PMD from the flow pattern
for the group 0 rule, the matching metadata will then need to be
explicitly provided by the application in the flow pattern for the flow
rule in group 1. For devices capable of wildcard matching then the hardware
must be capable of extracting the data from the packet as specified by the
mask in the flow action rule in group 0.

2. Encapsulation

Encapsulation of all traffic matching a specific flow pattern to a
specified tunnel and egressing to a particular port.

struct rte_flow_attr attr = { .egress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action_tunnel_encap vxlan_encap_action = {
	.definition = {
		{ .type=eth, .spec={}, .mask={} },
		{ .type=ipv4, .spec={}, .mask={} },
		{ .type=udp, .spec={}, .mask={} },
		{ .type=vxlan, .spec={}, .mask={} }
		{ .type=end }
	}
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &count } },
	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, .conf = &vxlan_encap_action } },
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
};

Declan Doherty (6):
  ethdev: Add tunnel encap/decap actions
  ethdev: Add group action type to rte_flow
  testpmd: add jump action
  ethdev: add mark flow item to rte_flow_item_types
  testpmd: add support for MARK flow item
  ethdev: add shared counter support to rte_flow

 app/test-pmd/cmdline_flow.c                 |  51 +++++++-
 app/test-pmd/config.c                       |  15 ++-
 app/test-pmd/testpmd.h                      |   2 +-
 doc/guides/prog_guide/rte_flow.rst          | 191 +++++++++++++++++++++++++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   8 ++
 drivers/net/failsafe/failsafe_flow.c        |   4 +-
 lib/librte_ether/rte_flow.c                 |   2 +-
 lib/librte_ether/rte_flow.h                 | 148 ++++++++++++++++++++-
 lib/librte_ether/rte_flow_driver.h          |   2 +-
 9 files changed, 384 insertions(+), 39 deletions(-)

-- 
2.14.3

[dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions

[Declan Doherty]

Add new flow action types and associated action data structure to
support the encapsulation and decapsulation of VXLAN/NVGRE tunnel
endpoints.

The RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP or
RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP actions will cause the matching
flow to be encapsulated in the tunnel endpoint overlay
defined in the rte_flow_action_tunnel_encap action definition.

The RTE_FLOW_ACTION_TYPE_VXLAN_DECAP and
RTE_FLOW_ACTION_TYPE_NVGRE_DECAP actions will cause all headers
associated with the outermost VXLAN/NVGRE tunnel overlay to be
decapsulated from the matching flow.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 89 ++++++++++++++++++++++++++++++++++++++
 lib/librte_ether/rte_flow.h        | 67 +++++++++++++++++++++++++++-
 2 files changed, 155 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 961943dda..672473d33 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1486,6 +1486,95 @@ fields in the pattern items.
    | 1     | END      |
    +-------+----------+
 
+Action: ``VXLAN_ENCAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a VXLAN encapsulation action by encapsulating the matched flow in the
+VXLAN tunnel as defined in the``rte_flow_action_tunnel_encap`` flow items
+definition.
+
+This action modifies the payload of matched flows. The flow definition specified
+in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
+VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible Local Area
+Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over
+Layer 3 Networks). The pattern must be terminated with
+the RTE_FLOW_ITEM_TYPE_END item type.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_tunnel_encap:
+
+.. table:: TUNNEL_ENCAP
+
+   +----------------+-------------------------------------+
+   | Field          | Value                               |
+   +================+=====================================+
+   | ``definition`` | Tunnel end-point overlay definition |
+   +----------------+-------------------------------------+
+
+.. _table_rte_flow_action_tunnel_encap_example:
+
+.. table:: IPv4 VxLAN flow pattern example.
+
+   +-------+----------+
+   | Index | Item     |
+   +=======+==========+
+   | 0     | Ethernet |
+   +-------+----------+
+   | 1     | IPv4     |
+   +-------+----------+
+   | 2     | UDP      |
+   +-------+----------+
+   | 3     | VXLAN    |
+   +-------+----------+
+   | 4     | END      |
+   +-------+----------+
+
+Action: ``VXLAN_DECAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a decapsulation action by stripping all headers of the VXLAN tunnel
+network overlay from the matched flow.
+
+This action modifies the payload of matched flows.
+
+Action: ``NVGRE_ENCAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a NVGRE encapsulation action by encapsulating the matched flow in the
+NVGRE tunnel as defined in the``rte_flow_action_tunnel_encap`` flow item
+definition.
+
+This action modifies the payload of matched flows. The flow definition specified
+in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
+NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network Virtualization
+Using Generic Routing Encapsulation). The pattern must be terminated with
+the RTE_FLOW_ITEM_TYPE_END item type.
+
+.. _table_rte_flow_action_tunnel_encap_example:
+
+.. table:: IPv4 NVGRE flow pattern example.
+
+   +-------+----------+
+   | Index | Item     |
+   +=======+==========+
+   | 0     | Ethernet |
+   +-------+----------+
+   | 1     | IPv4     |
+   +-------+----------+
+   | 2     | NVGRE    |
+   +-------+----------+
+   | 3     | END      |
+   +-------+----------+
+
+Action: ``NVGRE_DECAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a decapsulation action by stripping all headers of the NVGRE tunnel
+network overlay from the matched flow.
+
+This action modifies the payload of matched flows.
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 56c733451..537e1bfba 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1010,7 +1010,35 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_security.
 	 */
-	RTE_FLOW_ACTION_TYPE_SECURITY
+	RTE_FLOW_ACTION_TYPE_SECURITY,
+
+	/**
+	 * Encapsulate flow in VXLAN tunnel as defined in RFC7348
+	 * using headers defined in rte_flow_action_tunnel_encap
+	 * structure.
+	 *
+	 * See struct rte_flow_action_tunnel_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP,
+
+	/**
+	 * Decapsulate outer most VXLAN tunnel headers from flow
+	 */
+	RTE_FLOW_ACTION_TYPE_VXLAN_DECAP,
+
+	/**
+	 * Encapsulate flow in NVGRE tunnel as defined in RFC7637
+	 * using header defined in the rte_flow_action_tunnel_encap
+	 * structure.
+	 *
+	 * See struct rte_flow_action_tunnel_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP,
+
+	/**
+	 * Decapsulate outer most NVGRE tunnel headers from flow
+	 */
+	RTE_FLOW_ACTION_TYPE_NVGRE_DECAP
 };
 
 /**
@@ -1148,6 +1176,43 @@ struct rte_flow_action_security {
 	void *security_session; /**< Pointer to security session structure. */
 };
 
+/**
+ * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
+ *
+ * Tunnel end-point encapsulation data definition
+ *
+ * The tunnel definition is provided through the flow item pattern pattern, the
+ * provided pattern must conform with the corresponding RFC for the
+ * tunnel encapsulation action specified by the action type. The flow
+ * definition must be provided in order from the RTE_FLOW_ITEM_TYPE_ETH
+ * definition up the end item which is specified by RTE_FLOW_ITEM_TYPE_END.
+ *
+ * The mask field allows user to specify which fields in the flow item
+ * definitions can be ignored and which have valid data and can be used
+ * verbatim.
+ *
+ * Note: the last field is not used in the definition of a tunnel and can be
+ * ignored.
+ *
+ * For example if the actions type was RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP
+ * then valid patterns would include:
+ *
+ * - ETH / IPV4 / UDP / VXLAN / END
+ * - ETH / VLAN / IPV4 / UDP / VXLAN / END
+ *
+ * some valid examples for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include:
+ *
+ * - ETH / IPV4 / NVGRE / END
+ * - ETH / VLAN / IPV4 / NVGRE / END
+ */
+struct rte_flow_action_tunnel_encap {
+	struct rte_flow_item *definition;
+	/**<
+	 * Encapsulating tunnel definition
+	 * (list terminated by the END pattern item).
+	 */
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:18PM +0100, Declan Doherty wrote:
> Add new flow action types and associated action data structure to
> support the encapsulation and decapsulation of VXLAN/NVGRE tunnel
> endpoints.
> 
> The RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP or
> RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP actions will cause the matching
> flow to be encapsulated in the tunnel endpoint overlay
> defined in the rte_flow_action_tunnel_encap action definition.
> 
> The RTE_FLOW_ACTION_TYPE_VXLAN_DECAP and
> RTE_FLOW_ACTION_TYPE_NVGRE_DECAP actions will cause all headers
> associated with the outermost VXLAN/NVGRE tunnel overlay to be
> decapsulated from the matching flow.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

So far so good, more comments below.

> ---
>  doc/guides/prog_guide/rte_flow.rst | 89 ++++++++++++++++++++++++++++++++++++++
>  lib/librte_ether/rte_flow.h        | 67 +++++++++++++++++++++++++++-
>  2 files changed, 155 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 961943dda..672473d33 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1486,6 +1486,95 @@ fields in the pattern items.
>     | 1     | END      |
>     +-------+----------+
>  
> +Action: ``VXLAN_ENCAP``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs a VXLAN encapsulation action by encapsulating the matched flow in the
> +VXLAN tunnel as defined in the``rte_flow_action_tunnel_encap`` flow items
> +definition.

Missing space before ``rte_flow_action_tunnel_encap``. However please define
a dedicated rte_flow_action_vxlan_encap and another for nvgre instead, even
if their contents are identical, in order to keep them synchronized with
their type name. There's not much overhead involved and it helps clarifying
the API.

> +
> +This action modifies the payload of matched flows. The flow definition specified
> +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid

defined => define

> +VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible Local Area
> +Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over
> +Layer 3 Networks). The pattern must be terminated with
> +the RTE_FLOW_ITEM_TYPE_END item type.
> +
> +- Non-terminating by default.
> +
> +.. _table_rte_flow_action_tunnel_encap:
> +
> +.. table:: TUNNEL_ENCAP
> +
> +   +----------------+-------------------------------------+
> +   | Field          | Value                               |
> +   +================+=====================================+
> +   | ``definition`` | Tunnel end-point overlay definition |
> +   +----------------+-------------------------------------+
> +
> +.. _table_rte_flow_action_tunnel_encap_example:
> +
> +.. table:: IPv4 VxLAN flow pattern example.
> +
> +   +-------+----------+
> +   | Index | Item     |
> +   +=======+==========+
> +   | 0     | Ethernet |
> +   +-------+----------+
> +   | 1     | IPv4     |
> +   +-------+----------+
> +   | 2     | UDP      |
> +   +-------+----------+
> +   | 3     | VXLAN    |
> +   +-------+----------+
> +   | 4     | END      |
> +   +-------+----------+
> +
> +Action: ``VXLAN_DECAP``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs a decapsulation action by stripping all headers of the VXLAN tunnel
> +network overlay from the matched flow.
> +
> +This action modifies the payload of matched flows.

You should document "undefined behavior" when this action faces traffic
which does not contain a recognized VXLAN header.

> +
> +Action: ``NVGRE_ENCAP``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs a NVGRE encapsulation action by encapsulating the matched flow in the
> +NVGRE tunnel as defined in the``rte_flow_action_tunnel_encap`` flow item
> +definition.
> +
> +This action modifies the payload of matched flows. The flow definition specified
> +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
> +NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network Virtualization
> +Using Generic Routing Encapsulation). The pattern must be terminated with
> +the RTE_FLOW_ITEM_TYPE_END item type.

Same comment as for VXLAN.

> +
> +.. _table_rte_flow_action_tunnel_encap_example:
> +
> +.. table:: IPv4 NVGRE flow pattern example.
> +
> +   +-------+----------+
> +   | Index | Item     |
> +   +=======+==========+
> +   | 0     | Ethernet |
> +   +-------+----------+
> +   | 1     | IPv4     |
> +   +-------+----------+
> +   | 2     | NVGRE    |
> +   +-------+----------+
> +   | 3     | END      |
> +   +-------+----------+
> +
> +Action: ``NVGRE_DECAP``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Performs a decapsulation action by stripping all headers of the NVGRE tunnel
> +network overlay from the matched flow.
> +
> +This action modifies the payload of matched flows.
> +

Ditto.

>  Negative types
>  ~~~~~~~~~~~~~~
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 56c733451..537e1bfba 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -1010,7 +1010,35 @@ enum rte_flow_action_type {
>  	 *
>  	 * See struct rte_flow_action_security.
>  	 */
> -	RTE_FLOW_ACTION_TYPE_SECURITY
> +	RTE_FLOW_ACTION_TYPE_SECURITY,
> +
> +	/**
> +	 * Encapsulate flow in VXLAN tunnel as defined in RFC7348
> +	 * using headers defined in rte_flow_action_tunnel_encap
> +	 * structure.
> +	 *
> +	 * See struct rte_flow_action_tunnel_encap.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP,
> +
> +	/**
> +	 * Decapsulate outer most VXLAN tunnel headers from flow
> +	 */
> +	RTE_FLOW_ACTION_TYPE_VXLAN_DECAP,
> +
> +	/**
> +	 * Encapsulate flow in NVGRE tunnel as defined in RFC7637
> +	 * using header defined in the rte_flow_action_tunnel_encap
> +	 * structure.
> +	 *
> +	 * See struct rte_flow_action_tunnel_encap.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP,
> +
> +	/**
> +	 * Decapsulate outer most NVGRE tunnel headers from flow
> +	 */
> +	RTE_FLOW_ACTION_TYPE_NVGRE_DECAP

Please add a trailing comma.

>  };
>  
>  /**
> @@ -1148,6 +1176,43 @@ struct rte_flow_action_security {
>  	void *security_session; /**< Pointer to security session structure. */
>  };
>  
> +/**
> + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
> + *
> + * Tunnel end-point encapsulation data definition
> + *
> + * The tunnel definition is provided through the flow item pattern pattern, the
> + * provided pattern must conform with the corresponding RFC for the
> + * tunnel encapsulation action specified by the action type. The flow
> + * definition must be provided in order from the RTE_FLOW_ITEM_TYPE_ETH
> + * definition up the end item which is specified by RTE_FLOW_ITEM_TYPE_END.
> + *
> + * The mask field allows user to specify which fields in the flow item
> + * definitions can be ignored and which have valid data and can be used
> + * verbatim.
> + *
> + * Note: the last field is not used in the definition of a tunnel and can be
> + * ignored.
> + *
> + * For example if the actions type was RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP
> + * then valid patterns would include:
> + *
> + * - ETH / IPV4 / UDP / VXLAN / END
> + * - ETH / VLAN / IPV4 / UDP / VXLAN / END
> + *
> + * some valid examples for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include:
> + *
> + * - ETH / IPV4 / NVGRE / END
> + * - ETH / VLAN / IPV4 / NVGRE / END
> + */

The above must be split between VXLAN and NVGRE, since they should come as
distinct structures. In any case, make sure Doxygen is synchronized with its
rte_flow.rst counterpart.

> +struct rte_flow_action_tunnel_encap {
> +	struct rte_flow_item *definition;
> +	/**<
> +	 * Encapsulating tunnel definition
> +	 * (list terminated by the END pattern item).
> +	 */

Please put this comment before the documented field by replacing the opening
"/**<" with "/**". End result is the same but I find it clearer and more
consistent that way ("/**<" is still fine for one-liners).

> +};
> +
>  /**
>   * Definition of a single action.
>   *
> -- 
> 2.14.3
> 

I'm still unsure about the definition involving a list of items. I imagined
these actions even less generic than that. How about tagging them
EXPERIMENTAL until sorted out through the first PMD implementation?

(We could even provide forward declarations only to prevent applications
from using them in the meantime.)

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions

[Shahaf Shuler]

Thursday, April 19, 2018 4:03 PM, Adrien Mazarguil:
> Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap
> actions
> 
> On Wed, Apr 18, 2018 at 10:04:18PM +0100, Declan Doherty wrote:

[...]

> 
> I'm still unsure about the definition involving a list of items. I imagined
> these actions even less generic than that. How about tagging them
> EXPERIMENTAL until sorted out through the first PMD implementation?

I think every new API should be marked as experimental. At least for one release. 
Here in specific, because there is no actual implementation of those APIs in any of the drivers. 

> 
> (We could even provide forward declarations only to prevent applications
> from using them in the meantime.)
> 
> --
> Adrien Mazarguil
> 6WIND

Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions

[Doherty, Declan]

On 23/04/2018 12:00 PM, Shahaf Shuler wrote:
> Thursday, April 19, 2018 4:03 PM, Adrien Mazarguil:
>> Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap
>> actions
>>
>> On Wed, Apr 18, 2018 at 10:04:18PM +0100, Declan Doherty wrote:
> 
> [...]
> 
>>
>> I'm still unsure about the definition involving a list of items. I imagined
>> these actions even less generic than that. How about tagging them
>> EXPERIMENTAL until sorted out through the first PMD implementation?
> 
> I think every new API should be marked as experimental. At least for one release.
> Here in specific, because there is no actual implementation of those APIs in any of the drivers.
> 

On this, since these are just new structures to use with existing APIs 
is using the following tag in the doxygen comments sufficient?

/**
  * @warning
  * @b EXPERIMENTAL: this structure may change without prior notice
  */

>>
>> (We could even provide forward declarations only to prevent applications
>> from using them in the meantime.)
>>
>> --
>> Adrien Mazarguil
>> 6WIND

Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions

[Adrien Mazarguil]

On Mon, Apr 23, 2018 at 12:17:09PM +0100, Doherty, Declan wrote:
> On 23/04/2018 12:00 PM, Shahaf Shuler wrote:
> > Thursday, April 19, 2018 4:03 PM, Adrien Mazarguil:
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap
> > > actions
> > > 
> > > On Wed, Apr 18, 2018 at 10:04:18PM +0100, Declan Doherty wrote:
> > 
> > [...]
> > 
> > > 
> > > I'm still unsure about the definition involving a list of items. I imagined
> > > these actions even less generic than that. How about tagging them
> > > EXPERIMENTAL until sorted out through the first PMD implementation?
> > 
> > I think every new API should be marked as experimental. At least for one release.
> > Here in specific, because there is no actual implementation of those APIs in any of the drivers.
> > 
> 
> On this, since these are just new structures to use with existing APIs is
> using the following tag in the doxygen comments sufficient?
> 
> /**
>  * @warning
>  * @b EXPERIMENTAL: this structure may change without prior notice
>  */

Looks good to me. I did not realize we already had such a thing in DPDK
(eventdev).

> > > (We could even provide forward declarations only to prevent applications
> > > from using them in the meantime.)

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v4 2/6] ethdev: Add jump action type to rte_flow

[Declan Doherty]

Add jump action type which defines an action which allows a matched
flow to be redirect to the specified group. This allows physical and
logical flow table/group hierarchies to be managed through rte_flow.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 26 ++++++++++++++++++++++++--
 lib/librte_ether/rte_flow.h        | 27 +++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 672473d33..325010544 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1188,6 +1188,28 @@ flow rules:
    | 2     | END                        |
    +-------+----------------------------+
 
+
+Action: ``JUMP``
+^^^^^^^^^^^^^^^^
+
+Redirects packets to a group on the current device.
+
+In a hierarchy of groups, which can be used to represent physical or logical
+flow group/tables on the device, this action allows the terminating action to
+be a group on that device.
+
+- Terminating by default.
+
+.. _table_rte_flow_action_jump:
+
+.. table:: JUMP
+
+   +-----------+---------------------------------+
+   | Field     | Value                           |
+   +===========+=================================+
+   | ``group`` | Group ID to redirect packets to |
+   +-----------+---------------------------------+
+
 Action: ``MARK``
 ^^^^^^^^^^^^^^^^
 
@@ -1512,7 +1534,7 @@ the RTE_FLOW_ITEM_TYPE_END item type.
    | ``definition`` | Tunnel end-point overlay definition |
    +----------------+-------------------------------------+
 
-.. _table_rte_flow_action_tunnel_encap_example:
+.. _table_rte_flow_action_tunnel_encap_vxlan_example:
 
 .. table:: IPv4 VxLAN flow pattern example.
 
@@ -1551,7 +1573,7 @@ NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network Virtualizatio
 Using Generic Routing Encapsulation). The pattern must be terminated with
 the RTE_FLOW_ITEM_TYPE_END item type.
 
-.. _table_rte_flow_action_tunnel_encap_example:
+.. _table_rte_flow_action_tunnel_encap_nvgre_example:
 
 .. table:: IPv4 NVGRE flow pattern example.
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 537e1bfba..91544f62b 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -913,6 +913,20 @@ enum rte_flow_action_type {
 	 */
 	RTE_FLOW_ACTION_TYPE_PASSTHRU,
 
+	/**
+	 * RTE_FLOW_ACTION_TYPE_JUMP
+	 *
+	 * Redirects packets to a group on the current device.
+	 *
+	 * In a hierarchy of groups, which can be used to represent
+	 * physical or logical flow groups/tables on a device, this
+	 * action allows the terminating action to be a group on
+	 * that device.
+	 *
+	 * See struct rte_flow_action_jump
+	 */
+	RTE_FLOW_ACTION_TYPE_JUMP,
+
 	/**
 	 * [META]
 	 *
@@ -1213,6 +1227,19 @@ struct rte_flow_action_tunnel_encap {
 	 */
 };
 
+/**
+ * RTE_FLOW_ACTION_TYPE_JUMP
+ *
+ * Redirects packets to a group on the current device.
+ *
+ * In a hierarchy of groups, which can be used to represent physical or logical
+ * flow tables on the device, this action allows the action to be a redirect to
+ * a group on that device.
+ */
+struct rte_flow_action_jump {
+	uint32_t group;
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 2/6] ethdev: Add jump action type to rte_flow

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:19PM +0100, Declan Doherty wrote:
> Add jump action type which defines an action which allows a matched
> flow to be redirect to the specified group. This allows physical and
> logical flow table/group hierarchies to be managed through rte_flow.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

You should have rebased this series including this patch on top of mine
([1] followed by [2]) to avoid some mistakes such as documenting
"terminating actions".

This patch could also update documentation for flow rules [3] groups [4] and
priorities [5] to make clear that groups aren't linked by default, their
order doesn't matter and explicit JUMP actions are needed to reach them
(actually look for every instance of the word "group" in this
documentation).

Also the addition of an action in the middle of the enum has an ABI impact,
please put a reminder in the commit log as in [6].

More below.

[1] "Bunch of flow API-related fixes"
    http://dpdk.org/ml/archives/dev/2018-April/098035.html
[2] "Flow API overhaul for switch offloads"
    http://dpdk.org/ml/archives/dev/2018-April/098047.html
[3] "9.2.1. Description"
     https://dpdk.org/doc/guides/prog_guide/rte_flow.html#description
[3] "9.2.2.1. Attribute: Group"
    https://dpdk.org/doc/guides/prog_guide/rte_flow.html#attribute-group
[5] "9.2.2.2. Attribute: Priority"
    https://dpdk.org/doc/guides/prog_guide/rte_flow.html#attribute-priority
[6] "ethdev: add physical port action to flow API"
    http://dpdk.org/ml/archives/dev/2018-April/098062.html

> ---
>  doc/guides/prog_guide/rte_flow.rst | 26 ++++++++++++++++++++++++--
>  lib/librte_ether/rte_flow.h        | 27 +++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 672473d33..325010544 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1188,6 +1188,28 @@ flow rules:
>     | 2     | END                        |
>     +-------+----------------------------+
>  
> +

Extraneous empty line.

> +Action: ``JUMP``
> +^^^^^^^^^^^^^^^^
> +
> +Redirects packets to a group on the current device.
> +
> +In a hierarchy of groups, which can be used to represent physical or logical
> +flow group/tables on the device, this action allows the terminating action to
> +be a group on that device.
> +
> +- Terminating by default.

Since there are no more "terminating" actions, you should document that it
will cause traffic to be processed by flow rules found in the target group.

Also I think you should put emphasis on undefined behavior:

- Targeting a group that doesn't include any flow rule.
- Triggering loops.

> +
> +.. _table_rte_flow_action_jump:
> +
> +.. table:: JUMP
> +
> +   +-----------+---------------------------------+
> +   | Field     | Value                           |
> +   +===========+=================================+
> +   | ``group`` | Group ID to redirect packets to |
> +   +-----------+---------------------------------+

Nit: "Group ID" => "group ID" to keep the style.

> +
>  Action: ``MARK``
>  ^^^^^^^^^^^^^^^^
>  
> @@ -1512,7 +1534,7 @@ the RTE_FLOW_ITEM_TYPE_END item type.
>     | ``definition`` | Tunnel end-point overlay definition |
>     +----------------+-------------------------------------+
>  
> -.. _table_rte_flow_action_tunnel_encap_example:
> +.. _table_rte_flow_action_tunnel_encap_vxlan_example:
>  
>  .. table:: IPv4 VxLAN flow pattern example.
>  
> @@ -1551,7 +1573,7 @@ NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network Virtualizatio
>  Using Generic Routing Encapsulation). The pattern must be terminated with
>  the RTE_FLOW_ITEM_TYPE_END item type.
>  
> -.. _table_rte_flow_action_tunnel_encap_example:
> +.. _table_rte_flow_action_tunnel_encap_nvgre_example:

The above two hunks do not seem relevant.

>
>  .. table:: IPv4 NVGRE flow pattern example.
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 537e1bfba..91544f62b 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -913,6 +913,20 @@ enum rte_flow_action_type {
>  	 */
>  	RTE_FLOW_ACTION_TYPE_PASSTHRU,
>  
> +	/**
> +	 * RTE_FLOW_ACTION_TYPE_JUMP
> +	 *
> +	 * Redirects packets to a group on the current device.
> +	 *
> +	 * In a hierarchy of groups, which can be used to represent
> +	 * physical or logical flow groups/tables on a device, this
> +	 * action allows the terminating action to be a group on
> +	 * that device.

Since struct rte_flow_action_jump provides complete documentation, no need
to repeat this paragraph here. A single line is enough (see other actions).

> +	 *
> +	 * See struct rte_flow_action_jump

Nit: missing "."

> +	 */
> +	RTE_FLOW_ACTION_TYPE_JUMP,
> +
>  	/**
>  	 * [META]
>  	 *
> @@ -1213,6 +1227,19 @@ struct rte_flow_action_tunnel_encap {
>  	 */
>  };
>  
> +/**
> + * RTE_FLOW_ACTION_TYPE_JUMP
> + *
> + * Redirects packets to a group on the current device.
> + *
> + * In a hierarchy of groups, which can be used to represent physical or logical
> + * flow tables on the device, this action allows the action to be a redirect to
> + * a group on that device.

Remember to synchronize this paragraph after making changes to rte_flow.rst.

Here you can also provide more info regarding undefined behavior (useful in
Doxygen format for application writers).

> + */
> +struct rte_flow_action_jump {
> +	uint32_t group;
> +};
> +

You should move this definition before "struct rte_flow_action_mark" to keep
the same definition order as in the enum.

>  /**
>   * Definition of a single action.
>   *
> -- 
> 2.14.3
> 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v4 3/6] testpmd: add jump action

[Declan Doherty]

Add support for specificaiton of new JUMP action to testpmd's flow
cli, and update the testpmd documentation to describe this new
action.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c                 | 23 +++++++++++++++++++++++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++++
 2 files changed, 27 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 59f3b3b57..93e9a240d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -157,6 +157,8 @@ enum index {
 	ACTION_END,
 	ACTION_VOID,
 	ACTION_PASSTHRU,
+	ACTION_JUMP,
+	ACTION_JUMP_GROUP,
 	ACTION_MARK,
 	ACTION_MARK_ID,
 	ACTION_FLAG,
@@ -590,6 +592,7 @@ static const enum index next_action[] = {
 	ACTION_END,
 	ACTION_VOID,
 	ACTION_PASSTHRU,
+	ACTION_JUMP,
 	ACTION_MARK,
 	ACTION_FLAG,
 	ACTION_QUEUE,
@@ -640,6 +643,12 @@ static const enum index action_meter[] = {
 	ZERO,
 };
 
+static const enum index action_jump[] = {
+	ACTION_JUMP_GROUP,
+	ACTION_NEXT,
+	ZERO,
+};
+
 static int parse_init(struct context *, const struct token *,
 		      const char *, unsigned int,
 		      void *, unsigned int);
@@ -1506,6 +1515,20 @@ static const struct token token_list[] = {
 		.next = NEXT(NEXT_ENTRY(ACTION_NEXT)),
 		.call = parse_vc,
 	},
+	[ACTION_JUMP] = {
+		.name = "jump",
+		.help = "redirect packets to a given group",
+		.priv = PRIV_ACTION(JUMP, sizeof(struct rte_flow_action_jump)),
+		.next = NEXT(action_jump),
+		.call = parse_vc,
+	},
+	[ACTION_JUMP_GROUP] = {
+		.name = "group",
+		.help = "group to redirect packets to",
+		.next = NEXT(action_jump, NEXT_ENTRY(UNSIGNED)),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_jump, group)),
+		.call = parse_vc_conf,
+	},
 	[ACTION_MARK] = {
 		.name = "mark",
 		.help = "attach 32 bit value to packets",
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a766ac795..7ecd602da 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3386,6 +3386,10 @@ This section lists supported actions and their attributes, if any.
 
 - ``passthru``: let subsequent rule process matched packets.
 
+- ``jump``: redirect packet to group on device
+
+  - ``group {unsigned}``: group to redirect to
+
 - ``mark``: attach 32 bit value to packets.
 
   - ``id {unsigned}``: 32 bit value to return with packets.
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 3/6] testpmd: add jump action

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:20PM +0100, Declan Doherty wrote:
> Add support for specificaiton of new JUMP action to testpmd's flow

Typo on "specificaiton".

> cli, and update the testpmd documentation to describe this new
> action.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

Beside minor nits below, this patch is OK. I suggest to merge it in the
previous one ("Add jump action type to rte_flow").

> ---
>  app/test-pmd/cmdline_flow.c                 | 23 +++++++++++++++++++++++
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 59f3b3b57..93e9a240d 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -157,6 +157,8 @@ enum index {
>  	ACTION_END,
>  	ACTION_VOID,
>  	ACTION_PASSTHRU,
> +	ACTION_JUMP,
> +	ACTION_JUMP_GROUP,
>  	ACTION_MARK,
>  	ACTION_MARK_ID,
>  	ACTION_FLAG,
> @@ -590,6 +592,7 @@ static const enum index next_action[] = {
>  	ACTION_END,
>  	ACTION_VOID,
>  	ACTION_PASSTHRU,
> +	ACTION_JUMP,
>  	ACTION_MARK,
>  	ACTION_FLAG,
>  	ACTION_QUEUE,
> @@ -640,6 +643,12 @@ static const enum index action_meter[] = {
>  	ZERO,
>  };
>  
> +static const enum index action_jump[] = {
> +	ACTION_JUMP_GROUP,
> +	ACTION_NEXT,
> +	ZERO,
> +};
> +
>  static int parse_init(struct context *, const struct token *,
>  		      const char *, unsigned int,
>  		      void *, unsigned int);
> @@ -1506,6 +1515,20 @@ static const struct token token_list[] = {
>  		.next = NEXT(NEXT_ENTRY(ACTION_NEXT)),
>  		.call = parse_vc,
>  	},
> +	[ACTION_JUMP] = {
> +		.name = "jump",
> +		.help = "redirect packets to a given group",

How about: packets => traffic

> +		.priv = PRIV_ACTION(JUMP, sizeof(struct rte_flow_action_jump)),
> +		.next = NEXT(action_jump),
> +		.call = parse_vc,
> +	},
> +	[ACTION_JUMP_GROUP] = {
> +		.name = "group",
> +		.help = "group to redirect packets to",
> +		.next = NEXT(action_jump, NEXT_ENTRY(UNSIGNED)),
> +		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_jump, group)),
> +		.call = parse_vc_conf,
> +	},
>  	[ACTION_MARK] = {
>  		.name = "mark",
>  		.help = "attach 32 bit value to packets",
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index a766ac795..7ecd602da 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -3386,6 +3386,10 @@ This section lists supported actions and their attributes, if any.
>  
>  - ``passthru``: let subsequent rule process matched packets.
>  
> +- ``jump``: redirect packet to group on device

Missing "."

> +
> +  - ``group {unsigned}``: group to redirect to

Ditto.

> +
>  - ``mark``: attach 32 bit value to packets.
>  
>    - ``id {unsigned}``: 32 bit value to return with packets.
> -- 
> 2.14.3
> 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow item types

[Declan Doherty]

Introduces a new action type RTE_FLOW_ITEM_TYPE_MARK which enables
flow patterns to specify arbitrary integer values to match aginst
which are set by the RTE_FLOW_ACTION_TYPE_MARK action in a 
previously matched flow from a higher prioriry group.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 28 ++++++++++++++++++++++++++++
 lib/librte_ether/rte_flow.h        | 24 ++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 325010544..6f23ad909 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -598,6 +598,34 @@ associated with a port_id should be retrieved by other means.
    | ``mask`` | ``index`` | zeroed to match any port index |
    +----------+-----------+--------------------------------+
 
+Item: ``MARK``
+^^^^^^^^^^^^^^
+
+Matches packets coming from a previously matched flow in a higher priority group
+with an arbitrary integer value which was set using the ``MARK`` action in the
+previously matched rule.
+
+This item can only specified once as a match criteria as the ``MARK`` action can
+only be specified once in a flow action.
+
+Note the value of MARK field is arbitrary and application defined.
+
+- Default ``mask`` matches any integer value.
+
+.. _table_rte_flow_item_mark:
+
+.. table:: MARK
+
+   +----------+----------+---------------------------+
+   | Field    | Subfield | Value                     |
+   +==========+==========+===========================+
+   | ``spec`` | ``id``   | integer value             |
+   +----------+--------------------------------------+
+   | ``last`` | ``id``   | upper range value         |
+   +----------+----------+---------------------------+
+   | ``mask`` | ``id``   | zeroed to match any value |
+   +----------+------- --+---------------------------+
+
 Data matching item types
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 91544f62b..56e262a23 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -323,6 +323,13 @@ enum rte_flow_item_type {
 	 * See struct rte_flow_item_geneve.
 	 */
 	RTE_FLOW_ITEM_TYPE_GENEVE,
+
+	/**
+	 * Matches specified mark field.
+	 *
+	 * See struct rte_flow_item_mark.
+	 */
+	RTE_FLOW_ITEM_TYPE_MARK
 };
 
 /**
@@ -814,6 +821,23 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
 };
 #endif
 
+/**
+ * RTE_FLOW_ITEM_TYPE_MARK
+ *
+ * Allow arbitrary integer value set using MARK action in a flow rule in a
+ * higher priority group to be matched against in flow rule in a lower
+ * priority group.
+ *
+ * This value is arbitrary and application-defined. Maximum allowed value
+ * depends on the underlying implementation.
+ *
+ * Depending on the underlying implementation the MARK item may be supported in
+ * the physical device, virtually in logical groups in the PMD or not at all.
+ */
+struct rte_flow_item_mark {
+	uint32_t id; /**< Integer value to match against. */
+};
+
 /**
  * Matching pattern item definition.
  *
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow item types

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:21PM +0100, Declan Doherty wrote:
> Introduces a new action type RTE_FLOW_ITEM_TYPE_MARK which enables
> flow patterns to specify arbitrary integer values to match aginst

Typo on "aginst".

> which are set by the RTE_FLOW_ACTION_TYPE_MARK action in a 
> previously matched flow from a higher prioriry group.

prioriry => priority, however this last addition is unnecessary, it could be
any prior flow rule that happens to use PASSTHRU.

> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 28 ++++++++++++++++++++++++++++
>  lib/librte_ether/rte_flow.h        | 24 ++++++++++++++++++++++++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 325010544..6f23ad909 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -598,6 +598,34 @@ associated with a port_id should be retrieved by other means.
>     | ``mask`` | ``index`` | zeroed to match any port index |
>     +----------+-----------+--------------------------------+
>  
> +Item: ``MARK``
> +^^^^^^^^^^^^^^
> +
> +Matches packets coming from a previously matched flow in a higher priority group

See above re "higher priority group".

> +with an arbitrary integer value which was set using the ``MARK`` action in the
> +previously matched rule.
> +
> +This item can only specified once as a match criteria as the ``MARK`` action can
> +only be specified once in a flow action.
> +
> +Note the value of MARK field is arbitrary and application defined.
> +
> +- Default ``mask`` matches any integer value.
> +
> +.. _table_rte_flow_item_mark:
> +
> +.. table:: MARK
> +
> +   +----------+----------+---------------------------+
> +   | Field    | Subfield | Value                     |
> +   +==========+==========+===========================+
> +   | ``spec`` | ``id``   | integer value             |
> +   +----------+--------------------------------------+
> +   | ``last`` | ``id``   | upper range value         |
> +   +----------+----------+---------------------------+
> +   | ``mask`` | ``id``   | zeroed to match any value |
> +   +----------+------- --+---------------------------+
> +
>  Data matching item types
>  ~~~~~~~~~~~~~~~~~~~~~~~~
>  
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 91544f62b..56e262a23 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -323,6 +323,13 @@ enum rte_flow_item_type {
>  	 * See struct rte_flow_item_geneve.
>  	 */
>  	RTE_FLOW_ITEM_TYPE_GENEVE,
> +
> +	/**
> +	 * Matches specified mark field.
> +	 *
> +	 * See struct rte_flow_item_mark.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_MARK

Remember to add a trailing comma.

>  };
>  
>  /**
> @@ -814,6 +821,23 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
>  };
>  #endif
>  
> +/**
> + * RTE_FLOW_ITEM_TYPE_MARK
> + *
> + * Allow arbitrary integer value set using MARK action in a flow rule in a
> + * higher priority group to be matched against in flow rule in a lower
> + * priority group.
> + *
> + * This value is arbitrary and application-defined. Maximum allowed value
> + * depends on the underlying implementation.
> + *
> + * Depending on the underlying implementation the MARK item may be supported in
> + * the physical device, virtually in logical groups in the PMD or not at all.

See above regarding groups. Also please synchronize this with the contents
of rte_flow.rst. They should be the same.

> + */
> +struct rte_flow_item_mark {
> +	uint32_t id; /**< Integer value to match against. */
> +};
> +
>  /**
>   * Matching pattern item definition.
>   *
> -- 
> 2.14.3
> 

Otherwise this patch looks good.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow item types

[Shahaf Shuler]

Thursday, April 19, 2018 4:04 PM, Adrien Mazarguil:
>
> Subject: Re: [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow
> item types
> 
> On Wed, Apr 18, 2018 at 10:04:21PM +0100, Declan Doherty wrote:
> > Introduces a new action type RTE_FLOW_ITEM_TYPE_MARK which enables
> > flow patterns to specify arbitrary integer values to match aginst
> 
> Typo on "aginst".
> 
> > which are set by the RTE_FLOW_ACTION_TYPE_MARK action in a
> previously
> > matched flow from a higher prioriry group.
> 
> prioriry => priority, however this last addition is unnecessary, it could be any
> prior flow rule that happens to use PASSTHRU.
> 
> >
> > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > ---
> >  doc/guides/prog_guide/rte_flow.rst | 28
> ++++++++++++++++++++++++++++
> >  lib/librte_ether/rte_flow.h        | 24 ++++++++++++++++++++++++
> >  2 files changed, 52 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 325010544..6f23ad909 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -598,6 +598,34 @@ associated with a port_id should be retrieved by
> other means.
> >     | ``mask`` | ``index`` | zeroed to match any port index |
> >     +----------+-----------+--------------------------------+
> >
> > +Item: ``MARK``
> > +^^^^^^^^^^^^^^
> > +
> > +Matches packets coming from a previously matched flow in a higher
> > +priority group
> 
> See above re "higher priority group".
> 
> > +with an arbitrary integer value which was set using the ``MARK``
> > +action in the previously matched rule.
> > +

Why we have to bind It with the MARK? It is HW limitation or design consideration? 

My understanding is you want flow action of setting metadata to be used later as a matching item for the flows on other group.
It doesn't have to, but can be, bounded with the specific mark the application wants to receive. 

Re: [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow item types

[Adrien Mazarguil]

On Mon, Apr 23, 2018 at 11:10:11AM +0000, Shahaf Shuler wrote:
> Thursday, April 19, 2018 4:04 PM, Adrien Mazarguil:
> >
> > Subject: Re: [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow
> > item types
> > 
> > On Wed, Apr 18, 2018 at 10:04:21PM +0100, Declan Doherty wrote:
> > > Introduces a new action type RTE_FLOW_ITEM_TYPE_MARK which enables
> > > flow patterns to specify arbitrary integer values to match aginst
> > 
> > Typo on "aginst".
> > 
> > > which are set by the RTE_FLOW_ACTION_TYPE_MARK action in a
> > previously
> > > matched flow from a higher prioriry group.
> > 
> > prioriry => priority, however this last addition is unnecessary, it could be any
> > prior flow rule that happens to use PASSTHRU.
> > 
> > >
> > > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > > ---
> > >  doc/guides/prog_guide/rte_flow.rst | 28
> > ++++++++++++++++++++++++++++
> > >  lib/librte_ether/rte_flow.h        | 24 ++++++++++++++++++++++++
> > >  2 files changed, 52 insertions(+)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > > b/doc/guides/prog_guide/rte_flow.rst
> > > index 325010544..6f23ad909 100644
> > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > @@ -598,6 +598,34 @@ associated with a port_id should be retrieved by
> > other means.
> > >     | ``mask`` | ``index`` | zeroed to match any port index |
> > >     +----------+-----------+--------------------------------+
> > >
> > > +Item: ``MARK``
> > > +^^^^^^^^^^^^^^
> > > +
> > > +Matches packets coming from a previously matched flow in a higher
> > > +priority group
> > 
> > See above re "higher priority group".
> > 
> > > +with an arbitrary integer value which was set using the ``MARK``
> > > +action in the previously matched rule.
> > > +
> 
> Why we have to bind It with the MARK? It is HW limitation or design consideration? 
> 
> My understanding is you want flow action of setting metadata to be used later as a matching item for the flows on other group.
> It doesn't have to, but can be, bounded with the specific mark the application wants to receive. 

Yes, no problem with that, I was only commenting the wording of the
description. It reads like it'll only work if a prior MARK action found in a
*different* group set a mark to match. My point was that it could also be a
prior rule in the same group. It could even be added by the device by some
other means.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v4 5/6] testpmd: add support for MARK flow item

[Declan Doherty]

Add support for specificaiton of new MARK flow item in testpmd's cli,
and update testpmd documentation to describe new MARK flow item support.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c                 | 22 ++++++++++++++++++++++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++++
 2 files changed, 26 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 93e9a240d..e6284ce11 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -87,6 +87,8 @@ enum index {
 	ITEM_VF_ID,
 	ITEM_PORT,
 	ITEM_PORT_INDEX,
+	ITEM_MARK,
+	ITEM_MARK_ID,
 	ITEM_RAW,
 	ITEM_RAW_RELATIVE,
 	ITEM_RAW_SEARCH,
@@ -419,6 +421,7 @@ static const enum index next_item[] = {
 	ITEM_PF,
 	ITEM_VF,
 	ITEM_PORT,
+	ITEM_MARK,
 	ITEM_RAW,
 	ITEM_ETH,
 	ITEM_VLAN,
@@ -465,6 +468,12 @@ static const enum index item_port[] = {
 	ZERO,
 };
 
+static const enum index item_mark[] = {
+	ITEM_MARK_ID,
+	ITEM_NEXT,
+	ZERO,
+};
+
 static const enum index item_raw[] = {
 	ITEM_RAW_RELATIVE,
 	ITEM_RAW_SEARCH,
@@ -1041,6 +1050,19 @@ static const struct token token_list[] = {
 		.next = NEXT(item_port, NEXT_ENTRY(UNSIGNED), item_param),
 		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_port, index)),
 	},
+	[ITEM_MARK] = {
+		.name = "mark",
+		.help = "match packets against value set in previous group",
+		.priv = PRIV_ITEM(MARK, sizeof(struct rte_flow_item_mark)),
+		.next = NEXT(item_mark),
+		.call = parse_vc,
+	},
+	[ITEM_MARK_ID] = {
+		.name = "id",
+		.help = "Integer value to match against",
+		.next = NEXT(item_mark, NEXT_ENTRY(UNSIGNED), item_param),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_mark, id)),
+	},
 	[ITEM_RAW] = {
 		.name = "raw",
 		.help = "match an arbitrary byte string",
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 7ecd602da..2b5ade4a8 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3211,6 +3211,10 @@ This section lists supported pattern items and their attributes, if any.
 
   - ``index {unsigned}``: physical port index.
 
+- ``mark``: match value set in previously matched flow in higher priority group.
+
+  - ``id {unsigned}``: arbitrary integer value.
+
 - ``raw``: match an arbitrary byte string.
 
   - ``relative {boolean}``: look for pattern after the previous item.
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 5/6] testpmd: add support for MARK flow item

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:22PM +0100, Declan Doherty wrote:
> Add support for specificaiton of new MARK flow item in testpmd's cli,
> and update testpmd documentation to describe new MARK flow item support.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

specificaiton => specification, however you should merge this in the
previous patch ("ethdev: add mark flow item to flow item types"), a few nits
below.

> ---
>  app/test-pmd/cmdline_flow.c                 | 22 ++++++++++++++++++++++
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 93e9a240d..e6284ce11 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -87,6 +87,8 @@ enum index {
>  	ITEM_VF_ID,
>  	ITEM_PORT,
>  	ITEM_PORT_INDEX,
> +	ITEM_MARK,
> +	ITEM_MARK_ID,
>  	ITEM_RAW,
>  	ITEM_RAW_RELATIVE,
>  	ITEM_RAW_SEARCH,
> @@ -419,6 +421,7 @@ static const enum index next_item[] = {
>  	ITEM_PF,
>  	ITEM_VF,
>  	ITEM_PORT,
> +	ITEM_MARK,
>  	ITEM_RAW,
>  	ITEM_ETH,
>  	ITEM_VLAN,
> @@ -465,6 +468,12 @@ static const enum index item_port[] = {
>  	ZERO,
>  };
>  
> +static const enum index item_mark[] = {
> +	ITEM_MARK_ID,
> +	ITEM_NEXT,
> +	ZERO,
> +};
> +
>  static const enum index item_raw[] = {
>  	ITEM_RAW_RELATIVE,
>  	ITEM_RAW_SEARCH,
> @@ -1041,6 +1050,19 @@ static const struct token token_list[] = {
>  		.next = NEXT(item_port, NEXT_ENTRY(UNSIGNED), item_param),
>  		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_port, index)),
>  	},
> +	[ITEM_MARK] = {
> +		.name = "mark",
> +		.help = "match packets against value set in previous group",

As previously discussed, you should drop the "previous group" part.

> +		.priv = PRIV_ITEM(MARK, sizeof(struct rte_flow_item_mark)),
> +		.next = NEXT(item_mark),
> +		.call = parse_vc,
> +	},
> +	[ITEM_MARK_ID] = {
> +		.name = "id",
> +		.help = "Integer value to match against",
> +		.next = NEXT(item_mark, NEXT_ENTRY(UNSIGNED), item_param),
> +		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_mark, id)),
> +	},
>  	[ITEM_RAW] = {
>  		.name = "raw",
>  		.help = "match an arbitrary byte string",
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 7ecd602da..2b5ade4a8 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -3211,6 +3211,10 @@ This section lists supported pattern items and their attributes, if any.
>  
>    - ``index {unsigned}``: physical port index.
>  
> +- ``mark``: match value set in previously matched flow in higher priority group.
> +
> +  - ``id {unsigned}``: arbitrary integer value.
> +

Ditto.

>  - ``raw``: match an arbitrary byte string.
>  
>    - ``relative {boolean}``: look for pattern after the previous item.
> -- 
> 2.14.3
> 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v4 6/6] ethdev: add shared counter support to rte_flow

[Declan Doherty]

Add rte_flow_action_count action data structure to enable shared
counters across multiple flows on a single port or across multiple
flows on multiple ports within the same switch domain. Also this enables
multiple count actions to be specified in a single flow.

This patch also modifies the existing rte_flow_query API to take the
rte_flow_action structure as an input parameter instead of the
rte_flow_action_type enumeration to allow querying a specific action
from a flow rule when multiple actions of the same type are specified.

This patch also contains updates for the failsafe PMD and
testpmd application which are affected by this API change.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c          |  6 ++---
 app/test-pmd/config.c                | 15 ++++++-----
 app/test-pmd/testpmd.h               |  2 +-
 doc/guides/prog_guide/rte_flow.rst   | 52 ++++++++++++++++++++++--------------
 drivers/net/failsafe/failsafe_flow.c |  4 +--
 lib/librte_ether/rte_flow.c          |  2 +-
 lib/librte_ether/rte_flow.h          | 30 ++++++++++++++++++---
 lib/librte_ether/rte_flow_driver.h   |  2 +-
 8 files changed, 75 insertions(+), 38 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index e6284ce11..cec9885d5 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -347,7 +347,7 @@ struct buffer {
 		} destroy; /**< Destroy arguments. */
 		struct {
 			uint32_t rule;
-			enum rte_flow_action_type action;
+			struct rte_flow_action action;
 		} query; /**< Query arguments. */
 		struct {
 			uint32_t *group;
@@ -874,7 +874,7 @@ static const struct token token_list[] = {
 		.next = NEXT(NEXT_ENTRY(QUERY_ACTION),
 			     NEXT_ENTRY(RULE_ID),
 			     NEXT_ENTRY(PORT_ID)),
-		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action),
+		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action.type),
 			     ARGS_ENTRY(struct buffer, args.query.rule),
 			     ARGS_ENTRY(struct buffer, port)),
 		.call = parse_query,
@@ -2972,7 +2972,7 @@ cmd_flow_parsed(const struct buffer *in)
 		break;
 	case QUERY:
 		port_flow_query(in->port, in->args.query.rule,
-				in->args.query.action);
+				&in->args.query.action);
 		break;
 	case LIST:
 		port_flow_list(in->port, in->args.list.group_n,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index dd051f5ca..2d4ca840d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1342,7 +1342,7 @@ port_flow_flush(portid_t port_id)
 /** Query a flow rule. */
 int
 port_flow_query(portid_t port_id, uint32_t rule,
-		enum rte_flow_action_type action)
+		const struct rte_flow_action *action)
 {
 	struct rte_flow_error error;
 	struct rte_port *port;
@@ -1364,15 +1364,16 @@ port_flow_query(portid_t port_id, uint32_t rule,
 		return -ENOENT;
 	}
 	if ((unsigned int)action >= RTE_DIM(flow_action) ||
-	    !flow_action[action].name)
+	    !flow_action[action->type].name)
 		name = "unknown";
 	else
-		name = flow_action[action].name;
-	switch (action) {
+		name = flow_action[action->type].name;
+	switch (action->type) {
 	case RTE_FLOW_ACTION_TYPE_COUNT:
 		break;
 	default:
-		printf("Cannot query action type %d (%s)\n", action, name);
+		printf("Cannot query action type %d (%s)\n",
+			action->type, name);
 		return -ENOTSUP;
 	}
 	/* Poisoning to make sure PMDs update it in case of error. */
@@ -1380,7 +1381,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
 	memset(&query, 0, sizeof(query));
 	if (rte_flow_query(port_id, pf->flow, action, &query, &error))
 		return port_flow_complain(&error);
-	switch (action) {
+	switch (action->type) {
 	case RTE_FLOW_ACTION_TYPE_COUNT:
 		printf("%s:\n"
 		       " hits_set: %u\n"
@@ -1395,7 +1396,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
 		break;
 	default:
 		printf("Cannot display result for action type %d (%s)\n",
-		       action, name);
+		       action->type, name);
 		break;
 	}
 	return 0;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 98d84da84..a8a046135 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -603,7 +603,7 @@ int port_flow_create(portid_t port_id,
 int port_flow_destroy(portid_t port_id, uint32_t n, const uint32_t *rule);
 int port_flow_flush(portid_t port_id);
 int port_flow_query(portid_t port_id, uint32_t rule,
-		    enum rte_flow_action_type action);
+		    const struct rte_flow_action *action);
 void port_flow_list(portid_t port_id, uint32_t n, const uint32_t *group);
 int port_flow_isolate(portid_t port_id, int set);
 
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 6f23ad909..9f9a16068 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1078,23 +1078,24 @@ consider all actions to be performed simultaneously:
    | 2     | END    |
    +-------+--------+
 
-|
 
 .. _table_rte_flow_mark_count_redirect:
 
 .. table:: Mark, count and redirect
 
-   +-------+--------+-----------+-------+
-   | Index | Action | Field     | Value |
-   +=======+========+===========+=======+
-   | 0     | MARK   | ``mark``  | 0x2a  |
-   +-------+--------+-----------+-------+
-   | 1     | COUNT                      |
-   +-------+--------+-----------+-------+
-   | 2     | QUEUE  | ``queue`` | 10    |
-   +-------+--------+-----------+-------+
-   | 3     | END                        |
-   +-------+----------------------------+
+   +-------+--------+------------+-------+
+   | Index | Action | Field      | Value |
+   +=======+========+============+=======+
+   | 0     | MARK   | ``mark``   | 0x2a  |
+   +-------+--------+------------+-------+
+   | 1     | COUNT  | ``shared`` | 0     |
+   |       |        +------------+-------+
+   |       |        | ``id``     | 0     |
+   +-------+--------+------------+-------+
+   | 2     | QUEUE  | ``queue``  | 10    |
+   +-------+--------+------------+-------+
+   | 3     | END                         |
+   +-------+-----------------------------+
 
 |
 
@@ -1321,17 +1322,28 @@ These counters can be retrieved and reset through ``rte_flow_query()``, see
 ``struct rte_flow_query_count``.
 
 - Counters can be retrieved with ``rte_flow_query()``.
-- No configurable properties.
+
+The shared flag indicates whether the counter is unique to the flow rule the
+action is specified with, or whether it is a shared counter. A shared counter
+scope is within that of the port the flow rule is programmed, with the exception
+of ports which share a common switch domain, it that case the shared counter
+scope is within all the ports in that switch domain.
+
+If more that one count action is specified on a single flow rule then each count
+action must specify a unique counter id.
+
 
 .. _table_rte_flow_action_count:
 
 .. table:: COUNT
 
-   +---------------+
-   | Field         |
-   +===============+
-   | no properties |
-   +---------------+
+   +------------+---------------------+
+   | Field      | Value               |
+   +============+=====================+
+   | ``shared`` | shared counter flag |
+   +------------+---------------------+
+   | ``id``     | counter id          |
+   +------------+---------------------+
 
 Query structure to retrieve and reset flow rule counters:
 
@@ -1820,7 +1832,7 @@ definition.
    int
    rte_flow_query(uint16_t port_id,
                   struct rte_flow *flow,
-                  enum rte_flow_action_type action,
+                  const struct rte_flow_action *action,
                   void *data,
                   struct rte_flow_error *error);
 
@@ -1828,7 +1840,7 @@ Arguments:
 
 - ``port_id``: port identifier of Ethernet device.
 - ``flow``: flow rule handle to query.
-- ``action``: action type to query.
+- ``action``: action to query, this must match prototype from flow rule.
 - ``data``: pointer to storage for the associated query data type.
 - ``error``: perform verbose error reporting if not NULL. PMDs initialize
   this structure in case of error only.
diff --git a/drivers/net/failsafe/failsafe_flow.c b/drivers/net/failsafe/failsafe_flow.c
index a97f4075d..bfe42fcee 100644
--- a/drivers/net/failsafe/failsafe_flow.c
+++ b/drivers/net/failsafe/failsafe_flow.c
@@ -174,7 +174,7 @@ fs_flow_flush(struct rte_eth_dev *dev,
 static int
 fs_flow_query(struct rte_eth_dev *dev,
 	      struct rte_flow *flow,
-	      enum rte_flow_action_type type,
+	      const struct rte_flow_action *action,
 	      void *arg,
 	      struct rte_flow_error *error)
 {
@@ -185,7 +185,7 @@ fs_flow_query(struct rte_eth_dev *dev,
 	if (sdev != NULL) {
 		int ret = rte_flow_query(PORT_ID(sdev),
 					 flow->flows[SUB_ID(sdev)],
-					 type, arg, error);
+					 action, arg, error);
 
 		if ((ret = fs_err(sdev, ret))) {
 			fs_unlock(dev, 0);
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index a3823d874..516e6530e 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -201,7 +201,7 @@ rte_flow_flush(uint16_t port_id,
 int
 rte_flow_query(uint16_t port_id,
 	       struct rte_flow *flow,
-	       enum rte_flow_action_type action,
+	       const struct rte_flow_action *action,
 	       void *data,
 	       struct rte_flow_error *error)
 {
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 56e262a23..f58e96060 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -995,7 +995,7 @@ enum rte_flow_action_type {
 	 * These counters can be retrieved and reset through rte_flow_query(),
 	 * see struct rte_flow_query_count.
 	 *
-	 * No associated configuration structure.
+	 * See struct rte_flow_action_count.
 	 */
 	RTE_FLOW_ACTION_TYPE_COUNT,
 
@@ -1104,6 +1104,30 @@ struct rte_flow_action_queue {
 	uint16_t index; /**< Queue index to use. */
 };
 
+
+/**
+ * RTE_FLOW_ACTION_TYPE_COUNT
+ *
+ * Add a counter action to a matched flow
+ *
+ * If more than one count action is specified in a single flow rule, then each
+ * action must specify a unique id.
+ *
+ * For a count action with the shared flag set, then then a global device
+ * namespace is assumed for the counter id, so that any matched flow rules using
+ * a count action with the same counter id on the same port will contribute to
+ * that counter.
+ *
+ * For ports within the same switch domain then the counter id namespace extends
+ * to all ports within that switch domain.
+ *
+ */
+struct rte_flow_action_count {
+	uint32_t shared:1; /**< Share counter ID with other flow rules. */
+	uint32_t reserved:31; /**< Reserved, must be zero. */
+	uint32_t id; /**< Counter ID. */
+};
+
 /**
  * RTE_FLOW_ACTION_TYPE_COUNT (query)
  *
@@ -1467,7 +1491,7 @@ rte_flow_flush(uint16_t port_id,
  * @param flow
  *   Flow rule handle to query.
  * @param action
- *   Action type to query.
+ *   Action definition as defined in original flow rule
  * @param[in, out] data
  *   Pointer to storage for the associated query data type.
  * @param[out] error
@@ -1480,7 +1504,7 @@ rte_flow_flush(uint16_t port_id,
 int
 rte_flow_query(uint16_t port_id,
 	       struct rte_flow *flow,
-	       enum rte_flow_action_type action,
+	       const struct rte_flow_action *action,
 	       void *data,
 	       struct rte_flow_error *error);
 
diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
index 3800310ba..1c90c600d 100644
--- a/lib/librte_ether/rte_flow_driver.h
+++ b/lib/librte_ether/rte_flow_driver.h
@@ -88,7 +88,7 @@ struct rte_flow_ops {
 	int (*query)
 		(struct rte_eth_dev *,
 		 struct rte_flow *,
-		 enum rte_flow_action_type,
+		 const struct rte_flow_action *,
 		 void *,
 		 struct rte_flow_error *);
 	/** See rte_flow_isolate(). */
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4 6/6] ethdev: add shared counter support to rte_flow

[Adrien Mazarguil]

On Wed, Apr 18, 2018 at 10:04:23PM +0100, Declan Doherty wrote:
> Add rte_flow_action_count action data structure to enable shared
> counters across multiple flows on a single port or across multiple
> flows on multiple ports within the same switch domain. Also this enables
> multiple count actions to be specified in a single flow.
> 
> This patch also modifies the existing rte_flow_query API to take the
> rte_flow_action structure as an input parameter instead of the
> rte_flow_action_type enumeration to allow querying a specific action
> from a flow rule when multiple actions of the same type are specified.
> 
> This patch also contains updates for the failsafe PMD and
> testpmd application which are affected by this API change.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>

Patch is almost ready, please see the bunch of nits below.

> ---
>  app/test-pmd/cmdline_flow.c          |  6 ++---
>  app/test-pmd/config.c                | 15 ++++++-----
>  app/test-pmd/testpmd.h               |  2 +-
>  doc/guides/prog_guide/rte_flow.rst   | 52 ++++++++++++++++++++++--------------
>  drivers/net/failsafe/failsafe_flow.c |  4 +--
>  lib/librte_ether/rte_flow.c          |  2 +-
>  lib/librte_ether/rte_flow.h          | 30 ++++++++++++++++++---
>  lib/librte_ether/rte_flow_driver.h   |  2 +-
>  8 files changed, 75 insertions(+), 38 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index e6284ce11..cec9885d5 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -347,7 +347,7 @@ struct buffer {
>  		} destroy; /**< Destroy arguments. */
>  		struct {
>  			uint32_t rule;
> -			enum rte_flow_action_type action;
> +			struct rte_flow_action action;
>  		} query; /**< Query arguments. */
>  		struct {
>  			uint32_t *group;
> @@ -874,7 +874,7 @@ static const struct token token_list[] = {
>  		.next = NEXT(NEXT_ENTRY(QUERY_ACTION),
>  			     NEXT_ENTRY(RULE_ID),
>  			     NEXT_ENTRY(PORT_ID)),
> -		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action),
> +		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action.type),
>  			     ARGS_ENTRY(struct buffer, args.query.rule),
>  			     ARGS_ENTRY(struct buffer, port)),
>  		.call = parse_query,
> @@ -2972,7 +2972,7 @@ cmd_flow_parsed(const struct buffer *in)
>  		break;
>  	case QUERY:
>  		port_flow_query(in->port, in->args.query.rule,
> -				in->args.query.action);
> +				&in->args.query.action);
>  		break;
>  	case LIST:
>  		port_flow_list(in->port, in->args.list.group_n,
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index dd051f5ca..2d4ca840d 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -1342,7 +1342,7 @@ port_flow_flush(portid_t port_id)
>  /** Query a flow rule. */
>  int
>  port_flow_query(portid_t port_id, uint32_t rule,
> -		enum rte_flow_action_type action)
> +		const struct rte_flow_action *action)
>  {
>  	struct rte_flow_error error;
>  	struct rte_port *port;
> @@ -1364,15 +1364,16 @@ port_flow_query(portid_t port_id, uint32_t rule,
>  		return -ENOENT;
>  	}
>  	if ((unsigned int)action >= RTE_DIM(flow_action) ||
> -	    !flow_action[action].name)
> +	    !flow_action[action->type].name)
>  		name = "unknown";
>  	else
> -		name = flow_action[action].name;
> -	switch (action) {
> +		name = flow_action[action->type].name;
> +	switch (action->type) {
>  	case RTE_FLOW_ACTION_TYPE_COUNT:
>  		break;
>  	default:
> -		printf("Cannot query action type %d (%s)\n", action, name);
> +		printf("Cannot query action type %d (%s)\n",
> +			action->type, name);
>  		return -ENOTSUP;
>  	}
>  	/* Poisoning to make sure PMDs update it in case of error. */
> @@ -1380,7 +1381,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
>  	memset(&query, 0, sizeof(query));
>  	if (rte_flow_query(port_id, pf->flow, action, &query, &error))
>  		return port_flow_complain(&error);
> -	switch (action) {
> +	switch (action->type) {
>  	case RTE_FLOW_ACTION_TYPE_COUNT:
>  		printf("%s:\n"
>  		       " hits_set: %u\n"
> @@ -1395,7 +1396,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
>  		break;
>  	default:
>  		printf("Cannot display result for action type %d (%s)\n",
> -		       action, name);
> +		       action->type, name);
>  		break;
>  	}
>  	return 0;
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
> index 98d84da84..a8a046135 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -603,7 +603,7 @@ int port_flow_create(portid_t port_id,
>  int port_flow_destroy(portid_t port_id, uint32_t n, const uint32_t *rule);
>  int port_flow_flush(portid_t port_id);
>  int port_flow_query(portid_t port_id, uint32_t rule,
> -		    enum rte_flow_action_type action);
> +		    const struct rte_flow_action *action);
>  void port_flow_list(portid_t port_id, uint32_t n, const uint32_t *group);
>  int port_flow_isolate(portid_t port_id, int set);
>  
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 6f23ad909..9f9a16068 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1078,23 +1078,24 @@ consider all actions to be performed simultaneously:
>     | 2     | END    |
>     +-------+--------+
>  
> -|

This should stay. It's a special separator to untangle successive tables
when generating documentaton.

>  
>  .. _table_rte_flow_mark_count_redirect:
>  
>  .. table:: Mark, count and redirect
>  
> -   +-------+--------+-----------+-------+
> -   | Index | Action | Field     | Value |
> -   +=======+========+===========+=======+
> -   | 0     | MARK   | ``mark``  | 0x2a  |
> -   +-------+--------+-----------+-------+
> -   | 1     | COUNT                      |
> -   +-------+--------+-----------+-------+
> -   | 2     | QUEUE  | ``queue`` | 10    |
> -   +-------+--------+-----------+-------+
> -   | 3     | END                        |
> -   +-------+----------------------------+
> +   +-------+--------+------------+-------+
> +   | Index | Action | Field      | Value |
> +   +=======+========+============+=======+
> +   | 0     | MARK   | ``mark``   | 0x2a  |
> +   +-------+--------+------------+-------+
> +   | 1     | COUNT  | ``shared`` | 0     |
> +   |       |        +------------+-------+
> +   |       |        | ``id``     | 0     |
> +   +-------+--------+------------+-------+
> +   | 2     | QUEUE  | ``queue``  | 10    |
> +   +-------+--------+------------+-------+
> +   | 3     | END                         |
> +   +-------+-----------------------------+
>  
>  |
>  
> @@ -1321,17 +1322,28 @@ These counters can be retrieved and reset through ``rte_flow_query()``, see
>  ``struct rte_flow_query_count``.
>  
>  - Counters can be retrieved with ``rte_flow_query()``.
> -- No configurable properties.
> +
> +The shared flag indicates whether the counter is unique to the flow rule the
> +action is specified with, or whether it is a shared counter. A shared counter
> +scope is within that of the port the flow rule is programmed, with the exception
> +of ports which share a common switch domain, it that case the shared counter
> +scope is within all the ports in that switch domain.
> +
> +If more that one count action is specified on a single flow rule then each count
> +action must specify a unique counter id.
> +

Extraneous empty line.

>  
>  .. _table_rte_flow_action_count:
>  
>  .. table:: COUNT
>  
> -   +---------------+
> -   | Field         |
> -   +===============+
> -   | no properties |
> -   +---------------+
> +   +------------+---------------------+
> +   | Field      | Value               |
> +   +============+=====================+
> +   | ``shared`` | shared counter flag |
> +   +------------+---------------------+
> +   | ``id``     | counter id          |
> +   +------------+---------------------+
>  
>  Query structure to retrieve and reset flow rule counters:
>  
> @@ -1820,7 +1832,7 @@ definition.
>     int
>     rte_flow_query(uint16_t port_id,
>                    struct rte_flow *flow,
> -                  enum rte_flow_action_type action,
> +                  const struct rte_flow_action *action,
>                    void *data,
>                    struct rte_flow_error *error);
>  
> @@ -1828,7 +1840,7 @@ Arguments:
>  
>  - ``port_id``: port identifier of Ethernet device.
>  - ``flow``: flow rule handle to query.
> -- ``action``: action type to query.
> +- ``action``: action to query, this must match prototype from flow rule.
>  - ``data``: pointer to storage for the associated query data type.
>  - ``error``: perform verbose error reporting if not NULL. PMDs initialize
>    this structure in case of error only.
> diff --git a/drivers/net/failsafe/failsafe_flow.c b/drivers/net/failsafe/failsafe_flow.c
> index a97f4075d..bfe42fcee 100644
> --- a/drivers/net/failsafe/failsafe_flow.c
> +++ b/drivers/net/failsafe/failsafe_flow.c
> @@ -174,7 +174,7 @@ fs_flow_flush(struct rte_eth_dev *dev,
>  static int
>  fs_flow_query(struct rte_eth_dev *dev,
>  	      struct rte_flow *flow,
> -	      enum rte_flow_action_type type,
> +	      const struct rte_flow_action *action,
>  	      void *arg,
>  	      struct rte_flow_error *error)
>  {
> @@ -185,7 +185,7 @@ fs_flow_query(struct rte_eth_dev *dev,
>  	if (sdev != NULL) {
>  		int ret = rte_flow_query(PORT_ID(sdev),
>  					 flow->flows[SUB_ID(sdev)],
> -					 type, arg, error);
> +					 action, arg, error);
>  
>  		if ((ret = fs_err(sdev, ret))) {
>  			fs_unlock(dev, 0);
> diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
> index a3823d874..516e6530e 100644
> --- a/lib/librte_ether/rte_flow.c
> +++ b/lib/librte_ether/rte_flow.c
> @@ -201,7 +201,7 @@ rte_flow_flush(uint16_t port_id,
>  int
>  rte_flow_query(uint16_t port_id,
>  	       struct rte_flow *flow,
> -	       enum rte_flow_action_type action,
> +	       const struct rte_flow_action *action,
>  	       void *data,
>  	       struct rte_flow_error *error)
>  {
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index 56e262a23..f58e96060 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -995,7 +995,7 @@ enum rte_flow_action_type {
>  	 * These counters can be retrieved and reset through rte_flow_query(),
>  	 * see struct rte_flow_query_count.
>  	 *
> -	 * No associated configuration structure.
> +	 * See struct rte_flow_action_count.
>  	 */
>  	RTE_FLOW_ACTION_TYPE_COUNT,
>  
> @@ -1104,6 +1104,30 @@ struct rte_flow_action_queue {
>  	uint16_t index; /**< Queue index to use. */
>  };
>  
> +

Extraneous empty line.

> +/**
> + * RTE_FLOW_ACTION_TYPE_COUNT
> + *
> + * Add a counter action to a matched flow
> + *
> + * If more than one count action is specified in a single flow rule, then each
> + * action must specify a unique id.
> + *
> + * For a count action with the shared flag set, then then a global device
> + * namespace is assumed for the counter id, so that any matched flow rules using
> + * a count action with the same counter id on the same port will contribute to
> + * that counter.
> + *
> + * For ports within the same switch domain then the counter id namespace extends
> + * to all ports within that switch domain.

Please keep this documentation synchronized with rte_flow.rst.

> + *

Extraneous line.

> + */
> +struct rte_flow_action_count {
> +	uint32_t shared:1; /**< Share counter ID with other flow rules. */
> +	uint32_t reserved:31; /**< Reserved, must be zero. */
> +	uint32_t id; /**< Counter ID. */
> +};
> +
>  /**
>   * RTE_FLOW_ACTION_TYPE_COUNT (query)
>   *
> @@ -1467,7 +1491,7 @@ rte_flow_flush(uint16_t port_id,
>   * @param flow
>   *   Flow rule handle to query.
>   * @param action
> - *   Action type to query.
> + *   Action definition as defined in original flow rule

Missing "."

>   * @param[in, out] data
>   *   Pointer to storage for the associated query data type.
>   * @param[out] error
> @@ -1480,7 +1504,7 @@ rte_flow_flush(uint16_t port_id,
>  int
>  rte_flow_query(uint16_t port_id,
>  	       struct rte_flow *flow,
> -	       enum rte_flow_action_type action,
> +	       const struct rte_flow_action *action,
>  	       void *data,
>  	       struct rte_flow_error *error);
>  
> diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
> index 3800310ba..1c90c600d 100644
> --- a/lib/librte_ether/rte_flow_driver.h
> +++ b/lib/librte_ether/rte_flow_driver.h
> @@ -88,7 +88,7 @@ struct rte_flow_ops {
>  	int (*query)
>  		(struct rte_eth_dev *,
>  		 struct rte_flow *,
> -		 enum rte_flow_action_type,
> +		 const struct rte_flow_action *,
>  		 void *,
>  		 struct rte_flow_error *);
>  	/** See rte_flow_isolate(). */
> -- 
> 2.14.3
> 

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v4 0/6] additions to support tunnel encap/decap

[Shahaf Shuler]

Hi Declan,


Thursday, April 19, 2018 12:04 AM, Declan Doherty:
> <zhihong.wang@intel.com>; Declan Doherty <declan.doherty@intel.com>
> Subject: [dpdk-dev][PATCH v4 0/6] additions to support tunnel encap/decap
> 
> This patchset contains the revised proposal to manage virtual tunnel
> endpoints hardware accleration based on community feedback on RFC
> 
> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> dk.org%2Fml%2Farchives%2Fdev%2F2017-
> December%2F084676.html&data=02%7C01%7Cshahafs%40mellanox.com%7
> C543d0b7cb2ed4d382b3908d5a5713a52%7Ca652971c7d2e4d9ba6a4d149256f4
> 61b%7C0%7C0%7C636596828115384315&sdata=FgEiWJxF9zpA6NwsE1a22W6
> V0Bz1NH6rzXfJYvpxIj0%3D&reserved=0). This
> 
> proposal is purely enabled through rte_flow APIs with the additions of some
> new features which were previously implemented by the proposed rte_tep
> APIs which were proposed in the original RFC. This patchset ultimately aims
> to enable the configuration of inline data path encapsulation and
> decapsulation of tunnel endpoint network overlays on accelerated IO
> devices.

This series is very important one to provide the means for full vswitch offload.

Besides Adrien's comments (and my small ones), the patchset looks good. 
Do you plan to send new version soon?

Re: [dpdk-dev] [PATCH v4 0/6] additions to support tunnel encap/decap

[Doherty, Declan]

On 23/04/2018 12:11 PM, Shahaf Shuler wrote:
> Hi Declan,
> 
> 
> Thursday, April 19, 2018 12:04 AM, Declan Doherty:
>> <zhihong.wang@intel.com>; Declan Doherty <declan.doherty@intel.com>
>> Subject: [dpdk-dev][PATCH v4 0/6] additions to support tunnel encap/decap
>>
>> This patchset contains the revised proposal to manage virtual tunnel
>> endpoints hardware accleration based on community feedback on RFC
>>
>> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
>> dk.org%2Fml%2Farchives%2Fdev%2F2017-
>> December%2F084676.html&data=02%7C01%7Cshahafs%40mellanox.com%7
>> C543d0b7cb2ed4d382b3908d5a5713a52%7Ca652971c7d2e4d9ba6a4d149256f4
>> 61b%7C0%7C0%7C636596828115384315&sdata=FgEiWJxF9zpA6NwsE1a22W6
>> V0Bz1NH6rzXfJYvpxIj0%3D&reserved=0). This
>>
>> proposal is purely enabled through rte_flow APIs with the additions of some
>> new features which were previously implemented by the proposed rte_tep
>> APIs which were proposed in the original RFC. This patchset ultimately aims
>> to enable the configuration of inline data path encapsulation and
>> decapsulation of tunnel endpoint network overlays on accelerated IO
>> devices.
> 
> This series is very important one to provide the means for full vswitch offload.
> 
> Besides Adrien's comments (and my small ones), the patchset looks good.
> Do you plan to send new version soon?
> 

Hopefully within the next 2 hours, I'm just finishing up addressing the 
last couple of comments.

[dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap

[Declan Doherty]

This patchset contains the revised proposal to manage 
tunnel endpoints hardware accleration based on community
feedback on RFC
(http://dpdk.org/ml/archives/dev/2017-December/084676.html). This

proposal is purely enabled through rte_flow APIs with the
additions of some new features which were previously implemented
by the proposed rte_tep APIs which were proposed in the original
RFC. This patchset ultimately aims to enable the configuration
of inline data path encapsulation and decapsulation of tunnel
endpoint network overlays on accelerated IO devices.

V2:
Split new functions into separate patches, and add additional
documentaiton.

V3:
Extended the description of group counter in documentation.
Renamed VTEP to TUNNEL.
Fixed C99 syntax.

V4:
- Modify encap/decap actions to be protocol specific
- rename group action type to jump
- add mark flow item type in place of metadata flow/action types
- add count action data structure
- modify query API to accept rte_flow_action structure in place of
  rte_flow_actio_type enumeration to support specification and
  querying of multiple actions of the same type

V5:
- Documentation and comment updates
- Mark new API structures as experimental
- squash new function testpmd enablement into relevant patches.

The summary of the additions to the rte_flow are as follows:

- Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP and
RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP to rte_flow to support
specfication of encapsulation and decapsulation of VXLAN and NVGRE
tunnels in hardware.

- Introduces support for the use of pipeline metadata in
the flow pattern definition and the population of metadata fields
from flow actions using the MARK flow and action items.

- Add shared flag to counters to enable statistics to be kept on
groups offlows such as all ingress/egress flows of a tunnel

- Adds jump_action to allow a flows to be redirected to a group
within the device.


A high level summary of the proposed usage model is as follows:

1. Decapsulation

1.1. Decapsulation of tunnel outer headers and forward all traffic
     to the same queue/s or port, would have the follow flows
     paramteters, sudo code used here.

struct rte_flow_attr attr = { .ingress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP },
	{ .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action  },
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}


1.2.

Decapsulation of tunnel outer headers and matching on inner
headers, and forwarding to the same queue/s or port.

1.2.1.

The same scenario as above but either the application
or hardware requires configuration as 2 logically independent
operations (viewing it as 2 logical tables). The first stage
being the flow rule to define the pattern to match the tunnel
and the action to decapsulate the packet, and the second stage
stage table matches the inner header and defines the actions,
forward to port etc.

flow rule for outer header on table 0

struct rte_flow_attr attr = { .ingress = 1, .table = 0 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_item_count shared_couter = {
	.shared = 1,
	.id = {counter_id}
}

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &shared_counter },
	{ .type = RTE_FLOW_ACTION_TYPE_MARK, .conf = &mark_action },
	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP },

	{
	  .type = RTE_FLOW_ACTION_TYPE_JUMP,
	  .conf = { .group = 1 }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

flow rule for inner header on table 1

struct rte_flow_attr attr = { .ingress = 1, .group = 1 };

struct rte_flow_item_mark mark_item = { id = {mark_id} };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_MARK,  .spec = &mark_item },
	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action actions[] = {
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

Note that the mark action in the flow rule in group 0 is generating
the value in the pipeline which is then used in as part as the flow
pattern in group 1 to specify the exact flow to match against. In the
case where exact match rules are being provided by the application
explicitly then the MARK item value can be provided by the application
in the flow pattern for the flow rule in group 1 also. 

2. Encapsulation

Encapsulation of all traffic matching a specific flow pattern to a
specified tunnel and egressing to a particular port.

struct rte_flow_attr attr = { .egress = 1 };

struct rte_flow_item pattern[] = {
	{ .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &eth_item },
	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
	{ .type = RTE_FLOW_ITEM_TYPE_END }
};

struct rte_flow_action_tunnel_encap vxlan_encap_action = {
	.definition = {
		{ .type=eth, .spec={}, .mask={} },
		{ .type=ipv4, .spec={}, .mask={} },
		{ .type=udp, .spec={}, .mask={} },
		{ .type=vxlan, .spec={}, .mask={} }
		{ .type=end }
	}
};

struct rte_flow_action actions[] = {
	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &count } },
	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, .conf = &vxlan_encap_action } },
	{
	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
	  .conf = &port_id_action = { port_id }
	},
	{ .type = RTE_FLOW_ACTION_TYPE_END }

};

Declan Doherty (4):
  ethdev: Add tunnel encap/decap actions
  ethdev: Add group JUMP action
  ethdev: add mark flow item to rte_flow_item_types
  ethdev: add shared counter support to rte_flow

 app/test-pmd/cmdline_flow.c                 |  51 +++++-
 app/test-pmd/config.c                       |  15 +-
 app/test-pmd/testpmd.h                      |   2 +-
 doc/guides/prog_guide/rte_flow.rst          | 257 ++++++++++++++++++++++++----
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   8 +
 drivers/net/failsafe/failsafe_flow.c        |   4 +-
 lib/librte_ether/rte_flow.c                 |   2 +-
 lib/librte_ether/rte_flow.h                 | 213 +++++++++++++++++++++--
 lib/librte_ether/rte_flow_driver.h          |   2 +-
 9 files changed, 496 insertions(+), 58 deletions(-)

-- 
2.14.3

[dpdk-dev] [PATCH v5 1/4] ethdev: Add tunnel encap/decap actions

[Declan Doherty]

Add new flow action types and associated action data structures to
support the encapsulation and decapsulation of VXLAN and NVGRE tunnel
endpoints.

The RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP action will cause the 
matching flow to be encapsulated in the tunnel endpoint overlay
defined in the [vxlan/nvgre]_encap action data.

The RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP action will cause all
headers associated with the outer most tunnel endpoint of the specified
type for the matching flows.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 doc/guides/prog_guide/rte_flow.rst | 107 +++++++++++++++++++++++++++++++++++++
 lib/librte_ether/rte_flow.h        | 105 +++++++++++++++++++++++++++++++++++-
 2 files changed, 211 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2fb8e9c3f..20625c43e 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1592,6 +1592,113 @@ fields in the pattern items.
    | 1     | END      |
    +-------+----------+
 
+Action: ``VXLAN_ENCAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a VXLAN encapsulation action by encapsulating the matched flow in the
+VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow items
+definition.
+
+This action modifies the payload of matched flows. The flow definition specified
+in the ``rte_flow_action_tunnel_encap`` action structure must define a valid
+VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible Local
+Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks
+over Layer 3 Networks). The pattern must be terminated with the
+RTE_FLOW_ITEM_TYPE_END item type.
+
+.. _table_rte_flow_action_vxlan_encap:
+
+.. table:: VXLAN_ENCAP
+
+   +----------------+-------------------------------------+
+   | Field          | Value                               |
+   +================+=====================================+
+   | ``definition`` | Tunnel end-point overlay definition |
+   +----------------+-------------------------------------+
+
+.. _table_rte_flow_action_vxlan_encap_example:
+
+.. table:: IPv4 VxLAN flow pattern example.
+
+   +-------+----------+
+   | Index | Item     |
+   +=======+==========+
+   | 0     | Ethernet |
+   +-------+----------+
+   | 1     | IPv4     |
+   +-------+----------+
+   | 2     | UDP      |
+   +-------+----------+
+   | 3     | VXLAN    |
+   +-------+----------+
+   | 4     | END      |
+   +-------+----------+
+
+Action: ``VXLAN_DECAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a decapsulation action by stripping all headers of the VXLAN tunnel
+network overlay from the matched flow.
+
+The flow items pattern defined for the flow rule with which a ``VXLAN_DECAP``
+action is specified, must define a valid VXLAN tunnel as per RFC7348. If the
+flow pattern does not specify a valid VXLAN tunnel then a 
+RTE_FLOW_ERROR_TYPE_ACTION error should be returned.
+
+This action modifies the payload of matched flows.
+
+Action: ``NVGRE_ENCAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a NVGRE encapsulation action by encapsulating the matched flow in the
+NVGRE tunnel as defined in the``rte_flow_action_tunnel_encap`` flow item
+definition.
+
+This action modifies the payload of matched flows. The flow definition specified
+in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid
+NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network
+Virtualization Using Generic Routing Encapsulation). The pattern must be
+terminated with the RTE_FLOW_ITEM_TYPE_END item type.
+
+.. _table_rte_flow_action_nvgre_encap:
+
+.. table:: NVGRE_ENCAP
+
+   +----------------+-------------------------------------+
+   | Field          | Value                               |
+   +================+=====================================+
+   | ``definition`` | NVGRE end-point overlay definition |
+   +----------------+-------------------------------------+
+   
+.. _table_rte_flow_action_nvgre_encap_example:
+
+.. table:: IPv4 NVGRE flow pattern example.
+
+   +-------+----------+
+   | Index | Item     |
+   +=======+==========+
+   | 0     | Ethernet |
+   +-------+----------+
+   | 1     | IPv4     |
+   +-------+----------+
+   | 2     | NVGRE    |
+   +-------+----------+
+   | 3     | END      |
+   +-------+----------+
+
+Action: ``NVGRE_DECAP``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Performs a decapsulation action by stripping all headers of the NVGRE tunnel
+network overlay from the matched flow.
+
+The flow items pattern defined for the flow rule with which a ``NVGRE_DECAP``
+action is specified, must define a valid NVGRE tunnel as per RFC7637. If the
+flow pattern does not specify a valid NVGRE tunnel then a 
+RTE_FLOW_ERROR_TYPE_ACTION error should be returned.
+
+This action modifies the payload of matched flows.
+
 Negative types
 ~~~~~~~~~~~~~~
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 09a21e531..a51f76e72 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1053,7 +1053,41 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_security.
 	 */
-	RTE_FLOW_ACTION_TYPE_SECURITY
+	RTE_FLOW_ACTION_TYPE_SECURITY,
+
+	/**
+	 * Encapsulate flow in VXLAN tunnel as defined in
+	 * rte_flow_action_vxlan_encap action structure.
+	 *
+	 * See struct rte_flow_action_vxlan_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP,
+
+	/**
+	 * Decapsulate outer most VXLAN tunnel from matched flow.
+	 *
+	 * If flow pattern does not define a valid VXLAN tunnel (as specified by
+	 * RFC7348) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION
+	 * error.
+	 */
+	RTE_FLOW_ACTION_TYPE_VXLAN_DECAP,
+
+	/**
+	 * Encapsulate flow in NVGRE tunnel defined in the
+	 * rte_flow_action_nvgre_encap action structure.
+	 *
+	 * See struct rte_flow_action_nvgre_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP,
+
+	/**
+	 * Decapsulate outer most NVGRE tunnel from matched flow.
+	 *
+	 * If flow pattern does not define a valid NVGRE tunnel (as specified by
+	 * RFC7637) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION
+	 * error.
+	 */
+	RTE_FLOW_ACTION_TYPE_NVGRE_DECAP,
 };
 
 /**
@@ -1230,6 +1264,75 @@ struct rte_flow_action_security {
 	void *security_session; /**< Pointer to security session structure. */
 };
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP
+ *
+ * VXLAN tunnel end-point encapsulation data definition
+ *
+ * The tunnel definition is provided through the flow item pattern, the
+ * provided pattern must conform to RFC7348 for the tunnel specified. The flow
+ * definition must be provided in order from the RTE_FLOW_ITEM_TYPE_ETH
+ * definition up the end item which is specified by RTE_FLOW_ITEM_TYPE_END.
+ *
+ * The mask field allows user to specify which fields in the flow item
+ * definitions can be ignored and which have valid data and can be used
+ * verbatim.
+ *
+ * Note: the last field is not used in the definition of a tunnel and can be
+ * ignored.
+ *
+ * Valid flow definition for RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP include:
+ *
+ * - ETH / IPV4 / UDP / VXLAN / END
+ * - ETH / IPV6 / UDP / VXLAN / END
+ * - ETH / VLAN / IPV4 / UDP / VXLAN / END
+ *
+ */
+struct rte_flow_action_vxlan_encap {
+	/**
+	 * Encapsulating vxlan tunnel definition
+	 * (terminated by the END pattern item).
+	 */
+	struct rte_flow_item *definition;
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP
+ *
+ * NVGRE tunnel end-point encapsulation data definition
+ *
+ * The tunnel definition is provided through the flow item pattern  the
+ * provided pattern must conform with RFC7637. The flow definition must be
+ * provided in order from the RTE_FLOW_ITEM_TYPE_ETH definition up the end item
+ * which is specified by RTE_FLOW_ITEM_TYPE_END.
+ *
+ * The mask field allows user to specify which fields in the flow item
+ * definitions can be ignored and which have valid data and can be used
+ * verbatim.
+ *
+ * Note: the last field is not used in the definition of a tunnel and can be
+ * ignored.
+ *
+ * Valid flow definition for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include:
+ *
+ * - ETH / IPV4 / NVGRE / END
+ * - ETH / VLAN / IPV6 / NVGRE / END
+ *
+ */
+struct rte_flow_action_nvgre_encap {
+	/**
+	 * Encapsulating vxlan tunnel definition
+	 * (terminated by the END pattern item).
+	 */
+	struct rte_flow_item *definition;
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.14.3

[dpdk-dev] [PATCH v5 2/4] ethdev: Add group JUMP action

[Declan Doherty]

Add jump action type which defines an action which allows a matched
flow to be redirect to the specified group. This allows physical and
logical flow table/group hierarchies to be defined through rte_flow.

This breaks ABI compatibility for the following public functions (as it
modifes the ordering of the rte_flow_action_type enumeration):

- rte_flow_copy()
- rte_flow_create()
- rte_flow_query()
- rte_flow_validate()

Add support for specification of new JUMP action to testpmd's flow
cli, and update the testpmd documentation to describe this new
action.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c                 | 23 +++++++++++
 doc/guides/prog_guide/rte_flow.rst          | 61 ++++++++++++++++++++++++-----
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++
 lib/librte_ether/rte_flow.h                 | 41 +++++++++++++++----
 4 files changed, 112 insertions(+), 17 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 32fe6645a..8c570baf4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -161,6 +161,8 @@ enum index {
 	ACTION_END,
 	ACTION_VOID,
 	ACTION_PASSTHRU,
+	ACTION_JUMP,
+	ACTION_JUMP_GROUP,
 	ACTION_MARK,
 	ACTION_MARK_ID,
 	ACTION_FLAG,
@@ -630,6 +632,7 @@ static const enum index next_action[] = {
 	ACTION_END,
 	ACTION_VOID,
 	ACTION_PASSTHRU,
+	ACTION_JUMP,
 	ACTION_MARK,
 	ACTION_FLAG,
 	ACTION_QUEUE,
@@ -694,6 +697,12 @@ static const enum index action_meter[] = {
 	ZERO,
 };
 
+static const enum index action_jump[] = {
+	ACTION_JUMP_GROUP,
+	ACTION_NEXT,
+	ZERO,
+};
+
 static int parse_init(struct context *, const struct token *,
 		      const char *, unsigned int,
 		      void *, unsigned int);
@@ -1593,6 +1602,20 @@ static const struct token token_list[] = {
 		.next = NEXT(NEXT_ENTRY(ACTION_NEXT)),
 		.call = parse_vc,
 	},
+	[ACTION_JUMP] = {
+		.name = "jump",
+		.help = "redirect traffic to a given group",
+		.priv = PRIV_ACTION(JUMP, sizeof(struct rte_flow_action_jump)),
+		.next = NEXT(action_jump),
+		.call = parse_vc,
+	},
+	[ACTION_JUMP_GROUP] = {
+		.name = "group",
+		.help = "group to redirect traffic to",
+		.next = NEXT(action_jump, NEXT_ENTRY(UNSIGNED)),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_action_jump, group)),
+		.call = parse_vc_conf,
+	},
 	[ACTION_MARK] = {
 		.name = "mark",
 		.help = "attach 32 bit value to packets",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 20625c43e..837f30667 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -90,8 +90,12 @@ Thus predictable results for a given priority level can only be achieved
 with non-overlapping rules, using perfect matching on all protocol layers.
 
 Flow rules can also be grouped, the flow rule priority is specific to the
-group they belong to. All flow rules in a given group are thus processed
-either before or after another group.
+group they belong to. All flow rules in a given group are thus processed within
+the context of that group. Groups are not linked by default, so the logical
+hierarchy of groups must be explicitly defined by flow rules themselves in each
+group using the JUMP action to define the next group to redirect too. Only flow
+rules defined in the default group 0 are guarantee to be matched against, this
+makes group 0 the origin of any group hierarchy defined by an application. 
 
 Support for multiple actions per rule may be implemented internally on top
 of non-default hardware priorities, as a result both features may not be
@@ -138,29 +142,34 @@ Attributes
 Attribute: Group
 ^^^^^^^^^^^^^^^^
 
-Flow rules can be grouped by assigning them a common group number. Lower
-values have higher priority. Group 0 has the highest priority.
+Flow rules can be grouped by assigning them a common group number. Groups
+allow a logical hierarchy of flow rule groups (tables) to be defined. These
+groups can be supported virtually in the PMD or in the physical device. 
+Group 0 is the default group and this is the only group which flows are
+guarantee to matched against, all subsequent groups can only be reached by
+way of the JUMP action from a matched flow rule.
 
 Although optional, applications are encouraged to group similar rules as
 much as possible to fully take advantage of hardware capabilities
 (e.g. optimized matching) and work around limitations (e.g. a single pattern
-type possibly allowed in a given group).
+type possibly allowed in a given group), while being aware that the groups
+hierarchies must be programmed explicitly.
 
 Note that support for more than a single group is not guaranteed.
 
 Attribute: Priority
 ^^^^^^^^^^^^^^^^^^^
 
-A priority level can be assigned to a flow rule. Like groups, lower values
+A priority level can be assigned to a flow rule, lower values
 denote higher priority, with 0 as the maximum.
 
-A rule with priority 0 in group 8 is always matched after a rule with
-priority 8 in group 0.
-
-Group and priority levels are arbitrary and up to the application, they do
+Priority levels are arbitrary and up to the application, they do
 not need to be contiguous nor start from 0, however the maximum number
 varies between devices and may be affected by existing flow rules.
 
+A flow which matches multiple rules in the same group will always matched by
+the rule with the highest priority in that group.
+
 If a packet is matched by several rules of a given group for a given
 priority level, the outcome is undefined. It can take any path, may be
 duplicated or even cause unrecoverable errors.
@@ -1248,6 +1257,38 @@ flow rules:
    | 2     | END                        |
    +-------+----------------------------+
 
+Action: ``JUMP``
+^^^^^^^^^^^^^^^^
+
+Redirects packets to a group on the current device.
+
+In a hierarchy of groups, which can be used to represent physical or logical
+flow group/tables on the device, this action redirects the matched flow to
+the specified group on that device.
+
+If a matched flow is redirected to a table which doesn't contain a matching
+rule for that flow then the behavior is undefined and the resulting behavior
+is up to the specific device. Best practice when using groups would be define
+a default flow rule for each group which a defines the default actions in that
+group so a consistent behavior is defined.
+
+Defining an action for matched flow in a group to jump to a group which is
+higher in the group hierarchy may not be supported by physical devices, 
+depending on how groups are mapped to the physical devices. In the 
+definitions of jump actions, applications should be aware that it may be
+possible to define flow rules which trigger an undefined behavior causing
+flows to loop between groups.
+
+.. _table_rte_flow_action_jump:
+
+.. table:: JUMP
+
+   +-----------+------------------------------+
+   | Field     | Value                        |
+   +===========+==============================+
+   | ``group`` | Group to redirect packets to |
+   +-----------+------------------------------+
+
 Action: ``MARK``
 ^^^^^^^^^^^^^^^^
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index bfb5ad027..eec3cee4e 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3387,6 +3387,10 @@ This section lists supported actions and their attributes, if any.
 
 - ``passthru``: let subsequent rule process matched packets.
 
+- ``jump``: redirect traffic to group on device.
+
+  - ``group {unsigned}``: group to redirect to.
+
 - ``mark``: attach 32 bit value to packets.
 
   - ``id {unsigned}``: 32 bit value to return with packets.
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index a51f76e72..0372bd49f 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -35,18 +35,20 @@ extern "C" {
 /**
  * Flow rule attributes.
  *
- * Priorities are set on two levels: per group and per rule within groups.
+ * Priorities are set on a per rule based within groups.
  *
- * Lower values denote higher priority, the highest priority for both levels
- * is 0, so that a rule with priority 0 in group 8 is always matched after a
- * rule with priority 8 in group 0.
+ * Lower values denote higher priority, the highest priority for a flow rule
+ * is 0, so that a flow that matches for than one rule, the rule with the
+ * lowest priority value will always be matched.
  *
  * Although optional, applications are encouraged to group similar rules as
  * much as possible to fully take advantage of hardware capabilities
  * (e.g. optimized matching) and work around limitations (e.g. a single
- * pattern type possibly allowed in a given group).
+ * pattern type possibly allowed in a given group). Applications should be
+ * aware that groups are not linked by default, and that they must be explictly
+ * linked by the application using the JUMP action.
  *
- * Group and priority levels are arbitrary and up to the application, they
+ * Priority levels are arbitrary and up to the application, they
  * do not need to be contiguous nor start from 0, however the maximum number
  * varies between devices and may be affected by existing flow rules.
  *
@@ -69,7 +71,7 @@ extern "C" {
  */
 struct rte_flow_attr {
 	uint32_t group; /**< Priority group. */
-	uint32_t priority; /**< Priority level within group. */
+	uint32_t priority; /**< Rule priority level within group. */
 	uint32_t ingress:1; /**< Rule applies to ingress traffic. */
 	uint32_t egress:1; /**< Rule applies to egress traffic. */
 	/**
@@ -957,6 +959,15 @@ enum rte_flow_action_type {
 	 */
 	RTE_FLOW_ACTION_TYPE_PASSTHRU,
 
+	/**
+	 * RTE_FLOW_ACTION_TYPE_JUMP
+	 *
+	 * Redirects packets to a group on the current device.
+	 *
+	 * See struct rte_flow_action_jump.
+	 */
+	RTE_FLOW_ACTION_TYPE_JUMP,
+
 	/**
 	 * Attaches an integer value to packets and sets PKT_RX_FDIR and
 	 * PKT_RX_FDIR_ID mbuf flags.
@@ -1104,6 +1115,22 @@ struct rte_flow_action_mark {
 	uint32_t id; /**< Integer value to return with packets. */
 };
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_JUMP
+ *
+ * Redirects packets to a group on the current device.
+ *
+ * In a hierarchy of groups, which can be used to represent physical or logical
+ * flow tables on the device, this action allows the action to be a redirect to
+ * a group on that device.
+ */
+struct rte_flow_action_jump {
+	uint32_t group;
+};
+
 /**
  * RTE_FLOW_ACTION_TYPE_QUEUE
  *
-- 
2.14.3

[dpdk-dev] [PATCH v5 3/4] ethdev: add mark flow item to rte_flow_item_types

[Declan Doherty]

Introduces a new action type RTE_FLOW_ITEM_TYPE_MARK which enables
flow patterns to specify arbitrary integer values to match aginst
set by the RTE_FLOW_ACTION_TYPE_MARK action in previously matched
flows.

Add support for specification of new MARK flow item in testpmd's cli.
Update testpmd documentation to describe new MARK flow item support.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c                 | 22 +++++++++++++++++++++
 doc/guides/prog_guide/rte_flow.rst          | 30 +++++++++++++++++++++++++++++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++++
 lib/librte_ether/rte_flow.h                 | 29 ++++++++++++++++++++++++++++
 4 files changed, 85 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 8c570baf4..61af77aeb 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -91,6 +91,8 @@ enum index {
 	ITEM_PHY_PORT_INDEX,
 	ITEM_PORT_ID,
 	ITEM_PORT_ID_ID,
+	ITEM_MARK,
+	ITEM_MARK_ID,
 	ITEM_RAW,
 	ITEM_RAW_RELATIVE,
 	ITEM_RAW_SEARCH,
@@ -453,6 +455,7 @@ static const enum index next_item[] = {
 	ITEM_VF,
 	ITEM_PHY_PORT,
 	ITEM_PORT_ID,
+	ITEM_MARK,
 	ITEM_RAW,
 	ITEM_ETH,
 	ITEM_VLAN,
@@ -505,6 +508,12 @@ static const enum index item_port_id[] = {
 	ZERO,
 };
 
+static const enum index item_mark[] = {
+	ITEM_MARK_ID,
+	ITEM_NEXT,
+	ZERO,
+};
+
 static const enum index item_raw[] = {
 	ITEM_RAW_RELATIVE,
 	ITEM_RAW_SEARCH,
@@ -1127,6 +1136,19 @@ static const struct token token_list[] = {
 		.next = NEXT(item_port_id, NEXT_ENTRY(UNSIGNED), item_param),
 		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_port_id, id)),
 	},
+	[ITEM_MARK] = {
+		.name = "mark",
+		.help = "match traffic against value set in previously matched rule",
+		.priv = PRIV_ITEM(MARK, sizeof(struct rte_flow_item_mark)),
+		.next = NEXT(item_mark),
+		.call = parse_vc,
+	},
+	[ITEM_MARK_ID] = {
+		.name = "id",
+		.help = "Integer value to match against",
+		.next = NEXT(item_mark, NEXT_ENTRY(UNSIGNED), item_param),
+		.args = ARGS(ARGS_ENTRY(struct rte_flow_item_mark, id)),
+	},
 	[ITEM_RAW] = {
 		.name = "raw",
 		.help = "match an arbitrary byte string",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 837f30667..c8a79f59f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -656,6 +656,36 @@ representor" depending on the kind of underlying device).
    | ``mask`` | ``id``   | zeroed to match any port ID |
    +----------+----------+-----------------------------+
 
+Item: ``MARK``
+^^^^^^^^^^^^^^
+
+Matches an arbitrary integer value which was set using the ``MARK`` action in
+a previously matched rule.
+
+This item can only specified once as a match criteria as the ``MARK`` action can
+only be specified once in a flow action.
+
+Note the value of MARK field is arbitrary and application defined.
+
+Depending on the underlying implementation the MARK item may be supported on
+the physical device, with virtual groups in the PMD or not at all.
+ 
+- Default ``mask`` matches any integer value.
+
+.. _table_rte_flow_item_mark:
+
+.. table:: MARK
+
+   +----------+----------+---------------------------+
+   | Field    | Subfield | Value                     |
+   +==========+==========+===========================+
+   | ``spec`` | ``id``   | integer value             |
+   +----------+--------------------------------------+
+   | ``last`` | ``id``   | upper range value         |
+   +----------+----------+---------------------------+
+   | ``mask`` | ``id``   | zeroed to match any value |
+   +----------+------- --+---------------------------+
+
 Data matching item types
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index eec3cee4e..c6f321334 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3215,6 +3215,10 @@ This section lists supported pattern items and their attributes, if any.
 - ``port_id``: match traffic from/to a given DPDK port ID.
 
   - ``id {unsigned}``: DPDK port ID.
+  
+- ``mark``: match value set in previously matched flow rule using the mark action.
+
+  - ``id {unsigned}``: arbitrary integer value.
 
 - ``raw``: match an arbitrary byte string.
 
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 0372bd49f..cd2d56d51 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -341,6 +341,13 @@ enum rte_flow_item_type {
 	 * See struct rte_flow_item_geneve.
 	 */
 	RTE_FLOW_ITEM_TYPE_GENEVE,
+
+	/**
+	 * Matches specified mark field.
+	 *
+	 * See struct rte_flow_item_mark.
+	 */
+	RTE_FLOW_ITEM_TYPE_MARK,
 };
 
 /**
@@ -869,6 +876,28 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = {
 };
 #endif
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_MARK
+ *
+ * Matches an arbitrary integer value which was set using the ``MARK`` action
+ * in a previously matched rule.
+ *
+ * This item can only be specified once as a match criteria as the ``MARK``
+ * action can only be specified once in a flow action.
+ *
+ * This value is arbitrary and application-defined. Maximum allowed value
+ * depends on the underlying implementation.
+ *
+ * Depending on the underlying implementation the MARK item may be supported on
+ * the physical device, with virtual groups in the PMD or not at all.
+ */
+struct rte_flow_item_mark {
+	uint32_t id; /**< Integer value to match against. */
+};
+
 /**
  * Matching pattern item definition.
  *
-- 
2.14.3

[dpdk-dev] [PATCH v5 4/4] ethdev: add shared counter support to rte_flow

[Declan Doherty]

Add rte_flow_action_count action data structure to enable shared
counters across multiple flows on a single port or across multiple
flows on multiple ports within the same switch domain. Also this enables
multiple count actions to be specified in a single flow action.

This patch also modifies the existing rte_flow_query API to take the
rte_flow_action structure as an input parameter instead of the
rte_flow_action_type enumeration to allow querying a specific action
from a flow rule when multiple actions of the same type are specified.

This patch also contains updates for the failsafe PMD and
testpmd application which are affected by this API change.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/test-pmd/cmdline_flow.c          |  6 ++--
 app/test-pmd/config.c                | 15 ++++-----
 app/test-pmd/testpmd.h               |  2 +-
 doc/guides/prog_guide/rte_flow.rst   | 59 ++++++++++++++++++++++--------------
 drivers/net/failsafe/failsafe_flow.c |  4 +--
 lib/librte_ether/rte_flow.c          |  2 +-
 lib/librte_ether/rte_flow.h          | 38 +++++++++++++++++++++--
 lib/librte_ether/rte_flow_driver.h   |  2 +-
 8 files changed, 88 insertions(+), 40 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 61af77aeb..f8a1b5d72 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -379,7 +379,7 @@ struct buffer {
 		} destroy; /**< Destroy arguments. */
 		struct {
 			uint32_t rule;
-			enum rte_flow_action_type action;
+			struct rte_flow_action action;
 		} query; /**< Query arguments. */
 		struct {
 			uint32_t *group;
@@ -939,7 +939,7 @@ static const struct token token_list[] = {
 		.next = NEXT(NEXT_ENTRY(QUERY_ACTION),
 			     NEXT_ENTRY(RULE_ID),
 			     NEXT_ENTRY(PORT_ID)),
-		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action),
+		.args = ARGS(ARGS_ENTRY(struct buffer, args.query.action.type),
 			     ARGS_ENTRY(struct buffer, args.query.rule),
 			     ARGS_ENTRY(struct buffer, port)),
 		.call = parse_query,
@@ -3346,7 +3346,7 @@ cmd_flow_parsed(const struct buffer *in)
 		break;
 	case QUERY:
 		port_flow_query(in->port, in->args.query.rule,
-				in->args.query.action);
+				&in->args.query.action);
 		break;
 	case LIST:
 		port_flow_list(in->port, in->args.list.group_n,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index e7026011b..fefd943e4 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1405,7 +1405,7 @@ port_flow_flush(portid_t port_id)
 /** Query a flow rule. */
 int
 port_flow_query(portid_t port_id, uint32_t rule,
-		enum rte_flow_action_type action)
+		const struct rte_flow_action *action)
 {
 	struct rte_flow_error error;
 	struct rte_port *port;
@@ -1427,15 +1427,16 @@ port_flow_query(portid_t port_id, uint32_t rule,
 		return -ENOENT;
 	}
 	if ((unsigned int)action >= RTE_DIM(flow_action) ||
-	    !flow_action[action].name)
+	    !flow_action[action->type].name)
 		name = "unknown";
 	else
-		name = flow_action[action].name;
-	switch (action) {
+		name = flow_action[action->type].name;
+	switch (action->type) {
 	case RTE_FLOW_ACTION_TYPE_COUNT:
 		break;
 	default:
-		printf("Cannot query action type %d (%s)\n", action, name);
+		printf("Cannot query action type %d (%s)\n",
+			action->type, name);
 		return -ENOTSUP;
 	}
 	/* Poisoning to make sure PMDs update it in case of error. */
@@ -1443,7 +1444,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
 	memset(&query, 0, sizeof(query));
 	if (rte_flow_query(port_id, pf->flow, action, &query, &error))
 		return port_flow_complain(&error);
-	switch (action) {
+	switch (action->type) {
 	case RTE_FLOW_ACTION_TYPE_COUNT:
 		printf("%s:\n"
 		       " hits_set: %u\n"
@@ -1458,7 +1459,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
 		break;
 	default:
 		printf("Cannot display result for action type %d (%s)\n",
-		       action, name);
+		       action->type, name);
 		break;
 	}
 	return 0;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 070919822..a4728380f 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -616,7 +616,7 @@ int port_flow_create(portid_t port_id,
 int port_flow_destroy(portid_t port_id, uint32_t n, const uint32_t *rule);
 int port_flow_flush(portid_t port_id);
 int port_flow_query(portid_t port_id, uint32_t rule,
-		    enum rte_flow_action_type action);
+		    const struct rte_flow_action *action);
 void port_flow_list(portid_t port_id, uint32_t n, const uint32_t *group);
 int port_flow_isolate(portid_t port_id, int set);
 
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index c8a79f59f..e2552fc4c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1153,17 +1153,19 @@ Actions are performed in list order:
 
 .. table:: Mark, count then redirect
 
-   +-------+--------+-----------+-------+
-   | Index | Action | Field     | Value |
-   +=======+========+===========+=======+
-   | 0     | MARK   | ``mark``  | 0x2a  |
-   +-------+--------+-----------+-------+
-   | 1     | COUNT                      |
-   +-------+--------+-----------+-------+
-   | 2     | QUEUE  | ``queue`` | 10    |
-   +-------+--------+-----------+-------+
-   | 3     | END                        |
-   +-------+----------------------------+
+   +-------+--------+------------+-------+
+   | Index | Action | Field      | Value |
+   +=======+========+============+=======+
+   | 0     | MARK   | ``mark``   | 0x2a  |
+   +-------+--------+------------+-------+
+   | 1     | COUNT  | ``shared`` | 0     |
+   |       |        +------------+-------+
+   |       |        | ``id``     | 0     |
+   +-------+--------+------------+-------+
+   | 2     | QUEUE  | ``queue``  | 10    |
+   +-------+--------+------------+-------+
+   | 3     | END                         |
+   +-------+-----------------------------+
 
 |
 
@@ -1392,23 +1394,36 @@ Drop packets.
 Action: ``COUNT``
 ^^^^^^^^^^^^^^^^^
 
-Enables counters for this rule.
+Adds a counter action to a matched flow.
 
-These counters can be retrieved and reset through ``rte_flow_query()``, see
+If more than one count action is specified in a single flow rule, then each
+action must specify a unique id.
+ 
+Counters can be retrieved and reset through ``rte_flow_query()``, see
 ``struct rte_flow_query_count``.
 
-- Counters can be retrieved with ``rte_flow_query()``.
-- No configurable properties.
+The shared flag indicates whether the counter is unique to the flow rule the
+action is specified with, or whether it is a shared counter. 
+
+For a count action with the shared flag set, then then a global device 
+namespace is assumed for the counter id, so that any matched flow rules using
+a count action with the same counter id on the same port will contribute to
+that counter.
+
+For ports within the same switch domain then the counter id namespace extends
+to all ports within that switch domain.
 
 .. _table_rte_flow_action_count:
 
 .. table:: COUNT
 
-   +---------------+
-   | Field         |
-   +===============+
-   | no properties |
-   +---------------+
+   +------------+---------------------+
+   | Field      | Value               |
+   +============+=====================+
+   | ``shared`` | shared counter flag |
+   +------------+---------------------+
+   | ``id``     | counter id          |
+   +------------+---------------------+
 
 Query structure to retrieve and reset flow rule counters:
 
@@ -1965,7 +1980,7 @@ definition.
    int
    rte_flow_query(uint16_t port_id,
                   struct rte_flow *flow,
-                  enum rte_flow_action_type action,
+                  const struct rte_flow_action *action,
                   void *data,
                   struct rte_flow_error *error);
 
@@ -1973,7 +1988,7 @@ Arguments:
 
 - ``port_id``: port identifier of Ethernet device.
 - ``flow``: flow rule handle to query.
-- ``action``: action type to query.
+- ``action``: action to query, this must match prototype from flow rule.
 - ``data``: pointer to storage for the associated query data type.
 - ``error``: perform verbose error reporting if not NULL. PMDs initialize
   this structure in case of error only.
diff --git a/drivers/net/failsafe/failsafe_flow.c b/drivers/net/failsafe/failsafe_flow.c
index a97f4075d..bfe42fcee 100644
--- a/drivers/net/failsafe/failsafe_flow.c
+++ b/drivers/net/failsafe/failsafe_flow.c
@@ -174,7 +174,7 @@ fs_flow_flush(struct rte_eth_dev *dev,
 static int
 fs_flow_query(struct rte_eth_dev *dev,
 	      struct rte_flow *flow,
-	      enum rte_flow_action_type type,
+	      const struct rte_flow_action *action,
 	      void *arg,
 	      struct rte_flow_error *error)
 {
@@ -185,7 +185,7 @@ fs_flow_query(struct rte_eth_dev *dev,
 	if (sdev != NULL) {
 		int ret = rte_flow_query(PORT_ID(sdev),
 					 flow->flows[SUB_ID(sdev)],
-					 type, arg, error);
+					 action, arg, error);
 
 		if ((ret = fs_err(sdev, ret))) {
 			fs_unlock(dev, 0);
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index cecab59f6..aa056175f 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -203,7 +203,7 @@ rte_flow_flush(uint16_t port_id,
 int
 rte_flow_query(uint16_t port_id,
 	       struct rte_flow *flow,
-	       enum rte_flow_action_type action,
+	       const struct rte_flow_action *action,
 	       void *data,
 	       struct rte_flow_error *error)
 {
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index cd2d56d51..548d892de 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1035,7 +1035,7 @@ enum rte_flow_action_type {
 	 * These counters can be retrieved and reset through rte_flow_query(),
 	 * see struct rte_flow_query_count.
 	 *
-	 * No associated configuration structure.
+	 * See struct rte_flow_action_count.
 	 */
 	RTE_FLOW_ACTION_TYPE_COUNT,
 
@@ -1169,6 +1169,38 @@ struct rte_flow_action_queue {
 	uint16_t index; /**< Queue index to use. */
 };
 
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_COUNT
+ *
+ * Adds a counter action to a matched flow.
+ *
+ * If more than one count action is specified in a single flow rule, then each
+ * action must specify a unique id.
+ *
+ * Counters can be retrieved and reset through ``rte_flow_query()``, see
+ * ``struct rte_flow_query_count``.
+ *
+ * The shared flag indicates whether the counter is unique to the flow rule the
+ * action is specified with, or whether it is a shared counter.
+ *
+ * For a count action with the shared flag set, then then a global device
+ * namespace is assumed for the counter id, so that any matched flow rules using
+ * a count action with the same counter id on the same port will contribute to
+ * that counter.
+ *
+ * For ports within the same switch domain then the counter id namespace extends
+ * to all ports within that switch domain.
+ */
+struct rte_flow_action_count {
+	uint32_t shared:1; /**< Share counter ID with other flow rules. */
+	uint32_t reserved:31; /**< Reserved, must be zero. */
+	uint32_t id; /**< Counter ID. */
+};
+
 /**
  * RTE_FLOW_ACTION_TYPE_COUNT (query)
  *
@@ -1597,7 +1629,7 @@ rte_flow_flush(uint16_t port_id,
  * @param flow
  *   Flow rule handle to query.
  * @param action
- *   Action type to query.
+ *   Action definition as defined in original flow rule.
  * @param[in, out] data
  *   Pointer to storage for the associated query data type.
  * @param[out] error
@@ -1610,7 +1642,7 @@ rte_flow_flush(uint16_t port_id,
 int
 rte_flow_query(uint16_t port_id,
 	       struct rte_flow *flow,
-	       enum rte_flow_action_type action,
+	       const struct rte_flow_action *action,
 	       void *data,
 	       struct rte_flow_error *error);
 
diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
index 3800310ba..1c90c600d 100644
--- a/lib/librte_ether/rte_flow_driver.h
+++ b/lib/librte_ether/rte_flow_driver.h
@@ -88,7 +88,7 @@ struct rte_flow_ops {
 	int (*query)
 		(struct rte_eth_dev *,
 		 struct rte_flow *,
-		 enum rte_flow_action_type,
+		 const struct rte_flow_action *,
 		 void *,
 		 struct rte_flow_error *);
 	/** See rte_flow_isolate(). */
-- 
2.14.3

Re: [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap

[Thomas Monjalon]

Hi,

> Declan Doherty (4):
>   ethdev: Add tunnel encap/decap actions
>   ethdev: Add group JUMP action
>   ethdev: add mark flow item to rte_flow_item_types
>   ethdev: add shared counter support to rte_flow

No specific comment.

It is only an API without any PMD implementation.
Which PMDs are planned to be supported? When?

Next time, we could require to have at least one implementation,
when submitting a new API.

The feature is described with rte_flow.
Adrien is the expert to review it, and he already said it was almost good.
Considering how we are late for RC1, the patches could be merged without
the final review/ack if lack of time.

Re: [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap

[Thomas Monjalon]

24/04/2018 18:26, Thomas Monjalon:
> Hi,
> 
> > Declan Doherty (4):
> >   ethdev: Add tunnel encap/decap actions
> >   ethdev: Add group JUMP action
> >   ethdev: add mark flow item to rte_flow_item_types
> >   ethdev: add shared counter support to rte_flow
> 
> No specific comment.
> 
> It is only an API without any PMD implementation.
> Which PMDs are planned to be supported? When?
> 
> Next time, we could require to have at least one implementation,
> when submitting a new API.

One more comment: there is no testpmd usage of this API.

Please Declan, could you fix testpmd by adding new commands
using this new flow encapsulation feature?
We need it in 18.05 in order to avoid having some orphan code.

Thanks

Re: [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap

[Ferruh Yigit]

On 4/23/2018 4:56 PM, Declan Doherty wrote:
> This patchset contains the revised proposal to manage 
> tunnel endpoints hardware accleration based on community
> feedback on RFC
> (http://dpdk.org/ml/archives/dev/2017-December/084676.html). This
> 
> proposal is purely enabled through rte_flow APIs with the
> additions of some new features which were previously implemented
> by the proposed rte_tep APIs which were proposed in the original
> RFC. This patchset ultimately aims to enable the configuration
> of inline data path encapsulation and decapsulation of tunnel
> endpoint network overlays on accelerated IO devices.
> 
> V2:
> Split new functions into separate patches, and add additional
> documentaiton.
> 
> V3:
> Extended the description of group counter in documentation.
> Renamed VTEP to TUNNEL.
> Fixed C99 syntax.
> 
> V4:
> - Modify encap/decap actions to be protocol specific
> - rename group action type to jump
> - add mark flow item type in place of metadata flow/action types
> - add count action data structure
> - modify query API to accept rte_flow_action structure in place of
>   rte_flow_actio_type enumeration to support specification and
>   querying of multiple actions of the same type
> 
> V5:
> - Documentation and comment updates
> - Mark new API structures as experimental
> - squash new function testpmd enablement into relevant patches.
> 
> The summary of the additions to the rte_flow are as follows:
> 
> - Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP and
> RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP to rte_flow to support
> specfication of encapsulation and decapsulation of VXLAN and NVGRE
> tunnels in hardware.
> 
> - Introduces support for the use of pipeline metadata in
> the flow pattern definition and the population of metadata fields
> from flow actions using the MARK flow and action items.
> 
> - Add shared flag to counters to enable statistics to be kept on
> groups offlows such as all ingress/egress flows of a tunnel
> 
> - Adds jump_action to allow a flows to be redirected to a group
> within the device.
> 
> 
> A high level summary of the proposed usage model is as follows:
> 
> 1. Decapsulation
> 
> 1.1. Decapsulation of tunnel outer headers and forward all traffic
>      to the same queue/s or port, would have the follow flows
>      paramteters, sudo code used here.
> 
> struct rte_flow_attr attr = { .ingress = 1 };
> 
> struct rte_flow_item pattern[] = {
> 	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_END }
> };
> 
> struct rte_flow_action actions[] = {
> 	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP },
> 	{ .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action  },
> 	{ .type = RTE_FLOW_ACTION_TYPE_END }
> }
> 
> 
> 1.2.
> 
> Decapsulation of tunnel outer headers and matching on inner
> headers, and forwarding to the same queue/s or port.
> 
> 1.2.1.
> 
> The same scenario as above but either the application
> or hardware requires configuration as 2 logically independent
> operations (viewing it as 2 logical tables). The first stage
> being the flow rule to define the pattern to match the tunnel
> and the action to decapsulate the packet, and the second stage
> stage table matches the inner header and defines the actions,
> forward to port etc.
> 
> flow rule for outer header on table 0
> 
> struct rte_flow_attr attr = { .ingress = 1, .table = 0 };
> 
> struct rte_flow_item pattern[] = {
> 	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_END }
> };
> 
> struct rte_flow_item_count shared_couter = {
> 	.shared = 1,
> 	.id = {counter_id}
> }
> 
> struct rte_flow_action actions[] = {
> 	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &shared_counter },
> 	{ .type = RTE_FLOW_ACTION_TYPE_MARK, .conf = &mark_action },
> 	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP },
> 
> 	{
> 	  .type = RTE_FLOW_ACTION_TYPE_JUMP,
> 	  .conf = { .group = 1 }
> 	},
> 	{ .type = RTE_FLOW_ACTION_TYPE_END }
> }
> 
> flow rule for inner header on table 1
> 
> struct rte_flow_attr attr = { .ingress = 1, .group = 1 };
> 
> struct rte_flow_item_mark mark_item = { id = {mark_id} };
> 
> struct rte_flow_item pattern[] = {
> 	{ .type = RTE_FLOW_ITEM_TYPE_MARK,  .spec = &mark_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_END }
> };
> 
> struct rte_flow_action actions[] = {
> 	{
> 	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
> 	  .conf = &port_id_action = { port_id }
> 	},
> 	{ .type = RTE_FLOW_ACTION_TYPE_END }
> }
> 
> Note that the mark action in the flow rule in group 0 is generating
> the value in the pipeline which is then used in as part as the flow
> pattern in group 1 to specify the exact flow to match against. In the
> case where exact match rules are being provided by the application
> explicitly then the MARK item value can be provided by the application
> in the flow pattern for the flow rule in group 1 also. 
> 
> 2. Encapsulation
> 
> Encapsulation of all traffic matching a specific flow pattern to a
> specified tunnel and egressing to a particular port.
> 
> struct rte_flow_attr attr = { .egress = 1 };
> 
> struct rte_flow_item pattern[] = {
> 	{ .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &eth_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item },
> 	{ .type = RTE_FLOW_ITEM_TYPE_END }
> };
> 
> struct rte_flow_action_tunnel_encap vxlan_encap_action = {
> 	.definition = {
> 		{ .type=eth, .spec={}, .mask={} },
> 		{ .type=ipv4, .spec={}, .mask={} },
> 		{ .type=udp, .spec={}, .mask={} },
> 		{ .type=vxlan, .spec={}, .mask={} }
> 		{ .type=end }
> 	}
> };
> 
> struct rte_flow_action actions[] = {
> 	{ .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &count } },
> 	{ .type = RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, .conf = &vxlan_encap_action } },
> 	{
> 	  .type = RTE_FLOW_ACTION_TYPE_PORT_ID,
> 	  .conf = &port_id_action = { port_id }
> 	},
> 	{ .type = RTE_FLOW_ACTION_TYPE_END }
> 
> };
> 
> Declan Doherty (4):
>   ethdev: Add tunnel encap/decap actions
>   ethdev: Add group JUMP action
>   ethdev: add mark flow item to rte_flow_item_types
>   ethdev: add shared counter support to rte_flow

Hi Declan,

Can you please rebase this set on latest next-net, updates done to
rte_flow_query() in this set causing build errors in bonding rte_flow, that
needs to be updated as well.

Also rte_flow.rst is giving build warnings, can you please check document build?

Thanks,
ferruh