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

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

[Declan Doherty]

This patchset contains the revised proposal to manage virtual
tunnel endpoints (vTEP) 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.

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

- Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_VTEP_ENCAP and
RTE_FLOW_ACTION_TYPE_VTEP_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 defintion 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 vTEP

- 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 vTEP 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_VTEP_DECAP, .type = VxLAN },
	{ .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action  },
	{ .type = RTE_FLOW_ACTION_TYPE_END }
}

1.2.

Decapsulation of vTEP 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 vTEP
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 = &vtep_counter },
	{ .type = RTE_FLOW_ACTION_TYPE_METADATA, .conf = &metadata_action },
	{ .type = RTE_FLOW_ACTION_TYPE_VTEP_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
explictly 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 vTEP 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_vtep_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_VTEP_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 vTEP 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      | 218 +++++++++++++++++++++++++++++++-
 lib/librte_ether/rte_ethdev_version.map |   8 ++
 lib/librte_ether/rte_flow.c             |  21 +++
 lib/librte_ether/rte_flow.h             | 192 +++++++++++++++++++++++++++-
 lib/librte_ether/rte_flow_driver.h      |   6 +
 5 files changed, 439 insertions(+), 6 deletions(-)

-- 
2.14.3

[dpdk-dev] [PATCH v2 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      | 33 +++++++++++++++++++
 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, 123 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 961943dda..468af51b2 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1698,6 +1698,39 @@ 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. 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 34df6c8b5..cff6807fc 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 38f2d27be..e10b1d082 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 13e420218..7d1f89d9e 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
 };
 
 /**
@@ -1148,6 +1160,18 @@ struct rte_flow_action_security {
 	void *security_session; /**< Pointer to security session structure. */
 };
 
+/**
+ * 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.
  *
@@ -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 7778c8e0f..ef09465cf 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.14.3

[dpdk-dev] [PATCH v2 2/4] ethdev: Add vTEP 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_VTEP_ENCAP action will cause the matching
flow to be encapsulated in the virtual tunnel endpoint overlay
defined in the vtep_encap action data.

The RTE_FLOW_ACTION_TYPE_VTEP_DECAP action will cause all virtual tunnel
endpoint overlays up to and including the first instance of the flow
item type defined in the vtep_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        | 60 +++++++++++++++++++++++++++--
 2 files changed, 131 insertions(+), 6 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 468af51b2..ba7baf2e4 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, VTEP_ENCAP, VTEP_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: ``VTEP_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_vtep_encap`` pattern items.
+
+This action modifies the payload of matched flows. The pattern items specified
+in the ``rte_flow_action_vtep_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_vtep_encap:
+
+.. table:: VTEP_ENCAP
+
+   +-------------+---------------------------------------------+
+   | Field       | Value                                       |
+   +=============+=============================================+
+   | ``pattern`` | Virtual tunnel end-point pattern definition |
+   +-------------+---------------------------------------------+
+
+
+.. _table_rte_flow_action_vtep_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: ``VTEP_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_vtep_decap`` action structure must defined a valid
+set of overlay header type.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_vtep_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 7d1f89d9e..4061a9cd4 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,
+ *   VTEP_ENCAP, VTEP_DECAP).
+ *
  * - Other non terminating meta actions that do not affect the fate of
  *   packets (END, VOID, MARK, FLAG, COUNT).
  *
@@ -1022,7 +1029,21 @@ 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 in defined vTEP defined in
+	 * rte_flow_action_vtep_encap structure.
+	 *
+	 * See struct rte_flow_action_vtep_encap.
+	 */
+	RTE_FLOW_ACTION_TYPE_VTEP_ENCAP,
+
+	/**
+	 * Decapsulate all the headers of the vTEP
+	 *
+	 * See struct rte_flow_action_vtep_decap.
+	 */
+	RTE_FLOW_ACTION_TYPE_VTEP_DECAP
 };
 
 /**
@@ -1172,6 +1193,39 @@ struct rte_flow_action_group_count {
 	uint32_t id;
 };
 
+/**
+ * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
+ *
+ * Virtual tunnel end-point encapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_encap {
+	struct rte_flow_action_item {
+		enum rte_flow_item_type type;
+		/**< Flow item type. */
+		const void *item;
+		/**< Flow item definition. */
+	} *pattern;
+	/**<
+	 * vTEP pattern specification (list terminated by the END pattern item).
+	 */
+};
+
+/**
+ * RTE_FLOW_ACTION_TYP_VTEP_DECAP
+ *
+ * Virtual tunnel end-point decapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_decap {
+	enum rte_flow_item_type type;
+	/**<
+	 * Flow item type of virtual tunnel end-point to be decapsulated
+	 */
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.14.3

[dpdk-dev] [PATCH v2 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        | 28 +++++++++++++++++++++++++++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index ba7baf2e4..362231829 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 4061a9cd4..55951b6ca 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1043,7 +1043,18 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_vtep_decap.
 	 */
-	RTE_FLOW_ACTION_TYPE_VTEP_DECAP
+	RTE_FLOW_ACTION_TYPE_VTEP_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
 };
 
 /**
@@ -1226,6 +1237,21 @@ struct rte_flow_action_vtep_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.
  *
-- 
2.14.3

[dpdk-dev] [PATCH v2 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        | 54 +++++++++++++++++++++++-
 2 files changed, 138 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 362231829..48e84b374 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 55951b6ca..be1b0348b 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
 };
 
 /**
@@ -814,6 +821,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.
  *
@@ -1054,7 +1072,17 @@ enum rte_flow_action_type {
 	 *
 	 * See struct rte_flow_action_group.
 	 */
-	RTE_FLOW_ACTION_TYPE_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
 };
 
 /**
@@ -1252,6 +1280,30 @@ struct rte_flow_action_group {
 	uint32_t id;
 };
 
+/**
+ * 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.
  *
-- 
2.14.3

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

[Thomas Monjalon]

05/04/2018 15:51, Declan Doherty:
> +Group Count Query
> +~~~~~~~~~~~~~~~~~
> +
> +Query group counter which can be associated with multiple flows on a specified
> +port.
> +
> +This function allows retrieving of group counters. Data
> +is gathered by special actions which must be present in the flow rule
> +definition.

I would like seeing an explanation of how group counter work.
The guide can be more verbose than the doxygen comments.

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

[Thomas Monjalon]

05/04/2018 15:51, Declan Doherty:
> +/**
> + * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
> + *
> + * Virtual tunnel end-point encapsulation action data.
> + *
> + * Non-terminating action by default.
> + */
> +struct rte_flow_action_vtep_encap {
> +	struct rte_flow_action_item {
> +		enum rte_flow_item_type type;
> +		/**< Flow item type. */
> +		const void *item;
> +		/**< Flow item definition. */
> +	} *pattern;
> +	/**<
> +	 * vTEP pattern specification (list terminated by the END pattern item).
> +	 */
> +};
> +
> +/**
> + * RTE_FLOW_ACTION_TYP_VTEP_DECAP
> + *
> + * Virtual tunnel end-point decapsulation action data.
> + *
> + * Non-terminating action by default.
> + */
> +struct rte_flow_action_vtep_decap {
> +	enum rte_flow_item_type type;
> +	/**<
> +	 * Flow item type of virtual tunnel end-point to be decapsulated
> +	 */
> +};

Question about the naming:
Why using the terminology VTEP instead of TUNNEL simply?
I probably miss something, but tunnel encap/decap looks simpler to me.

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

[Thomas Monjalon]

05/04/2018 15:51, Declan Doherty:
> +struct rte_flow_item_metadata {
> +       uint32_t id;            /**< field identifier */
> +       uint32_t size;          /**< field size */
> +       uint8_t bytes[];        /**< field value */
> +};

Spotted C99 syntax of flexible array.
Are we OK with all supported compilers?

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

[Adrien Mazarguil]

On Thu, Apr 05, 2018 at 06:49:32PM +0200, Thomas Monjalon wrote:
> 05/04/2018 15:51, Declan Doherty:
> > +struct rte_flow_item_metadata {
> > +       uint32_t id;            /**< field identifier */
> > +       uint32_t size;          /**< field size */
> > +       uint8_t bytes[];        /**< field value */
> > +};
> 
> Spotted C99 syntax of flexible array.
> Are we OK with all supported compilers?

I also thought they were a good idea at first but got rid of them in
rte_flow [1] for the following reasons:

- Not valid/standard C++.
- Can't be statically initialized.

Both can be overcome by relying on compiler extensions, however their use
should be restricted to a minimum in public APIs for portability reasons.

[1] http://dpdk.org/ml/archives/dev/2018-April/095307.html

-- 
Adrien Mazarguil
6WIND

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

[Mohammad Abdul Awal]

On 05/04/2018 17:31, Thomas Monjalon wrote:
> 05/04/2018 15:51, Declan Doherty:
>> +Group Count Query
>> +~~~~~~~~~~~~~~~~~
>> +
>> +Query group counter which can be associated with multiple flows on a specified
>> +port.
>> +
>> +This function allows retrieving of group counters. Data
>> +is gathered by special actions which must be present in the flow rule
>> +definition.
> I would like seeing an explanation of how group counter work.
> The guide can be more verbose than the doxygen comments.
A bit elaborated explanation is as below.

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.

When the tunnel is created, the underlying PMD can keep track of the 
tunnel which is specified as table 0. Then each time a packet is 
received belongs to the tunnel, the counter is increased. During the 
query the counter is returned.

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

[Mohammad Abdul Awal]

On 05/04/2018 17:42, Thomas Monjalon wrote:
> 05/04/2018 15:51, Declan Doherty:
>> +/**
>> + * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
>> + *
>> + * Virtual tunnel end-point encapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_vtep_encap {
>> +	struct rte_flow_action_item {
>> +		enum rte_flow_item_type type;
>> +		/**< Flow item type. */
>> +		const void *item;
>> +		/**< Flow item definition. */
>> +	} *pattern;
>> +	/**<
>> +	 * vTEP pattern specification (list terminated by the END pattern item).
>> +	 */
>> +};
>> +
>> +/**
>> + * RTE_FLOW_ACTION_TYP_VTEP_DECAP
>> + *
>> + * Virtual tunnel end-point decapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_vtep_decap {
>> +	enum rte_flow_item_type type;
>> +	/**<
>> +	 * Flow item type of virtual tunnel end-point to be decapsulated
>> +	 */
>> +};
> Question about the naming:
> Why using the terminology VTEP instead of TUNNEL simply?
> I probably miss something, but tunnel encap/decap looks simpler to me.

Initial thought was that the tunnel terminology may conflict with 
existing tunnel item types and their uses. In previous terminologies, it 
was assumed that to create a tunneled flows, each time a tunnel item has 
to be specified in the patterns.
Now with the endpoint concept, the tunnel endpoint will be created once 
only, in for each subsequent flows created that is supposed to use the 
tunnel, will use the tunnel metadata during the flow creation. Hence 
comes the terminology virtual tunnel endpoint (VTEP). It does not harm 
to use tunnel instead of vtep except the endpoint term is mission. In 
the next patch TUNNEL terminology is used instead of VTEP.

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

[Mohammad Abdul Awal]

On 05/04/2018 17:49, Thomas Monjalon wrote:
> 05/04/2018 15:51, Declan Doherty:
>> +struct rte_flow_item_metadata {
>> +       uint32_t id;            /**< field identifier */
>> +       uint32_t size;          /**< field size */
>> +       uint8_t bytes[];        /**< field value */
>> +};
> Spotted C99 syntax of flexible array.
> Are we OK with all supported compilers?
>
Used "uint8_t *bytes;" instead of "uint8_t bytes[];"

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

[Thomas Monjalon]

06/04/2018 15:47, Mohammad Abdul Awal:
> 
> On 05/04/2018 17:49, Thomas Monjalon wrote:
> > 05/04/2018 15:51, Declan Doherty:
> >> +struct rte_flow_item_metadata {
> >> +       uint32_t id;            /**< field identifier */
> >> +       uint32_t size;          /**< field size */
> >> +       uint8_t bytes[];        /**< field value */
> >> +};
> > Spotted C99 syntax of flexible array.
> > Are we OK with all supported compilers?
> >
> Used "uint8_t *bytes;" instead of "uint8_t bytes[];"

Why this change? It is changing the size of the structure, isn't it?

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

[Mohammad Abdul Awal]

On 06/04/2018 16:57, Thomas Monjalon wrote:
> 06/04/2018 15:47, Mohammad Abdul Awal:
>> On 05/04/2018 17:49, Thomas Monjalon wrote:
>>> 05/04/2018 15:51, Declan Doherty:
>>>> +struct rte_flow_item_metadata {
>>>> +       uint32_t id;            /**< field identifier */
>>>> +       uint32_t size;          /**< field size */
>>>> +       uint8_t bytes[];        /**< field value */
>>>> +};
>>> Spotted C99 syntax of flexible array.
>>> Are we OK with all supported compilers?
>>>
>> Used "uint8_t *bytes;" instead of "uint8_t bytes[];"
> Why this change? It is changing the size of the structure, isn't it?
It does change the size. I also agree with Adrien's comment as he 
mentioned in the previous mail.