[dpdk-dev] [RFC] net/mlx5: support for flow action on VLAN header

[dpdk-dev] [RFC] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

As for today the mlx5 PMD does not support those VLAN actions
using its Direct Verbs interface.
This RFC proposes adding this missing support to the PMD.

Comments are welcome.

[1] https://doc.dpdk.org/guides/prog_guide/rte_flow.html

[2] https://www.opennetworking.org/wp-content/uploads/2014/10/
    openflow-spec-v1.4.0.pdf

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile       |   2 +-
 drivers/net/mlx5/meson.build    |   2 +-
 drivers/net/mlx5/mlx5.c         |   9 ++
 drivers/net/mlx5/mlx5.h         |   1 +
 drivers/net/mlx5/mlx5_flow.h    |  26 +++-
 drivers/net/mlx5/mlx5_flow_dv.c | 263 +++++++++++++++++++++++++++++++++++++++-
 drivers/net/mlx5/mlx5_glue.c    |  27 +++++
 drivers/net/mlx5/mlx5_glue.h    |   2 +
 drivers/net/mlx5/mlx5_prm.h     |   1 +
 9 files changed, 324 insertions(+), 9 deletions(-)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 2694916..4a4225e 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -8,7 +8,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
 LIB = librte_pmd_mlx5.a
 LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION)
 LIB_GLUE_BASE = librte_pmd_mlx5_glue.so
-LIB_GLUE_VERSION = 19.05.0
+LIB_GLUE_VERSION = 19.08.0
 
 # Sources.
 SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5.c
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index ac3b529..f1f97a1 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -4,7 +4,7 @@
 
 pmd_dlopen = (get_option('ibverbs_link') == 'dlopen')
 LIB_GLUE_BASE = 'librte_pmd_mlx5_glue.so'
-LIB_GLUE_VERSION = '19.05.0'
+LIB_GLUE_VERSION = '19.08.0'
 LIB_GLUE = LIB_GLUE_BASE + '.' + LIB_GLUE_VERSION
 if pmd_dlopen
 	dpdk_conf.set('RTE_IBVERBS_LINK_DLOPEN', 1)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 9f5ec97..2000350 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -369,6 +369,7 @@ struct mlx5_dev_spawn_data {
 	}
 	pthread_mutex_init(&sh->dv_mutex, NULL);
 	sh->tx_domain = domain;
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 #ifdef HAVE_MLX5DV_DR_ESWITCH
 	if (priv->config.dv_esw_en) {
 		domain  = mlx5_glue->dr_create_domain
@@ -400,6 +401,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->dr_destroy_domain(sh->fdb_domain);
 		sh->fdb_domain = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	if (sh->esw_drop_action) {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
@@ -439,6 +444,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->dr_destroy_domain(sh->tx_domain);
 		sh->tx_domain = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 #ifdef HAVE_MLX5DV_DR_ESWITCH
 	if (sh->fdb_domain) {
 		mlx5_glue->dr_destroy_domain(sh->fdb_domain);
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 3eaaafd..b9e621d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -297,6 +297,7 @@ struct mlx5_ibv_shared {
 	void *tx_domain; /* TX Direct Rules name space handle. */
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
 	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index b665420..0fdba46 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -125,11 +125,13 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -140,7 +142,13 @@
 				      MLX5_FLOW_ACTION_SET_TTL | \
 				      MLX5_FLOW_ACTION_DEC_TTL | \
 				      MLX5_FLOW_ACTION_SET_MAC_SRC | \
-				      MLX5_FLOW_ACTION_SET_MAC_DST)
+				      MLX5_FLOW_ACTION_SET_MAC_DST | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_PCP)
+
+#define MLX5_FLOW_VLAN_ACTIONS \
+	(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN | \
+	 MLX5_FLOW_ACTION_OF_SET_VLAN_VID | MLX5_FLOW_ACTION_OF_SET_VLAN_PCP)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -258,6 +266,16 @@ struct mlx5_flow_dv_modify_hdr_resource {
 	uint64_t flags; /**< Flags for RDMA API. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action;
+	/**< Direct verbs action object. */
+	uint32_t vlan_hdr; /**< VLAN header value. */
+};
+
 /* Jump action resource structure. */
 struct mlx5_flow_dv_jump_tbl_resource {
 	LIST_ENTRY(mlx5_flow_dv_jump_tbl_resource) next;
@@ -297,6 +315,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to encap/decap resource in cache. */
 	struct mlx5_flow_dv_modify_hdr_resource *modify_hdr;
 	/**< Pointer to modify header resource in cache. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_action;
+	/**< Pointer to push VLAN action resource in cache. */
 	struct ibv_flow *flow; /**< Installed flow. */
 	struct mlx5_flow_dv_jump_tbl_resource *jump;
 	/**< Pointer to the jump action resource. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index cf255ca..b8b4e58 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -49,6 +49,17 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+union flow_dr_vlan_hdr {
+	struct vlan_hdr vhdr;
+	struct {
+	    uint32_t vid:12;
+	    uint32_t dei:1;
+	    uint32_t pcp:3;
+	    uint32_t tpid:16;
+	};
+	uint32_t tag;
+} __attribute__((__packed__));
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -107,6 +118,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan[] = {
+	/* TODO: Fill with correct values */
+	{4,  0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -238,6 +255,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set Modify-VLAN action to DV specification or create
+ * a new VLAN push action.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_modify_vlan
+			(struct mlx5_flow_dv_modify_hdr_resource *res,
+			 const union flow_dr_vlan_hdr *vlan,
+			 const uint64_t action_flags,
+			 const struct rte_flow_item *items,
+			 struct rte_flow_error *error)
+{
+	(void)res;
+	(void)vlan;
+	(void)action_flags;
+	(void)items;
+	return rte_flow_error_set(error, ENOTSUP,
+				  RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+				  "unsupported action");
+}
+
+/**
  * Convert modify-header set IPv4 address action to DV specification.
  *
  * @param[in,out] resource
@@ -819,6 +867,68 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	(void)action_flags;
+	(void)action;
+	(void)attr;
+	return rte_flow_error_set(error, ENOTSUP,
+				  RTE_FLOW_ERROR_TYPE_ACTION, action,
+				  "unsupported action");
+}
+
+/**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	(void)action_flags;
+	(void)action;
+	(void)item_flags;
+	(void)attr;
+	return rte_flow_error_set(error, ENOTSUP,
+				  RTE_FLOW_ERROR_TYPE_ACTION, action,
+				  "unsupported action");
+}
+
+/**
  * Validate the raw encap action.
  *
  * @param[in] action_flags
@@ -1502,6 +1612,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const uint32_t vlan_tag,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	(void)dev;
+	(void)vlan_tag;
+	(void)dev_flow;
+	return rte_flow_error_set(error, ENOTSUP,
+				  RTE_FLOW_ERROR_TYPE_ACTION,
+				  NULL, "unsupported action");
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -1566,6 +1707,34 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the modify-header VLAN actions.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the modify action.
+ * @param[in] item_flags
+ *   Holds the items detected.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_modify_vlan(const uint64_t action_flags,
+				    const struct rte_flow_action *action,
+				    const uint64_t item_flags,
+				    struct rte_flow_error *error)
+{
+	(void)action_flags;
+	(void)action;
+	(void)item_flags;
+	return rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_ACTION,
+				  NULL, "unsupported action");
+}
+
+/**
  * Validate the modify-header IPv4 address actions.
  *
  * @param[in] action_flags
@@ -2277,6 +2446,26 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			ret = flow_dv_validate_action_pop_vlan(action_flags,
+							       actions,
+							       item_flags, attr,
+							       error);
+				return -rte_errno;
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -2336,7 +2525,22 @@ struct field_modify_info modify_tcp[] = {
 						MLX5_FLOW_ACTION_SET_MAC_SRC :
 						MLX5_FLOW_ACTION_SET_MAC_DST;
 			break;
-
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_modify_vlan(action_flags,
+								  actions,
+								  item_flags,
+								  error);
+			if (ret < 0)
+				return ret;
+			/* Count all modify-header actions as one action. */
+			if (!(action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS))
+				++actions_n;
+			action_flags |= actions->type ==
+					RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID ?
+					MLX5_FLOW_ACTION_OF_SET_VLAN_VID :
+					MLX5_FLOW_ACTION_OF_SET_VLAN_PCP;
+			break;
 		case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
 		case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
 			ret = flow_dv_validate_action_modify_ipv4(action_flags,
@@ -3634,6 +3838,7 @@ struct field_modify_info modify_tcp[] = {
 	uint32_t modify_action_position = UINT32_MAX;
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
+	union flow_dr_vlan_hdr vlan;
 
 	flow->group = attr->group;
 	if (attr->transfer)
@@ -3740,6 +3945,37 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (!priv->sh->pop_vlan_action)
+				return rte_flow_error_set
+						(error, ENOTSUP,
+						 RTE_FLOW_ERROR_TYPE_ACTION,
+						 action,
+						 "cannot create pop vlan"
+						  " action.");
+			dev_flow->dv.actions[actions_n++] =
+						    priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			vlan.tpid =
+				((const struct rte_flow_action_of_push_vlan *)
+						      actions->conf)->ethertype;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			vlan.vid =
+			       ((const struct rte_flow_action_of_set_vlan_vid *)
+						       actions->conf)->vlan_vid;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			vlan.pcp =
+			   ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_PCP;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -3886,12 +4122,31 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_END:
 			actions_end = true;
+			/*
+			 * Finally we can handle the VLAN commands.
+			 * If we have a push VLAN action it will handle all
+			 * other VLAN modify-header actions.
+			 */
+			if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN) {
+				action_flags &=
+					~(MLX5_FLOW_ACTION_OF_SET_VLAN_VID |
+					  MLX5_FLOW_ACTION_OF_SET_VLAN_PCP);
+				if (flow_dv_create_action_push_vlan
+					    (dev, vlan.tag, dev_flow, error))
+					return -rte_errno;
+				dev_flow->dv.actions[actions_n++] =
+						dev_flow->dv.push_vlan_action;
+			} else if (action_flags & MLX5_FLOW_VLAN_ACTIONS) {
+				if (flow_dv_create_action_modify_vlan
+						(&res, &vlan,
+						 action_flags, items, error))
+					return -rte_errno;
+			}
 			if (action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS) {
 				/* create modify action if needed. */
 				if (flow_dv_modify_hdr_resource_register
-								(dev, &res,
-								 dev_flow,
-								 error))
+							(dev, &res,
+							 dev_flow, error))
 					return -rte_errno;
 				dev_flow->dv.actions[modify_action_position] =
 					dev_flow->dv.modify_hdr->verbs_action;
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 21cd3bb..66bc66e 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -408,6 +408,29 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(uint32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_create_action_pop_vlan(vlan_tag);
+#else
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_create_action_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -893,6 +916,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index b5c63cb..39bbf00 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -148,6 +148,8 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)(uint32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index 8c42380..d106aff 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -310,6 +310,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

[dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

This series of patches adds support for those VLAN actions
to the mlx5 PMD using the Direct Verbs interface.

Moti Haimovsky (7):
  net/mlx5: support for an action search in a list
  net/mlx5: add VLAN push/pop DR commands to glue
  net/mlx5: support pop flow action on VLAN header
  net/mlx5: support push flow action on VLAN header
  net/mlx5: support modify VLAN priority on VLAN hdr
  net/mlx5: supp modify VLAN ID on new VLAN header
  net/mlx5: supp modify VLAN ID on existing VLAN hdr

 drivers/net/mlx5/Makefile       |   5 +
 drivers/net/mlx5/meson.build    |   2 +
 drivers/net/mlx5/mlx5.c         |   9 +
 drivers/net/mlx5/mlx5.h         |   3 +
 drivers/net/mlx5/mlx5_flow.c    |  23 ++
 drivers/net/mlx5/mlx5_flow.h    |  27 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 521 ++++++++++++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.c    |  29 +++
 drivers/net/mlx5/mlx5_glue.h    |   6 +
 drivers/net/mlx5/mlx5_prm.h     |   1 +
 10 files changed, 623 insertions(+), 3 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH 1/7] net/mlx5: support for an action search in a list

[Moti Haimovsky]

This commit adds a helper routine that supports searching for a
specific action in a list of actions.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 6ae98e1..4cfeecd 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -685,6 +685,29 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 }
 
 /*
+ * return a pointer to the desired action in the list of actions.
+ *
+ * @param[in] actions
+ *   The list of actions to search the action in.
+ * @param[in] action
+ *   The action to find.
+ *
+ * @return
+ *   Pointer to the action in the list, if found. NULL otherwise.
+ */
+const struct rte_flow_action *
+mlx5_flow_find_action(const struct rte_flow_action *actions,
+		      enum rte_flow_action_type action)
+{
+	if (actions == NULL)
+		return NULL;
+	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+		if (actions->type == action)
+			return actions;
+	return NULL;
+}
+
+/*
  * Validate the flag action.
  *
  * @param[in] action_flags
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 822ff36..8d193b6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct mlx5_flow *dev_flow, int tunnel,
 				     uint64_t hash_fields);
 uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 				   uint32_t subpriority);
+const struct rte_flow_action *mlx5_flow_find_action
+					(const struct rte_flow_action *actions,
+					 enum rte_flow_action_type action);
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
 				    const struct rte_flow_attr *attr,
 				    struct rte_flow_error *error);
-- 
1.8.3.1

[dpdk-dev] [PATCH 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Moti Haimovsky]

This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
interface.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile    |  5 +++++
 drivers/net/mlx5/meson.build |  2 ++
 drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.h |  6 ++++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index dbb2a4e..95ce2e2 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -163,6 +163,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
 		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
 		$(AUTOCONF_OUTPUT)
 	$Q sh -- '$<' '$@' \
+		HAVE_MLX5DV_DR_VLAN \
+		infiniband/mlx5dv.h \
+		func mlx5dv_dr_action_create_push_vlan \
+		$(AUTOCONF_OUTPUT)
+	$Q sh -- '$<' '$@' \
 		HAVE_IBV_DEVX_OBJ \
 		infiniband/mlx5dv.h \
 		func mlx5dv_devx_obj_create \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 62b41ca..d5d10fe 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -130,6 +130,8 @@ if build
 		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
 		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
 		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
+		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
+		'mlx5dv_dr_action_create_push_vlan' ],
 		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
 		'SUPPORTED_40000baseKR4_Full' ],
 		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 50c369a..9ee37f4 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -415,6 +415,31 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain *domain,
+					  rte_be32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag);
+#else
+	(void)domain;
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -1016,6 +1041,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index 6b5dadf..82d6b10 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -9,6 +9,8 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include "rte_byteorder.h"
+
 /* Verbs headers do not support -pedantic. */
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
@@ -156,6 +158,10 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)
+					(struct mlx5dv_dr_domain *domain,
+					 rte_be32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
-- 
1.8.3.1

[dpdk-dev] [PATCH 3/7] net/mlx5: support pop flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
direct verbs flow rules.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5.c         |  9 +++++
 drivers/net/mlx5/mlx5.h         |  1 +
 drivers/net/mlx5/mlx5_flow.h    |  5 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 78 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index a3eacdb..4d0ff2d 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -538,6 +538,7 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = mlx5_glue->dr_create_flow_action_drop();
 	}
 #endif
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 	sh->dv_refcnt++;
 	priv->dr_shared = 1;
 	return 0;
@@ -560,6 +561,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	return err;
 #else
 	(void)priv;
@@ -605,6 +610,10 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = NULL;
 	}
 #endif
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	pthread_mutex_destroy(&sh->dv_mutex);
 #else
 	(void)priv;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f559f83..4d457bf 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -570,6 +570,7 @@ struct mlx5_ibv_shared {
 	void *tx_domain; /* TX Direct Rules name space handle. */
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
 	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8d193b6..06b0470 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -154,7 +154,8 @@
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -171,6 +172,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ca7252a..05e9c7b 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -831,6 +831,61 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
+				 uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+
+	(void)action;
+	(void)attr;
+	if (!priv->sh->pop_vlan_action)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "pop vlan action is not supported");
+	/*
+	 * Check for inconsistencies:
+	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
+	 *  fail strip_vlan in a flow that matches packets without explicitly a
+	 *  matching on VLAN tag ?
+	 */
+	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "no support for multiple vlan pop "
+					  "actions");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "cannot pop vlan without a "
+					  "match on (outer) vlan in the flow");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3108,6 +3163,16 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (flow_dv_validate_action_pop_vlan(dev,
+							     action_flags,
+							     actions,
+							     item_flags, attr,
+							     error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -3281,6 +3346,13 @@ struct field_modify_info modify_tcp[] = {
 						  "action not supported");
 		}
 	}
+	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
+	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION,
+					  actions,
+					  "can't have vxlan and vlan"
+					  " actions in the same rule");
 	/* Eswitch has few restrictions on using items and actions */
 	if (attr->transfer) {
 		if (action_flags & MLX5_FLOW_ACTION_FLAG)
@@ -4798,6 +4870,12 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			dev_flow->dv.actions[actions_n++] =
+						priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH 4/7] net/mlx5: support push flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN using
direct verbs flow rules.
If present in the flow, The VLAN default values are taken from the
VLAN item configuration.
In this commit only the VLAN TPID value can be set since VLAN
modification actions are not supported yet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5.h         |   2 +
 drivers/net/mlx5/mlx5_flow.h    |  18 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 264 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 282 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 4d457bf..ae4a7c5 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
 	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
 	LIST_HEAD(port_id_action_list, mlx5_flow_dv_port_id_action_resource)
 		port_id_action_list; /* List of port ID actions. */
+	LIST_HEAD(push_vlan_action_list, mlx5_flow_dv_push_vlan_action_resource)
+		push_vlan_action_list; /* List of push VLAN actions. */
 	struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
 	/* Shared interrupt handler section. */
 	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 06b0470..15c9c04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -150,7 +150,8 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
@@ -172,7 +173,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
-#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
+				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
 	uint32_t port_id; /**< Port ID value. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action; /**< Direct verbs action object. */
+	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
+	rte_be32_t vlan_tag; /**< VLAN tag value. */
+};
+
 /*
  * Max number of actions per DV flow.
  * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
@@ -335,6 +347,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to port ID action resource. */
 	struct mlx5_vf_vlan vf_vlan;
 	/**< Structure for VF VLAN workaround. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
+	/**< Pointer to push VLAN action resource in cache. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
 	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
 	/**< Action list. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 05e9c7b..e81fee2 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -50,6 +50,21 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+/* VLAN header definitions */
+#define FLOW_DV_VLAN_PCP_SHIFT 13
+#define FLOW_DV_VLAN_PCP_MASK RTE_BE16(0x7 << FLOW_DV_VLAN_PCP_SHIFT)
+#define FLOW_DV_VLAN_VID_MASK RTE_BE16(0x0fff)
+
+struct flow_dv_vlan_be {
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+	rte_be16_t tci;
+	rte_be16_t tpid;
+#else
+	rte_be16_t tpid;
+	rte_be16_t tci;
+#endif
+};
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -833,6 +848,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the pop VLAN action.
  *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
  * @param[in] action_flags
  *   Holds the actions detected until now.
  * @param[in] action
@@ -886,6 +903,86 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Get VLAN default info from vlan match info.
+ *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
+ * @param[in] item
+ *   the list of item specifications.
+ * @param[out] vlan
+ *   pointer VLAN info to fill to.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static void
+flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
+				   struct flow_dv_vlan_be *vlan)
+{
+	const struct rte_flow_item_vlan nic_mask = {
+		.tci = RTE_BE16(0x0fff),
+		.inner_type = RTE_BE16(0xffff),
+	};
+
+	if (items == NULL)
+		return;
+	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
+	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
+		;
+	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
+		const struct rte_flow_item_vlan *vlan_m = items->mask;
+		const struct rte_flow_item_vlan *vlan_v = items->spec;
+
+		if (!vlan_m)
+			vlan_m = &nic_mask;
+		if (vlan_m->tci == nic_mask.tci)
+			vlan->tci = vlan_v->tci & vlan_m->tci;
+		if (vlan_m->inner_type == nic_mask.inner_type)
+			vlan->tpid = vlan_v->inner_type & vlan_m->inner_type;
+	}
+}
+
+/**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_push_vlan *push_vlan = action->conf;
+
+	if (push_vlan->ethertype != RTE_BE16(0x8100) &&
+	    push_vlan->ethertype != RTE_BE16(0x88a8))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "invalid vlan ethertype");
+	if (action_flags &
+		(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "no support for multiple VLAN "
+					  "actions");
+	(void)attr;
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -1310,6 +1407,77 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Find existing push vlan resource or create and register a new one.
+ *
+ * @param dev[in, out]
+ *   Pointer to rte_eth_dev structure.
+ * @param[in, out] resource
+ *   Pointer to port ID action resource.
+ * @parm[in, out] dev_flow
+ *   Pointer to the dev_flow.
+ * @param[out] error
+ *   pointer to error structure.
+ *
+ * @return
+ *   0 on success otherwise -errno and errno is set.
+ */
+static int
+flow_dv_push_vlan_action_resource_register
+		       (struct rte_eth_dev *dev,
+			struct mlx5_flow_dv_push_vlan_action_resource *resource,
+			struct mlx5_flow *dev_flow,
+			struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+	struct mlx5_ibv_shared *sh = priv->sh;
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
+	struct mlx5dv_dr_domain *domain;
+
+	/* Lookup a matching resource from cache. */
+	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
+		if (resource->vlan_tag == cache_resource->vlan_tag &&
+		    resource->ft_type == cache_resource->ft_type) {
+			DRV_LOG(DEBUG, "push-VLAN action resource resource %p: "
+				"refcnt %d++",
+				(void *)cache_resource,
+				rte_atomic32_read(&cache_resource->refcnt));
+			rte_atomic32_inc(&cache_resource->refcnt);
+			dev_flow->dv.push_vlan_res = cache_resource;
+			return 0;
+		}
+	}
+	/* Register new push_vlan action resource. */
+	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
+	if (!cache_resource)
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "cannot allocate resource memory");
+	*cache_resource = *resource;
+	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
+		domain = sh->fdb_domain;
+	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
+		domain = sh->rx_domain;
+	else
+		domain = sh->tx_domain;
+	cache_resource->action =
+		mlx5_glue->dr_create_flow_action_push_vlan(domain,
+							   resource->vlan_tag);
+	if (!cache_resource->action) {
+		rte_free(cache_resource);
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL, "cannot create action");
+	}
+	rte_atomic32_init(&cache_resource->refcnt);
+	rte_atomic32_inc(&cache_resource->refcnt);
+	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource, next);
+	dev_flow->dv.push_vlan_res = cache_resource;
+	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	return 0;
+}
+/**
  * Get the size of specific rte_flow_item_type
  *
  * @param[in] item_type
@@ -1729,6 +1897,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const struct rte_flow_attr *attr,
+				const struct flow_dv_vlan_be *vlan,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource res;
+	union {
+		struct flow_dv_vlan_be vlan;
+		rte_be32_t tag;
+	} hdr;
+
+	hdr.vlan = *vlan;
+	res.vlan_tag = hdr.tag;
+	if (attr->transfer)
+		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
+	else
+		res.ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
+					     MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
+	return flow_dv_push_vlan_action_resource_register
+					    (dev, &res, dev_flow, error);
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -3173,6 +3382,15 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4762,7 +4980,9 @@ struct field_modify_info modify_tcp[] = {
 	uint32_t modify_action_position = UINT32_MAX;
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
+	struct flow_dv_vlan_be vlan = { 0 };
 
+	flow_dev_get_vlan_info_from_items(items, &vlan);
 	flow->group = attr->group;
 	if (attr->transfer)
 		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
@@ -4876,6 +5096,17 @@ struct field_modify_info modify_tcp[] = {
 						priv->sh->pop_vlan_action;
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			vlan.tpid =
+			     (((const struct rte_flow_action_of_push_vlan *)
+						     actions->conf)->ethertype);
+			if (flow_dv_create_action_push_vlan
+					    (dev, attr, &vlan, dev_flow, error))
+				return -rte_errno;
+			dev_flow->dv.actions[actions_n++] =
+					   dev_flow->dv.push_vlan_res->action;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -5496,6 +5727,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Release push vlan action resource.
+ *
+ * @param flow
+ *   Pointer to mlx5_flow.
+ *
+ * @return
+ *   1 while a reference on it exists, 0 when freed.
+ */
+static int
+flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
+		flow->dv.push_vlan_res;
+
+	assert(cache_resource->action);
+	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
+		claim_zero(mlx5_glue->destroy_flow_action
+				(cache_resource->action));
+		LIST_REMOVE(cache_resource, next);
+		rte_free(cache_resource);
+		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
+			(void *)cache_resource);
+		return 0;
+	}
+	return 1;
+}
+
+/**
  * Remove the flow from the NIC but keeps it in memory.
  *
  * @param[in] dev
@@ -5567,6 +5829,8 @@ struct field_modify_info modify_tcp[] = {
 			flow_dv_jump_tbl_resource_release(dev_flow);
 		if (dev_flow->dv.port_id_action)
 			flow_dv_port_id_action_resource_release(dev_flow);
+		if (dev_flow->dv.push_vlan_res)
+			flow_dv_push_vlan_action_resource_release(dev_flow);
 		rte_free(dev_flow);
 	}
 }
-- 
1.8.3.1

[dpdk-dev] [PATCH 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VLAN priority (PCP) field
in about-to-be-pushed VLAN header.
This feature can only modify the PCP field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 58 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index e81fee2..9ebf006 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -983,6 +983,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN PCP.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
+
+	if (conf->vlan_pcp > 7)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN PCP value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3391,6 +3432,13 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_set_vlan_pcp
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count PCP with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4980,6 +5028,7 @@ struct field_modify_info modify_tcp[] = {
 	uint32_t modify_action_position = UINT32_MAX;
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
+	uint16_t vlan_tci;
 	struct flow_dv_vlan_be vlan = { 0 };
 
 	flow_dev_get_vlan_info_from_items(items, &vlan);
@@ -5107,6 +5156,15 @@ struct field_modify_info modify_tcp[] = {
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			vlan_tci =
+			    ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			vlan_tci = vlan_tci << FLOW_DV_VLAN_PCP_SHIFT;
+			vlan.tci &= ~FLOW_DV_VLAN_PCP_MASK;
+			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH 6/7] net/mlx5: supp modify VLAN ID on new VLAN header

[Moti Haimovsky]

This commit adds support for modifying the VLAN ID (VID) field
in an about-to-be-pushed VLAN header.
This feature can only modify the VID field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 55 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 9ebf006..c9bfad8 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1024,6 +1024,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN VID.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
+
+	if (conf->vlan_vid > RTE_BE16(0xFFFE))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN VID value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3439,6 +3480,13 @@ struct field_modify_info modify_tcp[] = {
 				return ret;
 			/* Count PCP with push_vlan command. */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			ret = flow_dv_validate_action_set_vlan_vid
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count VID with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -5165,6 +5213,13 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
 			/* Push VLAN command will use this value */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			vlan.tci &= ~FLOW_DV_VLAN_VID_MASK;
+			vlan.tci |=
+			    ((const struct rte_flow_action_of_set_vlan_vid *)
+						       actions->conf)->vlan_vid;
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VID of the outermost VLAN
header already present in the packet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.h    |  3 +-
 drivers/net/mlx5/mlx5_flow_dv.c | 90 +++++++++++++++++++++++++++++++++++------
 drivers/net/mlx5/mlx5_prm.h     |  1 +
 3 files changed, 81 insertions(+), 13 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 15c9c04..95abbb8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -171,7 +171,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
-				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
+				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
 
 #define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
 				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index c9bfad8..0250047 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -123,6 +123,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan_out_first_vid[] = {
+	/* Size in bits !!! */
+	{12, 0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -421,6 +427,46 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set VLAN VID action to DV specification.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_vlan_vid
+			(struct mlx5_flow_dv_modify_hdr_resource *resource,
+			 const struct rte_flow_action *action,
+			 struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_set_vlan_vid *conf =
+		(const struct rte_flow_action_of_set_vlan_vid *)(action->conf);
+	int i = resource->actions_num;
+	struct mlx5_modification_cmd *actions = &resource->actions[i];
+	struct field_modify_info *field = modify_vlan_out_first_vid;
+
+	if (i >= MLX5_MODIFY_NUM)
+		return rte_flow_error_set(error, EINVAL,
+			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+			 "too many items to modify");
+	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
+	actions[i].field = field->id;
+	actions[i].length = field->size;
+	actions[i].offset = field->offset;
+	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
+	actions[i].data1 = conf->vlan_vid;
+	actions[i].data1 = actions[i].data1 << 16;
+	resource->actions_num = ++i;
+	return 0;
+}
+
+/**
  * Convert modify-header set TP action to DV specification.
  *
  * @param[in,out] resource
@@ -1026,8 +1072,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the set VLAN VID.
  *
- * @param[in] action_flags
- *   Holds the actions detected until now.
+ * @param[in] item_flags
+ *   Holds the items detected in this rule.
  * @param[in] actions
  *   Pointer to the list of actions remaining in the flow rule.
  * @param[in] attr
@@ -1039,7 +1085,7 @@ struct field_modify_info modify_tcp[] = {
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
 				     const struct rte_flow_action actions[],
 				     struct rte_flow_error *error)
 {
@@ -1050,17 +1096,27 @@ struct field_modify_info modify_tcp[] = {
 		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
 					  "VLAN VID value to too big");
+	/* If a push VLAN action follows then it will handle this action */
 	if (mlx5_flow_find_action(actions,
-				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+		return 0;
+
+	/*
+	 * Action is on an existing VLAN header:
+	 *    Need to verify this is a single modify CID action.
+	 *   Rule mast include a match on outer VLAN.
+	 */
+	if (mlx5_flow_find_action(++action,
+				  RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
 		return rte_flow_error_set(error, ENOTSUP,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID can only be used "
-					  "with push VLAN action");
-	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
-		return rte_flow_error_set(error, ENOTSUP,
+					  "Multiple VLAN VID modifications are "
+					  "not supported");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID action must precede "
-					  "the push VLAN action");
+					  "match on VLAN is required in order "
+					  "to set VLAN VID");
 	return 0;
 }
 
@@ -3482,7 +3538,7 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 			ret = flow_dv_validate_action_set_vlan_vid
-						(action_flags, actions, error);
+						(item_flags, actions, error);
 			if (ret < 0)
 				return ret;
 			/* Count VID with push_vlan command. */
@@ -5203,6 +5259,8 @@ struct field_modify_info modify_tcp[] = {
 			dev_flow->dv.actions[actions_n++] =
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			/* Push VLAN command is also handling this VLAN_VID */
+			action_flags &= ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			vlan_tci =
@@ -5218,7 +5276,15 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |=
 			    ((const struct rte_flow_action_of_set_vlan_vid *)
 						       actions->conf)->vlan_vid;
-			/* Push VLAN command will use this value */
+			if (mlx5_flow_find_action
+				(actions,
+				 RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+				break;
+			/* If no VLAN push - this is a modify header action */
+			if (flow_dv_convert_action_modify_vlan_vid
+							(&res, actions, error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index d62837e..e5afc1c 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -413,6 +413,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 0/7] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

This series of patches adds support for those VLAN actions
to the mlx5 PMD using the Direct Verbs interface.

v2:
- Code rebase on latest commits.

Moti Haimovsky (7):
  net/mlx5: support for an action search in a list
  net/mlx5: add VLAN push/pop DR commands to glue
  net/mlx5: support pop flow action on VLAN header
  net/mlx5: support push flow action on VLAN header
  net/mlx5: support modify VLAN priority on VLAN hdr
  net/mlx5: supp modify VLAN ID on new VLAN header
  net/mlx5: supp modify VLAN ID on existing VLAN hdr

 drivers/net/mlx5/Makefile       |   5 +
 drivers/net/mlx5/meson.build    |   2 +
 drivers/net/mlx5/mlx5.c         |   9 +
 drivers/net/mlx5/mlx5.h         |   3 +
 drivers/net/mlx5/mlx5_flow.c    |  23 ++
 drivers/net/mlx5/mlx5_flow.h    |  27 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 521 ++++++++++++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.c    |  29 +++
 drivers/net/mlx5/mlx5_glue.h    |   6 +
 drivers/net/mlx5/mlx5_prm.h     |   1 +
 10 files changed, 623 insertions(+), 3 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v2 1/7] net/mlx5: support for an action search in a list

[Moti Haimovsky]

This commit adds a helper routine that supports searching for a
specific action in a list of actions.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 9d2c8c9..92f33d8 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -689,6 +689,29 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 }
 
 /*
+ * return a pointer to the desired action in the list of actions.
+ *
+ * @param[in] actions
+ *   The list of actions to search the action in.
+ * @param[in] action
+ *   The action to find.
+ *
+ * @return
+ *   Pointer to the action in the list, if found. NULL otherwise.
+ */
+const struct rte_flow_action *
+mlx5_flow_find_action(const struct rte_flow_action *actions,
+		      enum rte_flow_action_type action)
+{
+	if (actions == NULL)
+		return NULL;
+	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+		if (actions->type == action)
+			return actions;
+	return NULL;
+}
+
+/*
  * Validate the flag action.
  *
  * @param[in] action_flags
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 822ff36..8d193b6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct mlx5_flow *dev_flow, int tunnel,
 				     uint64_t hash_fields);
 uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 				   uint32_t subpriority);
+const struct rte_flow_action *mlx5_flow_find_action
+					(const struct rte_flow_action *actions,
+					 enum rte_flow_action_type action);
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
 				    const struct rte_flow_attr *attr,
 				    struct rte_flow_error *error);
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Moti Haimovsky]

This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
interface.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile    |  5 +++++
 drivers/net/mlx5/meson.build |  2 ++
 drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.h |  6 ++++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index dbb2a4e..95ce2e2 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -163,6 +163,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
 		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
 		$(AUTOCONF_OUTPUT)
 	$Q sh -- '$<' '$@' \
+		HAVE_MLX5DV_DR_VLAN \
+		infiniband/mlx5dv.h \
+		func mlx5dv_dr_action_create_push_vlan \
+		$(AUTOCONF_OUTPUT)
+	$Q sh -- '$<' '$@' \
 		HAVE_IBV_DEVX_OBJ \
 		infiniband/mlx5dv.h \
 		func mlx5dv_devx_obj_create \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 62b41ca..d5d10fe 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -130,6 +130,8 @@ if build
 		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
 		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
 		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
+		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
+		'mlx5dv_dr_action_create_push_vlan' ],
 		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
 		'SUPPORTED_40000baseKR4_Full' ],
 		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 50c369a..9ee37f4 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -415,6 +415,31 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain *domain,
+					  rte_be32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag);
+#else
+	(void)domain;
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -1016,6 +1041,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index 6b5dadf..82d6b10 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -9,6 +9,8 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include "rte_byteorder.h"
+
 /* Verbs headers do not support -pedantic. */
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
@@ -156,6 +158,10 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)
+					(struct mlx5dv_dr_domain *domain,
+					 rte_be32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 3/7] net/mlx5: support pop flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
direct verbs flow rules.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5.c         |  9 +++++
 drivers/net/mlx5/mlx5.h         |  1 +
 drivers/net/mlx5/mlx5_flow.h    |  5 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 78 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 962c0d5..19c0091 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -549,6 +549,7 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = mlx5_glue->dr_create_flow_action_drop();
 	}
 #endif
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 	sh->dv_refcnt++;
 	priv->dr_shared = 1;
 	return 0;
@@ -571,6 +572,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	return err;
 #else
 	(void)priv;
@@ -616,6 +621,10 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = NULL;
 	}
 #endif
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	pthread_mutex_destroy(&sh->dv_mutex);
 #else
 	(void)priv;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f559f83..4d457bf 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -570,6 +570,7 @@ struct mlx5_ibv_shared {
 	void *tx_domain; /* TX Direct Rules name space handle. */
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
 	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8d193b6..06b0470 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -154,7 +154,8 @@
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -171,6 +172,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 41500bc..2cb86e8 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -815,6 +815,61 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
+				 uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+
+	(void)action;
+	(void)attr;
+	if (!priv->sh->pop_vlan_action)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "pop vlan action is not supported");
+	/*
+	 * Check for inconsistencies:
+	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
+	 *  fail strip_vlan in a flow that matches packets without explicitly a
+	 *  matching on VLAN tag ?
+	 */
+	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "no support for multiple vlan pop "
+					  "actions");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "cannot pop vlan without a "
+					  "match on (outer) vlan in the flow");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3100,6 +3155,16 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (flow_dv_validate_action_pop_vlan(dev,
+							     action_flags,
+							     actions,
+							     item_flags, attr,
+							     error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -3273,6 +3338,13 @@ struct field_modify_info modify_tcp[] = {
 						  "action not supported");
 		}
 	}
+	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
+	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION,
+					  actions,
+					  "can't have vxlan and vlan"
+					  " actions in the same rule");
 	/* Eswitch has few restrictions on using items and actions */
 	if (attr->transfer) {
 		if (action_flags & MLX5_FLOW_ACTION_FLAG)
@@ -4791,6 +4863,12 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			dev_flow->dv.actions[actions_n++] =
+						priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 4/7] net/mlx5: support push flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN using
direct verbs flow rules.
If present in the flow, The VLAN default values are taken from the
VLAN item configuration.
In this commit only the VLAN TPID value can be set since VLAN
modification actions are not supported yet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5.h         |   2 +
 drivers/net/mlx5/mlx5_flow.h    |  18 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 264 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 282 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 4d457bf..ae4a7c5 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
 	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
 	LIST_HEAD(port_id_action_list, mlx5_flow_dv_port_id_action_resource)
 		port_id_action_list; /* List of port ID actions. */
+	LIST_HEAD(push_vlan_action_list, mlx5_flow_dv_push_vlan_action_resource)
+		push_vlan_action_list; /* List of push VLAN actions. */
 	struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
 	/* Shared interrupt handler section. */
 	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 06b0470..15c9c04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -150,7 +150,8 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
@@ -172,7 +173,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
-#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
+				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
 	uint32_t port_id; /**< Port ID value. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action; /**< Direct verbs action object. */
+	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
+	rte_be32_t vlan_tag; /**< VLAN tag value. */
+};
+
 /*
  * Max number of actions per DV flow.
  * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
@@ -335,6 +347,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to port ID action resource. */
 	struct mlx5_vf_vlan vf_vlan;
 	/**< Structure for VF VLAN workaround. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
+	/**< Pointer to push VLAN action resource in cache. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
 	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
 	/**< Action list. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 2cb86e8..3a92846 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -50,6 +50,21 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+/* VLAN header definitions */
+#define FLOW_DV_VLAN_PCP_SHIFT 13
+#define FLOW_DV_VLAN_PCP_MASK RTE_BE16(0x7 << FLOW_DV_VLAN_PCP_SHIFT)
+#define FLOW_DV_VLAN_VID_MASK RTE_BE16(0x0fff)
+
+struct flow_dv_vlan_be {
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+	rte_be16_t tci;
+	rte_be16_t tpid;
+#else
+	rte_be16_t tpid;
+	rte_be16_t tci;
+#endif
+};
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -817,6 +832,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the pop VLAN action.
  *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
  * @param[in] action_flags
  *   Holds the actions detected until now.
  * @param[in] action
@@ -870,6 +887,86 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Get VLAN default info from vlan match info.
+ *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
+ * @param[in] item
+ *   the list of item specifications.
+ * @param[out] vlan
+ *   pointer VLAN info to fill to.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static void
+flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
+				   struct flow_dv_vlan_be *vlan)
+{
+	const struct rte_flow_item_vlan nic_mask = {
+		.tci = RTE_BE16(0x0fff),
+		.inner_type = RTE_BE16(0xffff),
+	};
+
+	if (items == NULL)
+		return;
+	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
+	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
+		;
+	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
+		const struct rte_flow_item_vlan *vlan_m = items->mask;
+		const struct rte_flow_item_vlan *vlan_v = items->spec;
+
+		if (!vlan_m)
+			vlan_m = &nic_mask;
+		if (vlan_m->tci == nic_mask.tci)
+			vlan->tci = vlan_v->tci & vlan_m->tci;
+		if (vlan_m->inner_type == nic_mask.inner_type)
+			vlan->tpid = vlan_v->inner_type & vlan_m->inner_type;
+	}
+}
+
+/**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_push_vlan *push_vlan = action->conf;
+
+	if (push_vlan->ethertype != RTE_BE16(0x8100) &&
+	    push_vlan->ethertype != RTE_BE16(0x88a8))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "invalid vlan ethertype");
+	if (action_flags &
+		(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "no support for multiple VLAN "
+					  "actions");
+	(void)attr;
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -1300,6 +1397,77 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Find existing push vlan resource or create and register a new one.
+ *
+ * @param dev[in, out]
+ *   Pointer to rte_eth_dev structure.
+ * @param[in, out] resource
+ *   Pointer to port ID action resource.
+ * @parm[in, out] dev_flow
+ *   Pointer to the dev_flow.
+ * @param[out] error
+ *   pointer to error structure.
+ *
+ * @return
+ *   0 on success otherwise -errno and errno is set.
+ */
+static int
+flow_dv_push_vlan_action_resource_register
+		       (struct rte_eth_dev *dev,
+			struct mlx5_flow_dv_push_vlan_action_resource *resource,
+			struct mlx5_flow *dev_flow,
+			struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+	struct mlx5_ibv_shared *sh = priv->sh;
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
+	struct mlx5dv_dr_domain *domain;
+
+	/* Lookup a matching resource from cache. */
+	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
+		if (resource->vlan_tag == cache_resource->vlan_tag &&
+		    resource->ft_type == cache_resource->ft_type) {
+			DRV_LOG(DEBUG, "push-VLAN action resource resource %p: "
+				"refcnt %d++",
+				(void *)cache_resource,
+				rte_atomic32_read(&cache_resource->refcnt));
+			rte_atomic32_inc(&cache_resource->refcnt);
+			dev_flow->dv.push_vlan_res = cache_resource;
+			return 0;
+		}
+	}
+	/* Register new push_vlan action resource. */
+	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
+	if (!cache_resource)
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "cannot allocate resource memory");
+	*cache_resource = *resource;
+	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
+		domain = sh->fdb_domain;
+	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
+		domain = sh->rx_domain;
+	else
+		domain = sh->tx_domain;
+	cache_resource->action =
+		mlx5_glue->dr_create_flow_action_push_vlan(domain,
+							   resource->vlan_tag);
+	if (!cache_resource->action) {
+		rte_free(cache_resource);
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL, "cannot create action");
+	}
+	rte_atomic32_init(&cache_resource->refcnt);
+	rte_atomic32_inc(&cache_resource->refcnt);
+	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource, next);
+	dev_flow->dv.push_vlan_res = cache_resource;
+	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	return 0;
+}
+/**
  * Get the size of specific rte_flow_item_type
  *
  * @param[in] item_type
@@ -1719,6 +1887,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const struct rte_flow_attr *attr,
+				const struct flow_dv_vlan_be *vlan,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource res;
+	union {
+		struct flow_dv_vlan_be vlan;
+		rte_be32_t tag;
+	} hdr;
+
+	hdr.vlan = *vlan;
+	res.vlan_tag = hdr.tag;
+	if (attr->transfer)
+		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
+	else
+		res.ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
+					     MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
+	return flow_dv_push_vlan_action_resource_register
+					    (dev, &res, dev_flow, error);
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -3165,6 +3374,15 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4755,7 +4973,9 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	struct flow_dv_vlan_be vlan = { 0 };
 
+	flow_dev_get_vlan_info_from_items(items, &vlan);
 	flow->group = attr->group;
 	if (attr->transfer)
 		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
@@ -4869,6 +5089,17 @@ struct field_modify_info modify_tcp[] = {
 						priv->sh->pop_vlan_action;
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			vlan.tpid =
+			     (((const struct rte_flow_action_of_push_vlan *)
+						     actions->conf)->ethertype);
+			if (flow_dv_create_action_push_vlan
+					    (dev, attr, &vlan, dev_flow, error))
+				return -rte_errno;
+			dev_flow->dv.actions[actions_n++] =
+					   dev_flow->dv.push_vlan_res->action;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -5517,6 +5748,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Release push vlan action resource.
+ *
+ * @param flow
+ *   Pointer to mlx5_flow.
+ *
+ * @return
+ *   1 while a reference on it exists, 0 when freed.
+ */
+static int
+flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
+		flow->dv.push_vlan_res;
+
+	assert(cache_resource->action);
+	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
+		claim_zero(mlx5_glue->destroy_flow_action
+				(cache_resource->action));
+		LIST_REMOVE(cache_resource, next);
+		rte_free(cache_resource);
+		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
+			(void *)cache_resource);
+		return 0;
+	}
+	return 1;
+}
+
+/**
  * Remove the flow from the NIC but keeps it in memory.
  *
  * @param[in] dev
@@ -5588,6 +5850,8 @@ struct field_modify_info modify_tcp[] = {
 			flow_dv_jump_tbl_resource_release(dev_flow);
 		if (dev_flow->dv.port_id_action)
 			flow_dv_port_id_action_resource_release(dev_flow);
+		if (dev_flow->dv.push_vlan_res)
+			flow_dv_push_vlan_action_resource_release(dev_flow);
 		rte_free(dev_flow);
 	}
 }
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VLAN priority (PCP) field
in about-to-be-pushed VLAN header.
This feature can only modify the PCP field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 58 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 3a92846..30b0112 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -967,6 +967,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN PCP.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
+
+	if (conf->vlan_pcp > 7)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN PCP value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3383,6 +3424,13 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_set_vlan_pcp
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count PCP with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4973,6 +5021,7 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	uint16_t vlan_tci;
 	struct flow_dv_vlan_be vlan = { 0 };
 
 	flow_dev_get_vlan_info_from_items(items, &vlan);
@@ -5100,6 +5149,15 @@ struct field_modify_info modify_tcp[] = {
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			vlan_tci =
+			    ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			vlan_tci = vlan_tci << FLOW_DV_VLAN_PCP_SHIFT;
+			vlan.tci &= ~FLOW_DV_VLAN_PCP_MASK;
+			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 6/7] net/mlx5: supp modify VLAN ID on new VLAN header

[Moti Haimovsky]

This commit adds support for modifying the VLAN ID (VID) field
in an about-to-be-pushed VLAN header.
This feature can only modify the VID field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 55 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 30b0112..ea51805 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1008,6 +1008,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN VID.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
+
+	if (conf->vlan_vid > RTE_BE16(0xFFFE))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN VID value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3431,6 +3472,13 @@ struct field_modify_info modify_tcp[] = {
 				return ret;
 			/* Count PCP with push_vlan command. */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			ret = flow_dv_validate_action_set_vlan_vid
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count VID with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -5158,6 +5206,13 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
 			/* Push VLAN command will use this value */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			vlan.tci &= ~FLOW_DV_VLAN_VID_MASK;
+			vlan.tci |=
+			    ((const struct rte_flow_action_of_set_vlan_vid *)
+						       actions->conf)->vlan_vid;
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VID of the outermost VLAN
header already present in the packet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.h    |  3 +-
 drivers/net/mlx5/mlx5_flow_dv.c | 90 +++++++++++++++++++++++++++++++++++------
 drivers/net/mlx5/mlx5_prm.h     |  1 +
 3 files changed, 81 insertions(+), 13 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 15c9c04..95abbb8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -171,7 +171,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
-				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
+				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
 
 #define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
 				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ea51805..8463327 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -123,6 +123,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan_out_first_vid[] = {
+	/* Size in bits !!! */
+	{12, 0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -405,6 +411,46 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set VLAN VID action to DV specification.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_vlan_vid
+			(struct mlx5_flow_dv_modify_hdr_resource *resource,
+			 const struct rte_flow_action *action,
+			 struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_set_vlan_vid *conf =
+		(const struct rte_flow_action_of_set_vlan_vid *)(action->conf);
+	int i = resource->actions_num;
+	struct mlx5_modification_cmd *actions = &resource->actions[i];
+	struct field_modify_info *field = modify_vlan_out_first_vid;
+
+	if (i >= MLX5_MODIFY_NUM)
+		return rte_flow_error_set(error, EINVAL,
+			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+			 "too many items to modify");
+	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
+	actions[i].field = field->id;
+	actions[i].length = field->size;
+	actions[i].offset = field->offset;
+	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
+	actions[i].data1 = conf->vlan_vid;
+	actions[i].data1 = actions[i].data1 << 16;
+	resource->actions_num = ++i;
+	return 0;
+}
+
+/**
  * Convert modify-header set TP action to DV specification.
  *
  * @param[in,out] resource
@@ -1010,8 +1056,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the set VLAN VID.
  *
- * @param[in] action_flags
- *   Holds the actions detected until now.
+ * @param[in] item_flags
+ *   Holds the items detected in this rule.
  * @param[in] actions
  *   Pointer to the list of actions remaining in the flow rule.
  * @param[in] attr
@@ -1023,7 +1069,7 @@ struct field_modify_info modify_tcp[] = {
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
 				     const struct rte_flow_action actions[],
 				     struct rte_flow_error *error)
 {
@@ -1034,17 +1080,27 @@ struct field_modify_info modify_tcp[] = {
 		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
 					  "VLAN VID value to too big");
+	/* If a push VLAN action follows then it will handle this action */
 	if (mlx5_flow_find_action(actions,
-				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+		return 0;
+
+	/*
+	 * Action is on an existing VLAN header:
+	 *    Need to verify this is a single modify CID action.
+	 *   Rule mast include a match on outer VLAN.
+	 */
+	if (mlx5_flow_find_action(++action,
+				  RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
 		return rte_flow_error_set(error, ENOTSUP,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID can only be used "
-					  "with push VLAN action");
-	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
-		return rte_flow_error_set(error, ENOTSUP,
+					  "Multiple VLAN VID modifications are "
+					  "not supported");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID action must precede "
-					  "the push VLAN action");
+					  "match on VLAN is required in order "
+					  "to set VLAN VID");
 	return 0;
 }
 
@@ -3474,7 +3530,7 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 			ret = flow_dv_validate_action_set_vlan_vid
-						(action_flags, actions, error);
+						(item_flags, actions, error);
 			if (ret < 0)
 				return ret;
 			/* Count VID with push_vlan command. */
@@ -5196,6 +5252,8 @@ struct field_modify_info modify_tcp[] = {
 			dev_flow->dv.actions[actions_n++] =
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			/* Push VLAN command is also handling this VLAN_VID */
+			action_flags &= ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			vlan_tci =
@@ -5211,7 +5269,15 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |=
 			    ((const struct rte_flow_action_of_set_vlan_vid *)
 						       actions->conf)->vlan_vid;
-			/* Push VLAN command will use this value */
+			if (mlx5_flow_find_action
+				(actions,
+				 RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+				break;
+			/* If no VLAN push - this is a modify header action */
+			if (flow_dv_convert_action_modify_vlan_vid
+							(&res, actions, error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index d62837e..e5afc1c 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -413,6 +413,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 0/7] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

This series of patches adds support for those VLAN actions
to the mlx5 PMD using the Direct Verbs interface.

v2:
- Code rebase on latest commits.

v3:
- mlx5 documentation update.

Moti Haimovsky (7):
  net/mlx5: support for an action search in a list
  net/mlx5: add VLAN push/pop DR commands to glue
  net/mlx5: support pop flow action on VLAN header
  net/mlx5: support push flow action on VLAN header
  net/mlx5: support modify VLAN priority on VLAN hdr
  net/mlx5: supp modify VLAN ID on new VLAN header
  net/mlx5: supp modify VLAN ID on existing VLAN hdr

 doc/guides/nics/mlx5.rst        |  30 ++-
 drivers/net/mlx5/Makefile       |   5 +
 drivers/net/mlx5/meson.build    |   2 +
 drivers/net/mlx5/mlx5.c         |   9 +
 drivers/net/mlx5/mlx5.h         |   3 +
 drivers/net/mlx5/mlx5_flow.c    |  23 ++
 drivers/net/mlx5/mlx5_flow.h    |  27 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 521 ++++++++++++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.c    |  29 +++
 drivers/net/mlx5/mlx5_glue.h    |   6 +
 drivers/net/mlx5/mlx5_prm.h     |   1 +
 11 files changed, 646 insertions(+), 10 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v3 1/7] net/mlx5: support for an action search in a list

[Moti Haimovsky]

This commit adds a helper routine that supports searching for a
specific action in a list of actions.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 9d2c8c9..92f33d8 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -689,6 +689,29 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 }
 
 /*
+ * return a pointer to the desired action in the list of actions.
+ *
+ * @param[in] actions
+ *   The list of actions to search the action in.
+ * @param[in] action
+ *   The action to find.
+ *
+ * @return
+ *   Pointer to the action in the list, if found. NULL otherwise.
+ */
+const struct rte_flow_action *
+mlx5_flow_find_action(const struct rte_flow_action *actions,
+		      enum rte_flow_action_type action)
+{
+	if (actions == NULL)
+		return NULL;
+	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+		if (actions->type == action)
+			return actions;
+	return NULL;
+}
+
+/*
  * Validate the flag action.
  *
  * @param[in] action_flags
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 822ff36..8d193b6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct mlx5_flow *dev_flow, int tunnel,
 				     uint64_t hash_fields);
 uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 				   uint32_t subpriority);
+const struct rte_flow_action *mlx5_flow_find_action
+					(const struct rte_flow_action *actions,
+					 enum rte_flow_action_type action);
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
 				    const struct rte_flow_attr *attr,
 				    struct rte_flow_error *error);
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Moti Haimovsky]

This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
interface.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile    |  5 +++++
 drivers/net/mlx5/meson.build |  2 ++
 drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.h |  6 ++++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index dbb2a4e..95ce2e2 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -163,6 +163,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
 		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
 		$(AUTOCONF_OUTPUT)
 	$Q sh -- '$<' '$@' \
+		HAVE_MLX5DV_DR_VLAN \
+		infiniband/mlx5dv.h \
+		func mlx5dv_dr_action_create_push_vlan \
+		$(AUTOCONF_OUTPUT)
+	$Q sh -- '$<' '$@' \
 		HAVE_IBV_DEVX_OBJ \
 		infiniband/mlx5dv.h \
 		func mlx5dv_devx_obj_create \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 62b41ca..d5d10fe 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -130,6 +130,8 @@ if build
 		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
 		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
 		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
+		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
+		'mlx5dv_dr_action_create_push_vlan' ],
 		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
 		'SUPPORTED_40000baseKR4_Full' ],
 		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 50c369a..9ee37f4 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -415,6 +415,31 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain *domain,
+					  rte_be32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag);
+#else
+	(void)domain;
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -1016,6 +1041,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index 6b5dadf..82d6b10 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -9,6 +9,8 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include "rte_byteorder.h"
+
 /* Verbs headers do not support -pedantic. */
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
@@ -156,6 +158,10 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)
+					(struct mlx5dv_dr_domain *domain,
+					 rte_be32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 3/7] net/mlx5: support pop flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
direct verbs flow rules.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        |  6 ++++
 drivers/net/mlx5/mlx5.c         |  9 +++++
 drivers/net/mlx5/mlx5.h         |  1 +
 drivers/net/mlx5/mlx5_flow.h    |  5 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 78 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 4115520..81ad2d9 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -124,6 +124,8 @@ Limitations
 
   Will match any ipv4 packet (VLAN included).
 
+- VLAN pop offload is not supported on egress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1032,6 +1034,10 @@ Supported hardware offloads
    |                       | | rdma-core 24  |     | N/A       |
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
+   | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
+   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
+   +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
 -----------------
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 962c0d5..19c0091 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -549,6 +549,7 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = mlx5_glue->dr_create_flow_action_drop();
 	}
 #endif
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 	sh->dv_refcnt++;
 	priv->dr_shared = 1;
 	return 0;
@@ -571,6 +572,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	return err;
 #else
 	(void)priv;
@@ -616,6 +621,10 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = NULL;
 	}
 #endif
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	pthread_mutex_destroy(&sh->dv_mutex);
 #else
 	(void)priv;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f559f83..4d457bf 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -570,6 +570,7 @@ struct mlx5_ibv_shared {
 	void *tx_domain; /* TX Direct Rules name space handle. */
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
 	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8d193b6..06b0470 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -154,7 +154,8 @@
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -171,6 +172,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 41500bc..2cb86e8 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -815,6 +815,61 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
+				 uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+
+	(void)action;
+	(void)attr;
+	if (!priv->sh->pop_vlan_action)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "pop vlan action is not supported");
+	/*
+	 * Check for inconsistencies:
+	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
+	 *  fail strip_vlan in a flow that matches packets without explicitly a
+	 *  matching on VLAN tag ?
+	 */
+	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "no support for multiple vlan pop "
+					  "actions");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "cannot pop vlan without a "
+					  "match on (outer) vlan in the flow");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3100,6 +3155,16 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (flow_dv_validate_action_pop_vlan(dev,
+							     action_flags,
+							     actions,
+							     item_flags, attr,
+							     error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -3273,6 +3338,13 @@ struct field_modify_info modify_tcp[] = {
 						  "action not supported");
 		}
 	}
+	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
+	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION,
+					  actions,
+					  "can't have vxlan and vlan"
+					  " actions in the same rule");
 	/* Eswitch has few restrictions on using items and actions */
 	if (attr->transfer) {
 		if (action_flags & MLX5_FLOW_ACTION_FLAG)
@@ -4791,6 +4863,12 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			dev_flow->dv.actions[actions_n++] =
+						priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 4/7] net/mlx5: support push flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN using
direct verbs flow rules.
If present in the flow, The VLAN default values are taken from the
VLAN item configuration.
In this commit only the VLAN TPID value can be set since VLAN
modification actions are not supported yet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        |   6 +-
 drivers/net/mlx5/mlx5.h         |   2 +
 drivers/net/mlx5/mlx5_flow.h    |  18 ++-
 drivers/net/mlx5/mlx5_flow_dv.c | 264 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 286 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 81ad2d9..21c9de7 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -126,6 +126,8 @@ Limitations
 
 - VLAN pop offload is not supported on egress traffic.
 
+- VLAN push offload is not supported on ingress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1035,8 +1037,8 @@ Supported hardware offloads
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
-   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
-   |                       | | ConnectX-5    | | ConnectX-5    |
+   | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
+   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 4d457bf..ae4a7c5 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
 	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
 	LIST_HEAD(port_id_action_list, mlx5_flow_dv_port_id_action_resource)
 		port_id_action_list; /* List of port ID actions. */
+	LIST_HEAD(push_vlan_action_list, mlx5_flow_dv_push_vlan_action_resource)
+		push_vlan_action_list; /* List of push VLAN actions. */
 	struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
 	/* Shared interrupt handler section. */
 	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 06b0470..15c9c04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -150,7 +150,8 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
@@ -172,7 +173,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
-#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
+				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
 	uint32_t port_id; /**< Port ID value. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action; /**< Direct verbs action object. */
+	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
+	rte_be32_t vlan_tag; /**< VLAN tag value. */
+};
+
 /*
  * Max number of actions per DV flow.
  * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
@@ -335,6 +347,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to port ID action resource. */
 	struct mlx5_vf_vlan vf_vlan;
 	/**< Structure for VF VLAN workaround. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
+	/**< Pointer to push VLAN action resource in cache. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
 	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
 	/**< Action list. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 2cb86e8..3a92846 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -50,6 +50,21 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+/* VLAN header definitions */
+#define FLOW_DV_VLAN_PCP_SHIFT 13
+#define FLOW_DV_VLAN_PCP_MASK RTE_BE16(0x7 << FLOW_DV_VLAN_PCP_SHIFT)
+#define FLOW_DV_VLAN_VID_MASK RTE_BE16(0x0fff)
+
+struct flow_dv_vlan_be {
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+	rte_be16_t tci;
+	rte_be16_t tpid;
+#else
+	rte_be16_t tpid;
+	rte_be16_t tci;
+#endif
+};
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -817,6 +832,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the pop VLAN action.
  *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
  * @param[in] action_flags
  *   Holds the actions detected until now.
  * @param[in] action
@@ -870,6 +887,86 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Get VLAN default info from vlan match info.
+ *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
+ * @param[in] item
+ *   the list of item specifications.
+ * @param[out] vlan
+ *   pointer VLAN info to fill to.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static void
+flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
+				   struct flow_dv_vlan_be *vlan)
+{
+	const struct rte_flow_item_vlan nic_mask = {
+		.tci = RTE_BE16(0x0fff),
+		.inner_type = RTE_BE16(0xffff),
+	};
+
+	if (items == NULL)
+		return;
+	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
+	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
+		;
+	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
+		const struct rte_flow_item_vlan *vlan_m = items->mask;
+		const struct rte_flow_item_vlan *vlan_v = items->spec;
+
+		if (!vlan_m)
+			vlan_m = &nic_mask;
+		if (vlan_m->tci == nic_mask.tci)
+			vlan->tci = vlan_v->tci & vlan_m->tci;
+		if (vlan_m->inner_type == nic_mask.inner_type)
+			vlan->tpid = vlan_v->inner_type & vlan_m->inner_type;
+	}
+}
+
+/**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_push_vlan *push_vlan = action->conf;
+
+	if (push_vlan->ethertype != RTE_BE16(0x8100) &&
+	    push_vlan->ethertype != RTE_BE16(0x88a8))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "invalid vlan ethertype");
+	if (action_flags &
+		(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "no support for multiple VLAN "
+					  "actions");
+	(void)attr;
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -1300,6 +1397,77 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Find existing push vlan resource or create and register a new one.
+ *
+ * @param dev[in, out]
+ *   Pointer to rte_eth_dev structure.
+ * @param[in, out] resource
+ *   Pointer to port ID action resource.
+ * @parm[in, out] dev_flow
+ *   Pointer to the dev_flow.
+ * @param[out] error
+ *   pointer to error structure.
+ *
+ * @return
+ *   0 on success otherwise -errno and errno is set.
+ */
+static int
+flow_dv_push_vlan_action_resource_register
+		       (struct rte_eth_dev *dev,
+			struct mlx5_flow_dv_push_vlan_action_resource *resource,
+			struct mlx5_flow *dev_flow,
+			struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+	struct mlx5_ibv_shared *sh = priv->sh;
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
+	struct mlx5dv_dr_domain *domain;
+
+	/* Lookup a matching resource from cache. */
+	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
+		if (resource->vlan_tag == cache_resource->vlan_tag &&
+		    resource->ft_type == cache_resource->ft_type) {
+			DRV_LOG(DEBUG, "push-VLAN action resource resource %p: "
+				"refcnt %d++",
+				(void *)cache_resource,
+				rte_atomic32_read(&cache_resource->refcnt));
+			rte_atomic32_inc(&cache_resource->refcnt);
+			dev_flow->dv.push_vlan_res = cache_resource;
+			return 0;
+		}
+	}
+	/* Register new push_vlan action resource. */
+	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
+	if (!cache_resource)
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "cannot allocate resource memory");
+	*cache_resource = *resource;
+	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
+		domain = sh->fdb_domain;
+	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
+		domain = sh->rx_domain;
+	else
+		domain = sh->tx_domain;
+	cache_resource->action =
+		mlx5_glue->dr_create_flow_action_push_vlan(domain,
+							   resource->vlan_tag);
+	if (!cache_resource->action) {
+		rte_free(cache_resource);
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL, "cannot create action");
+	}
+	rte_atomic32_init(&cache_resource->refcnt);
+	rte_atomic32_inc(&cache_resource->refcnt);
+	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource, next);
+	dev_flow->dv.push_vlan_res = cache_resource;
+	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	return 0;
+}
+/**
  * Get the size of specific rte_flow_item_type
  *
  * @param[in] item_type
@@ -1719,6 +1887,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const struct rte_flow_attr *attr,
+				const struct flow_dv_vlan_be *vlan,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource res;
+	union {
+		struct flow_dv_vlan_be vlan;
+		rte_be32_t tag;
+	} hdr;
+
+	hdr.vlan = *vlan;
+	res.vlan_tag = hdr.tag;
+	if (attr->transfer)
+		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
+	else
+		res.ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
+					     MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
+	return flow_dv_push_vlan_action_resource_register
+					    (dev, &res, dev_flow, error);
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -3165,6 +3374,15 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4755,7 +4973,9 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	struct flow_dv_vlan_be vlan = { 0 };
 
+	flow_dev_get_vlan_info_from_items(items, &vlan);
 	flow->group = attr->group;
 	if (attr->transfer)
 		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
@@ -4869,6 +5089,17 @@ struct field_modify_info modify_tcp[] = {
 						priv->sh->pop_vlan_action;
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			vlan.tpid =
+			     (((const struct rte_flow_action_of_push_vlan *)
+						     actions->conf)->ethertype);
+			if (flow_dv_create_action_push_vlan
+					    (dev, attr, &vlan, dev_flow, error))
+				return -rte_errno;
+			dev_flow->dv.actions[actions_n++] =
+					   dev_flow->dv.push_vlan_res->action;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -5517,6 +5748,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Release push vlan action resource.
+ *
+ * @param flow
+ *   Pointer to mlx5_flow.
+ *
+ * @return
+ *   1 while a reference on it exists, 0 when freed.
+ */
+static int
+flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
+		flow->dv.push_vlan_res;
+
+	assert(cache_resource->action);
+	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
+		claim_zero(mlx5_glue->destroy_flow_action
+				(cache_resource->action));
+		LIST_REMOVE(cache_resource, next);
+		rte_free(cache_resource);
+		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
+			(void *)cache_resource);
+		return 0;
+	}
+	return 1;
+}
+
+/**
  * Remove the flow from the NIC but keeps it in memory.
  *
  * @param[in] dev
@@ -5588,6 +5850,8 @@ struct field_modify_info modify_tcp[] = {
 			flow_dv_jump_tbl_resource_release(dev_flow);
 		if (dev_flow->dv.port_id_action)
 			flow_dv_port_id_action_resource_release(dev_flow);
+		if (dev_flow->dv.push_vlan_res)
+			flow_dv_push_vlan_action_resource_release(dev_flow);
 		rte_free(dev_flow);
 	}
 }
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VLAN priority (PCP) field
in about-to-be-pushed VLAN header.
This feature can only modify the PCP field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        |  5 +++-
 drivers/net/mlx5/mlx5_flow_dv.c | 58 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 21c9de7..acaefd0 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -128,6 +128,8 @@ Limitations
 
 - VLAN push offload is not supported on ingress traffic.
 
+- VLAN set PCP offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1038,7 +1040,8 @@ Supported hardware offloads
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
-   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
+   | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
+   | | of_set_vlan_pcp)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 3a92846..30b0112 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -967,6 +967,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN PCP.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
+
+	if (conf->vlan_pcp > 7)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN PCP value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3383,6 +3424,13 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_set_vlan_pcp
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count PCP with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4973,6 +5021,7 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	uint16_t vlan_tci;
 	struct flow_dv_vlan_be vlan = { 0 };
 
 	flow_dev_get_vlan_info_from_items(items, &vlan);
@@ -5100,6 +5149,15 @@ struct field_modify_info modify_tcp[] = {
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			vlan_tci =
+			    ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			vlan_tci = vlan_tci << FLOW_DV_VLAN_PCP_SHIFT;
+			vlan.tci &= ~FLOW_DV_VLAN_PCP_MASK;
+			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 6/7] net/mlx5: supp modify VLAN ID on new VLAN header

[Moti Haimovsky]

This commit adds support for modifying the VLAN ID (VID) field
in an about-to-be-pushed VLAN header.
This feature can only modify the VID field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        |  5 +++-
 drivers/net/mlx5/mlx5_flow_dv.c | 55 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index acaefd0..c492635 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -130,6 +130,8 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
+- VLAN set VID offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1041,7 +1043,8 @@ Supported hardware offloads
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
    | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
-   | | of_set_vlan_pcp)    |                 |                 |
+   | | of_set_vlan_pcp /   |                 |                 |
+   | | of_set_vlan_vid)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 30b0112..ea51805 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1008,6 +1008,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN VID.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
+
+	if (conf->vlan_vid > RTE_BE16(0xFFFE))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN VID value to too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3431,6 +3472,13 @@ struct field_modify_info modify_tcp[] = {
 				return ret;
 			/* Count PCP with push_vlan command. */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			ret = flow_dv_validate_action_set_vlan_vid
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count VID with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -5158,6 +5206,13 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
 			/* Push VLAN command will use this value */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			vlan.tci &= ~FLOW_DV_VLAN_VID_MASK;
+			vlan.tci |=
+			    ((const struct rte_flow_action_of_set_vlan_vid *)
+						       actions->conf)->vlan_vid;
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v3 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VID of the outermost VLAN
header already present in the packet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        | 20 ++++-----
 drivers/net/mlx5/mlx5_flow.h    |  3 +-
 drivers/net/mlx5/mlx5_flow_dv.c | 90 +++++++++++++++++++++++++++++++++++------
 drivers/net/mlx5/mlx5_prm.h     |  1 +
 4 files changed, 92 insertions(+), 22 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index c492635..6e2e18a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -130,8 +130,6 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
-- VLAN set VID offload is not supported on existing headers.
-
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1017,13 +1015,17 @@ Supported hardware offloads
    | | (set_ipv4_src /     | | OFED 4.6-2    | | OFED 4.6-2    |
    | | set_ipv4_dst /      | | rdma-core 24  | | rdma-core 23  |
    | | set_ipv6_src /      | | ConnectX-5    | | ConnectX-5    |
-   | | set_ipv6_dst /      |                 |                 |
-   | | set_tp_src /        |                 |                 |
-   | | set_tp_dst /        |                 |                 |
-   | | dec_ttl /           |                 |                 |
-   | | set_ttl /           |                 |                 |
-   | | set_mac_src /       |                 |                 |
-   | | set_mac_dst)        |                 |                 |
+   | | set_ipv6_dst /      | |               | |               |
+   | | set_tp_src /        | |               | |               |
+   | | set_tp_dst /        | |               | |               |
+   | | dec_ttl /           | |               | |               |
+   | | set_ttl /           | |               | |               |
+   | | set_mac_src /       | |               | |               |
+   | | set_mac_dst)        | |               | |               |
+   | |                     | |               | |               |
+   | | (of_set_vlan_vid)   | | DPDK 19.11    | | DPDK 19.11    |
+   |                       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
    | Jump                  | | DPDK 19.05    | | DPDK 19.02    |
    |                       | | OFED 4.6-4    | | OFED 4.6-4    |
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 15c9c04..95abbb8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -171,7 +171,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
-				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
+				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
 
 #define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
 				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ea51805..8463327 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -123,6 +123,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan_out_first_vid[] = {
+	/* Size in bits !!! */
+	{12, 0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -405,6 +411,46 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set VLAN VID action to DV specification.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_vlan_vid
+			(struct mlx5_flow_dv_modify_hdr_resource *resource,
+			 const struct rte_flow_action *action,
+			 struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_set_vlan_vid *conf =
+		(const struct rte_flow_action_of_set_vlan_vid *)(action->conf);
+	int i = resource->actions_num;
+	struct mlx5_modification_cmd *actions = &resource->actions[i];
+	struct field_modify_info *field = modify_vlan_out_first_vid;
+
+	if (i >= MLX5_MODIFY_NUM)
+		return rte_flow_error_set(error, EINVAL,
+			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+			 "too many items to modify");
+	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
+	actions[i].field = field->id;
+	actions[i].length = field->size;
+	actions[i].offset = field->offset;
+	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
+	actions[i].data1 = conf->vlan_vid;
+	actions[i].data1 = actions[i].data1 << 16;
+	resource->actions_num = ++i;
+	return 0;
+}
+
+/**
  * Convert modify-header set TP action to DV specification.
  *
  * @param[in,out] resource
@@ -1010,8 +1056,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the set VLAN VID.
  *
- * @param[in] action_flags
- *   Holds the actions detected until now.
+ * @param[in] item_flags
+ *   Holds the items detected in this rule.
  * @param[in] actions
  *   Pointer to the list of actions remaining in the flow rule.
  * @param[in] attr
@@ -1023,7 +1069,7 @@ struct field_modify_info modify_tcp[] = {
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
 				     const struct rte_flow_action actions[],
 				     struct rte_flow_error *error)
 {
@@ -1034,17 +1080,27 @@ struct field_modify_info modify_tcp[] = {
 		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
 					  "VLAN VID value to too big");
+	/* If a push VLAN action follows then it will handle this action */
 	if (mlx5_flow_find_action(actions,
-				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+		return 0;
+
+	/*
+	 * Action is on an existing VLAN header:
+	 *    Need to verify this is a single modify CID action.
+	 *   Rule mast include a match on outer VLAN.
+	 */
+	if (mlx5_flow_find_action(++action,
+				  RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
 		return rte_flow_error_set(error, ENOTSUP,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID can only be used "
-					  "with push VLAN action");
-	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
-		return rte_flow_error_set(error, ENOTSUP,
+					  "Multiple VLAN VID modifications are "
+					  "not supported");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID action must precede "
-					  "the push VLAN action");
+					  "match on VLAN is required in order "
+					  "to set VLAN VID");
 	return 0;
 }
 
@@ -3474,7 +3530,7 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 			ret = flow_dv_validate_action_set_vlan_vid
-						(action_flags, actions, error);
+						(item_flags, actions, error);
 			if (ret < 0)
 				return ret;
 			/* Count VID with push_vlan command. */
@@ -5196,6 +5252,8 @@ struct field_modify_info modify_tcp[] = {
 			dev_flow->dv.actions[actions_n++] =
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			/* Push VLAN command is also handling this VLAN_VID */
+			action_flags &= ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			vlan_tci =
@@ -5211,7 +5269,15 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |=
 			    ((const struct rte_flow_action_of_set_vlan_vid *)
 						       actions->conf)->vlan_vid;
-			/* Push VLAN command will use this value */
+			if (mlx5_flow_find_action
+				(actions,
+				 RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+				break;
+			/* If no VLAN push - this is a modify header action */
+			if (flow_dv_convert_action_modify_vlan_vid
+							(&res, actions, error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index d62837e..e5afc1c 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -413,6 +413,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 0/7] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

This series of patches adds support for those VLAN actions
to the mlx5 PMD using the Direct Verbs interface.

v2:
- Code rebase on latest commits.

v3:
- mlx5 documentation update.

v4:
- Update the release notes with new the new features.
- Minor bug fixes.

Moti Haimovsky (7):
  net/mlx5: support for an action search in a list
  net/mlx5: add VLAN push/pop DR commands to glue
  net/mlx5: support pop flow action on VLAN header
  net/mlx5: support push flow action on VLAN header
  net/mlx5: support modify VLAN priority on VLAN hdr
  net/mlx5: supp modify VLAN ID on new VLAN header
  net/mlx5: supp modify VLAN ID on existing VLAN hdr

 doc/guides/nics/mlx5.rst               |  33 ++-
 doc/guides/rel_notes/release_19_11.rst |   9 +
 drivers/net/mlx5/Makefile              |   5 +
 drivers/net/mlx5/meson.build           |   2 +
 drivers/net/mlx5/mlx5.c                |   9 +
 drivers/net/mlx5/mlx5.h                |   3 +
 drivers/net/mlx5/mlx5_flow.c           |  23 ++
 drivers/net/mlx5/mlx5_flow.h           |  27 +-
 drivers/net/mlx5/mlx5_flow_dv.c        | 521 +++++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.c           |  29 ++
 drivers/net/mlx5/mlx5_glue.h           |   6 +
 drivers/net/mlx5/mlx5_prm.h            |   1 +
 12 files changed, 658 insertions(+), 10 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v4 1/7] net/mlx5: support for an action search in a list

[Moti Haimovsky]

This commit adds a helper routine that supports searching for a
specific action in a list of actions.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 9d2c8c9..92f33d8 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -689,6 +689,29 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 }
 
 /*
+ * return a pointer to the desired action in the list of actions.
+ *
+ * @param[in] actions
+ *   The list of actions to search the action in.
+ * @param[in] action
+ *   The action to find.
+ *
+ * @return
+ *   Pointer to the action in the list, if found. NULL otherwise.
+ */
+const struct rte_flow_action *
+mlx5_flow_find_action(const struct rte_flow_action *actions,
+		      enum rte_flow_action_type action)
+{
+	if (actions == NULL)
+		return NULL;
+	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+		if (actions->type == action)
+			return actions;
+	return NULL;
+}
+
+/*
  * Validate the flag action.
  *
  * @param[in] action_flags
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 822ff36..8d193b6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct mlx5_flow *dev_flow, int tunnel,
 				     uint64_t hash_fields);
 uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 				   uint32_t subpriority);
+const struct rte_flow_action *mlx5_flow_find_action
+					(const struct rte_flow_action *actions,
+					 enum rte_flow_action_type action);
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
 				    const struct rte_flow_attr *attr,
 				    struct rte_flow_error *error);
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Moti Haimovsky]

This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
interface.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile    |  5 +++++
 drivers/net/mlx5/meson.build |  2 ++
 drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.h |  6 ++++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index dbb2a4e..95ce2e2 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -163,6 +163,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
 		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
 		$(AUTOCONF_OUTPUT)
 	$Q sh -- '$<' '$@' \
+		HAVE_MLX5DV_DR_VLAN \
+		infiniband/mlx5dv.h \
+		func mlx5dv_dr_action_create_push_vlan \
+		$(AUTOCONF_OUTPUT)
+	$Q sh -- '$<' '$@' \
 		HAVE_IBV_DEVX_OBJ \
 		infiniband/mlx5dv.h \
 		func mlx5dv_devx_obj_create \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 62b41ca..d5d10fe 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -130,6 +130,8 @@ if build
 		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
 		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
 		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
+		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
+		'mlx5dv_dr_action_create_push_vlan' ],
 		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
 		'SUPPORTED_40000baseKR4_Full' ],
 		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 50c369a..9ee37f4 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -415,6 +415,31 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain *domain,
+					  rte_be32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag);
+#else
+	(void)domain;
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -1016,6 +1041,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index 6b5dadf..82d6b10 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -9,6 +9,8 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include "rte_byteorder.h"
+
 /* Verbs headers do not support -pedantic. */
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
@@ -156,6 +158,10 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)
+					(struct mlx5dv_dr_domain *domain,
+					 rte_be32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 3/7] net/mlx5: support pop flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
direct verbs flow rules.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst               |  9 ++++
 doc/guides/rel_notes/release_19_11.rst |  6 +++
 drivers/net/mlx5/mlx5.c                |  9 ++++
 drivers/net/mlx5/mlx5.h                |  1 +
 drivers/net/mlx5/mlx5_flow.h           |  5 ++-
 drivers/net/mlx5/mlx5_flow_dv.c        | 78 ++++++++++++++++++++++++++++++++++
 6 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 4115520..20b607c 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -124,6 +124,11 @@ Limitations
 
   Will match any ipv4 packet (VLAN included).
 
+- VLAN pop offload command:
+  - Flow rules having a VLAN pop offload command as one of their actions and
+    are lacking a match on VLAN as one of their items are not supported.
+  - The command is not supported on egress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1032,6 +1037,10 @@ Supported hardware offloads
    |                       | | rdma-core 24  |     | N/A       |
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
+   | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
+   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
+   +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
 -----------------
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 27cfbd9..5c2ac15 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -223,3 +223,9 @@ Tested Platforms
    Also, make sure to start the actual text at the margin.
    =========================================================
 
+* **Updated Mellanox mlx5 driver.**
+
+  Updated Mellanox mlx5 driver with new features and improvements, including:
+
+  * Added support for VLAN pop flow offload command.
+
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 962c0d5..19c0091 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -549,6 +549,7 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = mlx5_glue->dr_create_flow_action_drop();
 	}
 #endif
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 	sh->dv_refcnt++;
 	priv->dr_shared = 1;
 	return 0;
@@ -571,6 +572,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	return err;
 #else
 	(void)priv;
@@ -616,6 +621,10 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = NULL;
 	}
 #endif
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	pthread_mutex_destroy(&sh->dv_mutex);
 #else
 	(void)priv;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index f559f83..4d457bf 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -570,6 +570,7 @@ struct mlx5_ibv_shared {
 	void *tx_domain; /* TX Direct Rules name space handle. */
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
 	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8d193b6..06b0470 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -154,7 +154,8 @@
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -171,6 +172,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 41500bc..2cb86e8 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -815,6 +815,61 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
+				 uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+
+	(void)action;
+	(void)attr;
+	if (!priv->sh->pop_vlan_action)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "pop vlan action is not supported");
+	/*
+	 * Check for inconsistencies:
+	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
+	 *  fail strip_vlan in a flow that matches packets without explicitly a
+	 *  matching on VLAN tag ?
+	 */
+	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "no support for multiple vlan pop "
+					  "actions");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "cannot pop vlan without a "
+					  "match on (outer) vlan in the flow");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3100,6 +3155,16 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (flow_dv_validate_action_pop_vlan(dev,
+							     action_flags,
+							     actions,
+							     item_flags, attr,
+							     error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -3273,6 +3338,13 @@ struct field_modify_info modify_tcp[] = {
 						  "action not supported");
 		}
 	}
+	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
+	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION,
+					  actions,
+					  "can't have vxlan and vlan"
+					  " actions in the same rule");
 	/* Eswitch has few restrictions on using items and actions */
 	if (attr->transfer) {
 		if (action_flags & MLX5_FLOW_ACTION_FLAG)
@@ -4791,6 +4863,12 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			dev_flow->dv.actions[actions_n++] =
+						priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 4/7] net/mlx5: support push flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN using
direct verbs flow rules.
If present in the flow, The VLAN default values are taken from the
VLAN item configuration.
In this commit only the VLAN TPID value can be set since VLAN
modification actions are not supported yet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst               |   6 +-
 doc/guides/rel_notes/release_19_11.rst |   1 +
 drivers/net/mlx5/mlx5.h                |   2 +
 drivers/net/mlx5/mlx5_flow.h           |  18 ++-
 drivers/net/mlx5/mlx5_flow_dv.c        | 264 +++++++++++++++++++++++++++++++++
 5 files changed, 287 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 20b607c..bb1e102 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -129,6 +129,8 @@ Limitations
     are lacking a match on VLAN as one of their items are not supported.
   - The command is not supported on egress traffic.
 
+- VLAN push offload is not supported on ingress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1038,8 +1040,8 @@ Supported hardware offloads
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
-   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
-   |                       | | ConnectX-5    | | ConnectX-5    |
+   | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
+   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 5c2ac15..afe92ab 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -228,4 +228,5 @@ Tested Platforms
   Updated Mellanox mlx5 driver with new features and improvements, including:
 
   * Added support for VLAN pop flow offload command.
+  * Added support for VLAN push flow offload command.
 
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 4d457bf..ae4a7c5 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
 	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
 	LIST_HEAD(port_id_action_list, mlx5_flow_dv_port_id_action_resource)
 		port_id_action_list; /* List of port ID actions. */
+	LIST_HEAD(push_vlan_action_list, mlx5_flow_dv_push_vlan_action_resource)
+		push_vlan_action_list; /* List of push VLAN actions. */
 	struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
 	/* Shared interrupt handler section. */
 	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 06b0470..15c9c04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -150,7 +150,8 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
@@ -172,7 +173,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
-#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
+				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
 	uint32_t port_id; /**< Port ID value. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action; /**< Direct verbs action object. */
+	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
+	rte_be32_t vlan_tag; /**< VLAN tag value. */
+};
+
 /*
  * Max number of actions per DV flow.
  * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
@@ -335,6 +347,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to port ID action resource. */
 	struct mlx5_vf_vlan vf_vlan;
 	/**< Structure for VF VLAN workaround. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
+	/**< Pointer to push VLAN action resource in cache. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
 	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
 	/**< Action list. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 2cb86e8..3a92846 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -50,6 +50,21 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+/* VLAN header definitions */
+#define FLOW_DV_VLAN_PCP_SHIFT 13
+#define FLOW_DV_VLAN_PCP_MASK RTE_BE16(0x7 << FLOW_DV_VLAN_PCP_SHIFT)
+#define FLOW_DV_VLAN_VID_MASK RTE_BE16(0x0fff)
+
+struct flow_dv_vlan_be {
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+	rte_be16_t tci;
+	rte_be16_t tpid;
+#else
+	rte_be16_t tpid;
+	rte_be16_t tci;
+#endif
+};
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -817,6 +832,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the pop VLAN action.
  *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
  * @param[in] action_flags
  *   Holds the actions detected until now.
  * @param[in] action
@@ -870,6 +887,86 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Get VLAN default info from vlan match info.
+ *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
+ * @param[in] item
+ *   the list of item specifications.
+ * @param[out] vlan
+ *   pointer VLAN info to fill to.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static void
+flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
+				   struct flow_dv_vlan_be *vlan)
+{
+	const struct rte_flow_item_vlan nic_mask = {
+		.tci = RTE_BE16(0x0fff),
+		.inner_type = RTE_BE16(0xffff),
+	};
+
+	if (items == NULL)
+		return;
+	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
+	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
+		;
+	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
+		const struct rte_flow_item_vlan *vlan_m = items->mask;
+		const struct rte_flow_item_vlan *vlan_v = items->spec;
+
+		if (!vlan_m)
+			vlan_m = &nic_mask;
+		if (vlan_m->tci == nic_mask.tci)
+			vlan->tci = vlan_v->tci & vlan_m->tci;
+		if (vlan_m->inner_type == nic_mask.inner_type)
+			vlan->tpid = vlan_v->inner_type & vlan_m->inner_type;
+	}
+}
+
+/**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_push_vlan *push_vlan = action->conf;
+
+	if (push_vlan->ethertype != RTE_BE16(0x8100) &&
+	    push_vlan->ethertype != RTE_BE16(0x88a8))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "invalid vlan ethertype");
+	if (action_flags &
+		(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "no support for multiple VLAN "
+					  "actions");
+	(void)attr;
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -1300,6 +1397,77 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Find existing push vlan resource or create and register a new one.
+ *
+ * @param dev[in, out]
+ *   Pointer to rte_eth_dev structure.
+ * @param[in, out] resource
+ *   Pointer to port ID action resource.
+ * @parm[in, out] dev_flow
+ *   Pointer to the dev_flow.
+ * @param[out] error
+ *   pointer to error structure.
+ *
+ * @return
+ *   0 on success otherwise -errno and errno is set.
+ */
+static int
+flow_dv_push_vlan_action_resource_register
+		       (struct rte_eth_dev *dev,
+			struct mlx5_flow_dv_push_vlan_action_resource *resource,
+			struct mlx5_flow *dev_flow,
+			struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+	struct mlx5_ibv_shared *sh = priv->sh;
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
+	struct mlx5dv_dr_domain *domain;
+
+	/* Lookup a matching resource from cache. */
+	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
+		if (resource->vlan_tag == cache_resource->vlan_tag &&
+		    resource->ft_type == cache_resource->ft_type) {
+			DRV_LOG(DEBUG, "push-VLAN action resource resource %p: "
+				"refcnt %d++",
+				(void *)cache_resource,
+				rte_atomic32_read(&cache_resource->refcnt));
+			rte_atomic32_inc(&cache_resource->refcnt);
+			dev_flow->dv.push_vlan_res = cache_resource;
+			return 0;
+		}
+	}
+	/* Register new push_vlan action resource. */
+	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
+	if (!cache_resource)
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "cannot allocate resource memory");
+	*cache_resource = *resource;
+	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
+		domain = sh->fdb_domain;
+	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
+		domain = sh->rx_domain;
+	else
+		domain = sh->tx_domain;
+	cache_resource->action =
+		mlx5_glue->dr_create_flow_action_push_vlan(domain,
+							   resource->vlan_tag);
+	if (!cache_resource->action) {
+		rte_free(cache_resource);
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL, "cannot create action");
+	}
+	rte_atomic32_init(&cache_resource->refcnt);
+	rte_atomic32_inc(&cache_resource->refcnt);
+	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource, next);
+	dev_flow->dv.push_vlan_res = cache_resource;
+	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	return 0;
+}
+/**
  * Get the size of specific rte_flow_item_type
  *
  * @param[in] item_type
@@ -1719,6 +1887,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const struct rte_flow_attr *attr,
+				const struct flow_dv_vlan_be *vlan,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource res;
+	union {
+		struct flow_dv_vlan_be vlan;
+		rte_be32_t tag;
+	} hdr;
+
+	hdr.vlan = *vlan;
+	res.vlan_tag = hdr.tag;
+	if (attr->transfer)
+		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
+	else
+		res.ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
+					     MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
+	return flow_dv_push_vlan_action_resource_register
+					    (dev, &res, dev_flow, error);
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -3165,6 +3374,15 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4755,7 +4973,9 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	struct flow_dv_vlan_be vlan = { 0 };
 
+	flow_dev_get_vlan_info_from_items(items, &vlan);
 	flow->group = attr->group;
 	if (attr->transfer)
 		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
@@ -4869,6 +5089,17 @@ struct field_modify_info modify_tcp[] = {
 						priv->sh->pop_vlan_action;
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			vlan.tpid =
+			     (((const struct rte_flow_action_of_push_vlan *)
+						     actions->conf)->ethertype);
+			if (flow_dv_create_action_push_vlan
+					    (dev, attr, &vlan, dev_flow, error))
+				return -rte_errno;
+			dev_flow->dv.actions[actions_n++] =
+					   dev_flow->dv.push_vlan_res->action;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -5517,6 +5748,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Release push vlan action resource.
+ *
+ * @param flow
+ *   Pointer to mlx5_flow.
+ *
+ * @return
+ *   1 while a reference on it exists, 0 when freed.
+ */
+static int
+flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
+		flow->dv.push_vlan_res;
+
+	assert(cache_resource->action);
+	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
+		claim_zero(mlx5_glue->destroy_flow_action
+				(cache_resource->action));
+		LIST_REMOVE(cache_resource, next);
+		rte_free(cache_resource);
+		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
+			(void *)cache_resource);
+		return 0;
+	}
+	return 1;
+}
+
+/**
  * Remove the flow from the NIC but keeps it in memory.
  *
  * @param[in] dev
@@ -5588,6 +5850,8 @@ struct field_modify_info modify_tcp[] = {
 			flow_dv_jump_tbl_resource_release(dev_flow);
 		if (dev_flow->dv.port_id_action)
 			flow_dv_port_id_action_resource_release(dev_flow);
+		if (dev_flow->dv.push_vlan_res)
+			flow_dv_push_vlan_action_resource_release(dev_flow);
 		rte_free(dev_flow);
 	}
 }
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VLAN priority (PCP) field
in about-to-be-pushed VLAN header.
This feature can only modify the PCP field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
v4:
- Fixed typo in an error message.
---
 doc/guides/nics/mlx5.rst               |  5 ++-
 doc/guides/rel_notes/release_19_11.rst |  1 +
 drivers/net/mlx5/mlx5_flow_dv.c        | 58 ++++++++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index bb1e102..98a0d43 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -131,6 +131,8 @@ Limitations
 
 - VLAN push offload is not supported on ingress traffic.
 
+- VLAN set PCP offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1041,7 +1043,8 @@ Supported hardware offloads
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
-   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
+   | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
+   | | of_set_vlan_pcp)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index afe92ab..5067a1c 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -229,4 +229,5 @@ Tested Platforms
 
   * Added support for VLAN pop flow offload command.
   * Added support for VLAN push flow offload command.
+  * Added support for VLAN set PCP offload command.
 
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 3a92846..f70e655 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -967,6 +967,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN PCP.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
+
+	if (conf->vlan_pcp > 7)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN PCP value is too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3383,6 +3424,13 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_set_vlan_pcp
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count PCP with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4973,6 +5021,7 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	uint16_t vlan_tci;
 	struct flow_dv_vlan_be vlan = { 0 };
 
 	flow_dev_get_vlan_info_from_items(items, &vlan);
@@ -5100,6 +5149,15 @@ struct field_modify_info modify_tcp[] = {
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			vlan_tci =
+			    ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			vlan_tci = vlan_tci << FLOW_DV_VLAN_PCP_SHIFT;
+			vlan.tci &= ~FLOW_DV_VLAN_PCP_MASK;
+			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 6/7] net/mlx5: supp modify VLAN ID on new VLAN header

[Moti Haimovsky]

This commit adds support for modifying the VLAN ID (VID) field
in an about-to-be-pushed VLAN header.
This feature can only modify the VID field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
v4:
- Fixed typo in an error message.
- Fixed bug in verifying VLAN VID value, used 0xFFFE instead of 0xFFE.
---
 doc/guides/nics/mlx5.rst               |  5 +++-
 doc/guides/rel_notes/release_19_11.rst |  1 +
 drivers/net/mlx5/mlx5_flow_dv.c        | 55 ++++++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 98a0d43..ea47b20 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -133,6 +133,8 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
+- VLAN set VID offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1044,7 +1046,8 @@ Supported hardware offloads
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
    | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
-   | | of_set_vlan_pcp)    |                 |                 |
+   | | of_set_vlan_pcp /   |                 |                 |
+   | | of_set_vlan_vid)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 5067a1c..66297d8 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -230,4 +230,5 @@ Tested Platforms
   * Added support for VLAN pop flow offload command.
   * Added support for VLAN push flow offload command.
   * Added support for VLAN set PCP offload command.
+  * Added support for VLAN set VID offload command.
 
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index f70e655..90e46df 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1008,6 +1008,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN VID.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
+
+	if (conf->vlan_vid > RTE_BE16(0xFFE))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN VID value is too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3431,6 +3472,13 @@ struct field_modify_info modify_tcp[] = {
 				return ret;
 			/* Count PCP with push_vlan command. */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			ret = flow_dv_validate_action_set_vlan_vid
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count VID with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -5158,6 +5206,13 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |= rte_cpu_to_be_16(vlan_tci);
 			/* Push VLAN command will use this value */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			vlan.tci &= ~FLOW_DV_VLAN_VID_MASK;
+			vlan.tci |=
+			    ((const struct rte_flow_action_of_set_vlan_vid *)
+						       actions->conf)->vlan_vid;
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v4 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VID of the outermost VLAN
header already present in the packet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        | 20 ++++-----
 drivers/net/mlx5/mlx5_flow.h    |  3 +-
 drivers/net/mlx5/mlx5_flow_dv.c | 90 +++++++++++++++++++++++++++++++++++------
 drivers/net/mlx5/mlx5_prm.h     |  1 +
 4 files changed, 92 insertions(+), 22 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index ea47b20..f8631bf 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -133,8 +133,6 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
-- VLAN set VID offload is not supported on existing headers.
-
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1020,13 +1018,17 @@ Supported hardware offloads
    | | (set_ipv4_src /     | | OFED 4.6-2    | | OFED 4.6-2    |
    | | set_ipv4_dst /      | | rdma-core 24  | | rdma-core 23  |
    | | set_ipv6_src /      | | ConnectX-5    | | ConnectX-5    |
-   | | set_ipv6_dst /      |                 |                 |
-   | | set_tp_src /        |                 |                 |
-   | | set_tp_dst /        |                 |                 |
-   | | dec_ttl /           |                 |                 |
-   | | set_ttl /           |                 |                 |
-   | | set_mac_src /       |                 |                 |
-   | | set_mac_dst)        |                 |                 |
+   | | set_ipv6_dst /      | |               | |               |
+   | | set_tp_src /        | |               | |               |
+   | | set_tp_dst /        | |               | |               |
+   | | dec_ttl /           | |               | |               |
+   | | set_ttl /           | |               | |               |
+   | | set_mac_src /       | |               | |               |
+   | | set_mac_dst)        | |               | |               |
+   | |                     | |               | |               |
+   | | (of_set_vlan_vid)   | | DPDK 19.11    | | DPDK 19.11    |
+   |                       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
    | Jump                  | | DPDK 19.05    | | DPDK 19.02    |
    |                       | | OFED 4.6-4    | | OFED 4.6-4    |
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 15c9c04..95abbb8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -171,7 +171,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
-				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
+				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
 
 #define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
 				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 90e46df..c683d61 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -123,6 +123,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan_out_first_vid[] = {
+	/* Size in bits !!! */
+	{12, 0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -405,6 +411,46 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set VLAN VID action to DV specification.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_vlan_vid
+			(struct mlx5_flow_dv_modify_hdr_resource *resource,
+			 const struct rte_flow_action *action,
+			 struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_set_vlan_vid *conf =
+		(const struct rte_flow_action_of_set_vlan_vid *)(action->conf);
+	int i = resource->actions_num;
+	struct mlx5_modification_cmd *actions = &resource->actions[i];
+	struct field_modify_info *field = modify_vlan_out_first_vid;
+
+	if (i >= MLX5_MODIFY_NUM)
+		return rte_flow_error_set(error, EINVAL,
+			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+			 "too many items to modify");
+	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
+	actions[i].field = field->id;
+	actions[i].length = field->size;
+	actions[i].offset = field->offset;
+	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
+	actions[i].data1 = conf->vlan_vid;
+	actions[i].data1 = actions[i].data1 << 16;
+	resource->actions_num = ++i;
+	return 0;
+}
+
+/**
  * Convert modify-header set TP action to DV specification.
  *
  * @param[in,out] resource
@@ -1010,8 +1056,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the set VLAN VID.
  *
- * @param[in] action_flags
- *   Holds the actions detected until now.
+ * @param[in] item_flags
+ *   Holds the items detected in this rule.
  * @param[in] actions
  *   Pointer to the list of actions remaining in the flow rule.
  * @param[in] attr
@@ -1023,7 +1069,7 @@ struct field_modify_info modify_tcp[] = {
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
 				     const struct rte_flow_action actions[],
 				     struct rte_flow_error *error)
 {
@@ -1034,17 +1080,27 @@ struct field_modify_info modify_tcp[] = {
 		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
 					  "VLAN VID value is too big");
+	/* If a push VLAN action follows then it will handle this action */
 	if (mlx5_flow_find_action(actions,
-				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+		return 0;
+
+	/*
+	 * Action is on an existing VLAN header:
+	 *    Need to verify this is a single modify CID action.
+	 *   Rule mast include a match on outer VLAN.
+	 */
+	if (mlx5_flow_find_action(++action,
+				  RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
 		return rte_flow_error_set(error, ENOTSUP,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID can only be used "
-					  "with push VLAN action");
-	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
-		return rte_flow_error_set(error, ENOTSUP,
+					  "Multiple VLAN VID modifications are "
+					  "not supported");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID action must precede "
-					  "the push VLAN action");
+					  "match on VLAN is required in order "
+					  "to set VLAN VID");
 	return 0;
 }
 
@@ -3474,7 +3530,7 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 			ret = flow_dv_validate_action_set_vlan_vid
-						(action_flags, actions, error);
+						(item_flags, actions, error);
 			if (ret < 0)
 				return ret;
 			/* Count VID with push_vlan command. */
@@ -5196,6 +5252,8 @@ struct field_modify_info modify_tcp[] = {
 			dev_flow->dv.actions[actions_n++] =
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			/* Push VLAN command is also handling this VLAN_VID */
+			action_flags &= ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			vlan_tci =
@@ -5211,7 +5269,15 @@ struct field_modify_info modify_tcp[] = {
 			vlan.tci |=
 			    ((const struct rte_flow_action_of_set_vlan_vid *)
 						       actions->conf)->vlan_vid;
-			/* Push VLAN command will use this value */
+			if (mlx5_flow_find_action
+				(actions,
+				 RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+				break;
+			/* If no VLAN push - this is a modify header action */
+			if (flow_dv_convert_action_modify_vlan_vid
+							(&res, actions, error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index d62837e..e5afc1c 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -413,6 +413,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

[dpdk-dev] [PATCH v5 0/7] net/mlx5: support for flow action on VLAN header

[Moti Haimovsky]

VLAN actions support is implemented in librte_ethdev, and in
test-pmd application, based on [1] Generic flow API.
These actions conform to the VLAN actions defined in
[2] the OpenFlow Switch Specification.

rte_flow defines the following VLAN actions:
 1. OF_POP_VLAN
    Pop the outer-most VLAN header from the packet.
 2. OF_PUSH_VLAN
    Push a new VLAN header onto the packet.
 3. OF_SET_VLAN_VID
    Sets the ID of the outermost VLAN tag.
 4. OF_SET_VLAN_PCP
    Sets the 3-bit priority field of the outermost VLAN tag.

This series of patches adds support for those VLAN actions
to the mlx5 PMD using the Direct Verbs interface.

v2:
- Code rebase on latest commits.

v3:
- mlx5 documentation update.

v4:
- Update the release notes with new the new features.
- Minor bug fixes.

v5:
- Rebase on top of latest commits.
- Minor bug fix in vlan push action.
- Bug fix in the format of the release notes.

Moti Haimovsky (7):
  net/mlx5: support for an action search in a list
  net/mlx5: add VLAN push/pop DR commands to glue
  net/mlx5: support pop flow action on VLAN header
  net/mlx5: support push flow action on VLAN header
  net/mlx5: support modify VLAN priority on VLAN hdr
  net/mlx5: supp modify VLAN ID on new VLAN header
  net/mlx5: supp modify VLAN ID on existing VLAN hdr

 doc/guides/nics/mlx5.rst               |  34 ++-
 doc/guides/rel_notes/release_19_11.rst |   9 +
 drivers/net/mlx5/Makefile              |   5 +
 drivers/net/mlx5/meson.build           |   2 +
 drivers/net/mlx5/mlx5.c                |   9 +
 drivers/net/mlx5/mlx5.h                |   4 +
 drivers/net/mlx5/mlx5_flow.c           |  23 ++
 drivers/net/mlx5/mlx5_flow.h           |  27 +-
 drivers/net/mlx5/mlx5_flow_dv.c        | 538 +++++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.c           |  29 ++
 drivers/net/mlx5/mlx5_glue.h           |   6 +
 drivers/net/mlx5/mlx5_prm.h            |   1 +
 12 files changed, 677 insertions(+), 10 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v5 1/7] net/mlx5: support for an action search in a list

[Moti Haimovsky]

This commit adds a helper routine that supports searching for a
specific action in a list of actions.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 78cc06f..eb36052 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -697,6 +697,29 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 }
 
 /*
+ * return a pointer to the desired action in the list of actions.
+ *
+ * @param[in] actions
+ *   The list of actions to search the action in.
+ * @param[in] action
+ *   The action to find.
+ *
+ * @return
+ *   Pointer to the action in the list, if found. NULL otherwise.
+ */
+const struct rte_flow_action *
+mlx5_flow_find_action(const struct rte_flow_action *actions,
+		      enum rte_flow_action_type action)
+{
+	if (actions == NULL)
+		return NULL;
+	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+		if (actions->type == action)
+			return actions;
+	return NULL;
+}
+
+/*
  * Validate the flag action.
  *
  * @param[in] action_flags
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 822ff36..8d193b6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct mlx5_flow *dev_flow, int tunnel,
 				     uint64_t hash_fields);
 uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
 				   uint32_t subpriority);
+const struct rte_flow_action *mlx5_flow_find_action
+					(const struct rte_flow_action *actions,
+					 enum rte_flow_action_type action);
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
 				    const struct rte_flow_attr *attr,
 				    struct rte_flow_error *error);
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 1/7] net/mlx5: support for an action search in a list

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 1/7] net/mlx5: support for an action search in a list
> 
> This commit adds a helper routine that supports searching for a specific
> action in a list of actions.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
>  drivers/net/mlx5/mlx5_flow.c | 23 +++++++++++++++++++++++
> drivers/net/mlx5/mlx5_flow.h |  3 +++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 78cc06f..eb36052 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -697,6 +697,29 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,  }
> 
>  /*
> + * return a pointer to the desired action in the list of actions.
> + *
> + * @param[in] actions
> + *   The list of actions to search the action in.
> + * @param[in] action
> + *   The action to find.
> + *
> + * @return
> + *   Pointer to the action in the list, if found. NULL otherwise.
> + */
> +const struct rte_flow_action *
> +mlx5_flow_find_action(const struct rte_flow_action *actions,
> +		      enum rte_flow_action_type action) {
> +	if (actions == NULL)
> +		return NULL;
> +	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
> +		if (actions->type == action)
> +			return actions;
> +	return NULL;
> +}
> +
> +/*
>   * Validate the flag action.
>   *
>   * @param[in] action_flags
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 822ff36..8d193b6 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -442,6 +442,9 @@ uint64_t mlx5_flow_hashfields_adjust(struct
> mlx5_flow *dev_flow, int tunnel,
>  				     uint64_t hash_fields);
>  uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
>  				   uint32_t subpriority);
> +const struct rte_flow_action *mlx5_flow_find_action
> +					(const struct rte_flow_action
> *actions,
> +					 enum rte_flow_action_type action);
>  int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
>  				    const struct rte_flow_attr *attr,
>  				    struct rte_flow_error *error);
> --
> 1.8.3.1

[dpdk-dev] [PATCH v5 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Moti Haimovsky]

This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
interface.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 drivers/net/mlx5/Makefile    |  5 +++++
 drivers/net/mlx5/meson.build |  2 ++
 drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_glue.h |  6 ++++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 9f6a7b4..d89a7b5 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -164,6 +164,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
 		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
 		$(AUTOCONF_OUTPUT)
 	$Q sh -- '$<' '$@' \
+		HAVE_MLX5DV_DR_VLAN \
+		infiniband/mlx5dv.h \
+		func mlx5dv_dr_action_create_push_vlan \
+		$(AUTOCONF_OUTPUT)
+	$Q sh -- '$<' '$@' \
 		HAVE_IBV_DEVX_OBJ \
 		infiniband/mlx5dv.h \
 		func mlx5dv_devx_obj_create \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 3072c44..fb764fa 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -132,6 +132,8 @@ if build
 		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
 		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
 		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
+		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
+		'mlx5dv_dr_action_create_push_vlan' ],
 		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
 		'SUPPORTED_40000baseKR4_Full' ],
 		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index 50c369a..9ee37f4 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -415,6 +415,31 @@
 }
 
 static void *
+mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain *domain,
+					  rte_be32_t vlan_tag)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag);
+#else
+	(void)domain;
+	(void)vlan_tag;
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
+mlx5_glue_dr_create_flow_action_pop_vlan(void)
+{
+#ifdef HAVE_MLX5DV_DR_VLAN
+	return mlx5dv_dr_action_create_pop_vlan();
+#else
+	errno = ENOTSUP;
+	return NULL;
+#endif
+}
+
+static void *
 mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)
 {
 #ifdef HAVE_MLX5DV_DR
@@ -1016,6 +1041,10 @@
 		mlx5_glue_dr_create_flow_action_dest_vport,
 	.dr_create_flow_action_drop =
 		mlx5_glue_dr_create_flow_action_drop,
+	.dr_create_flow_action_push_vlan =
+		mlx5_glue_dr_create_flow_action_push_vlan,
+	.dr_create_flow_action_pop_vlan =
+		mlx5_glue_dr_create_flow_action_pop_vlan,
 	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
 	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
 	.dr_create_domain = mlx5_glue_dr_create_domain,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index 6b5dadf..82d6b10 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -9,6 +9,8 @@
 #include <stddef.h>
 #include <stdint.h>
 
+#include "rte_byteorder.h"
+
 /* Verbs headers do not support -pedantic. */
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
@@ -156,6 +158,10 @@ struct mlx5_glue {
 	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
 	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t vport);
 	void *(*dr_create_flow_action_drop)();
+	void *(*dr_create_flow_action_push_vlan)
+					(struct mlx5dv_dr_domain *domain,
+					 rte_be32_t vlan_tag);
+	void *(*dr_create_flow_action_pop_vlan)();
 	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
 	int (*dr_destroy_flow_tbl)(void *tbl);
 	void *(*dr_create_domain)(struct ibv_context *ctx,
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 2/7] net/mlx5: add VLAN push/pop DR commands to glue

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 2/7] net/mlx5: add VLAN push/pop DR commands to glue
> 
> This commit adds the mlx5dv VLAN push and pop commands to mlx5_glue
> interface.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
>  drivers/net/mlx5/Makefile    |  5 +++++
>  drivers/net/mlx5/meson.build |  2 ++
>  drivers/net/mlx5/mlx5_glue.c | 29 +++++++++++++++++++++++++++++
> drivers/net/mlx5/mlx5_glue.h |  6 ++++++
>  4 files changed, 42 insertions(+)
> 
> diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile index
> 9f6a7b4..d89a7b5 100644
> --- a/drivers/net/mlx5/Makefile
> +++ b/drivers/net/mlx5/Makefile
> @@ -164,6 +164,11 @@ mlx5_autoconf.h.new:
> $(RTE_SDK)/buildtools/auto-config-h.sh
>  		enum MLX5DV_DR_DOMAIN_TYPE_FDB \
>  		$(AUTOCONF_OUTPUT)
>  	$Q sh -- '$<' '$@' \
> +		HAVE_MLX5DV_DR_VLAN \
> +		infiniband/mlx5dv.h \
> +		func mlx5dv_dr_action_create_push_vlan \
> +		$(AUTOCONF_OUTPUT)
> +	$Q sh -- '$<' '$@' \
>  		HAVE_IBV_DEVX_OBJ \
>  		infiniband/mlx5dv.h \
>  		func mlx5dv_devx_obj_create \
> diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
> index 3072c44..fb764fa 100644
> --- a/drivers/net/mlx5/meson.build
> +++ b/drivers/net/mlx5/meson.build
> @@ -132,6 +132,8 @@ if build
>  		'MLX5DV_DR_DOMAIN_TYPE_NIC_RX' ],
>  		[ 'HAVE_MLX5DV_DR_ESWITCH', 'infiniband/mlx5dv.h',
>  		'MLX5DV_DR_DOMAIN_TYPE_FDB' ],
> +		[ 'HAVE_MLX5DV_DR_VLAN', 'infiniband/mlx5dv.h',
> +		'mlx5dv_dr_action_create_push_vlan' ],
>  		[ 'HAVE_SUPPORTED_40000baseKR4_Full', 'linux/ethtool.h',
>  		'SUPPORTED_40000baseKR4_Full' ],
>  		[ 'HAVE_SUPPORTED_40000baseCR4_Full', 'linux/ethtool.h',
> diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
> index 50c369a..9ee37f4 100644
> --- a/drivers/net/mlx5/mlx5_glue.c
> +++ b/drivers/net/mlx5/mlx5_glue.c
> @@ -415,6 +415,31 @@
>  }
> 
>  static void *
> +mlx5_glue_dr_create_flow_action_push_vlan(struct mlx5dv_dr_domain
> *domain,
> +					  rte_be32_t vlan_tag)
> +{
> +#ifdef HAVE_MLX5DV_DR_VLAN
> +	return mlx5dv_dr_action_create_push_vlan(domain, vlan_tag); #else
> +	(void)domain;
> +	(void)vlan_tag;
> +	errno = ENOTSUP;
> +	return NULL;
> +#endif
> +}
> +
> +static void *
> +mlx5_glue_dr_create_flow_action_pop_vlan(void)
> +{
> +#ifdef HAVE_MLX5DV_DR_VLAN
> +	return mlx5dv_dr_action_create_pop_vlan();
> +#else
> +	errno = ENOTSUP;
> +	return NULL;
> +#endif
> +}
> +
> +static void *
>  mlx5_glue_dr_create_flow_tbl(void *domain, uint32_t level)  {  #ifdef
> HAVE_MLX5DV_DR @@ -1016,6 +1041,10 @@
>  		mlx5_glue_dr_create_flow_action_dest_vport,
>  	.dr_create_flow_action_drop =
>  		mlx5_glue_dr_create_flow_action_drop,
> +	.dr_create_flow_action_push_vlan =
> +		mlx5_glue_dr_create_flow_action_push_vlan,
> +	.dr_create_flow_action_pop_vlan =
> +		mlx5_glue_dr_create_flow_action_pop_vlan,
>  	.dr_create_flow_tbl = mlx5_glue_dr_create_flow_tbl,
>  	.dr_destroy_flow_tbl = mlx5_glue_dr_destroy_flow_tbl,
>  	.dr_create_domain = mlx5_glue_dr_create_domain, diff --git
> a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h index
> 6b5dadf..82d6b10 100644
> --- a/drivers/net/mlx5/mlx5_glue.h
> +++ b/drivers/net/mlx5/mlx5_glue.h
> @@ -9,6 +9,8 @@
>  #include <stddef.h>
>  #include <stdint.h>
> 
> +#include "rte_byteorder.h"
> +
>  /* Verbs headers do not support -pedantic. */  #ifdef PEDANTIC  #pragma
> GCC diagnostic ignored "-Wpedantic"
> @@ -156,6 +158,10 @@ struct mlx5_glue {
>  	void *(*dr_create_flow_action_dest_flow_tbl)(void *tbl);
>  	void *(*dr_create_flow_action_dest_vport)(void *domain, uint32_t
> vport);
>  	void *(*dr_create_flow_action_drop)();
> +	void *(*dr_create_flow_action_push_vlan)
> +					(struct mlx5dv_dr_domain *domain,
> +					 rte_be32_t vlan_tag);
> +	void *(*dr_create_flow_action_pop_vlan)();
>  	void *(*dr_create_flow_tbl)(void *domain, uint32_t level);
>  	int (*dr_destroy_flow_tbl)(void *tbl);
>  	void *(*dr_create_domain)(struct ibv_context *ctx,
> --
> 1.8.3.1

[dpdk-dev] [PATCH v5 3/7] net/mlx5: support pop flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
direct verbs flow rules.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst               | 10 +++++
 doc/guides/rel_notes/release_19_11.rst |  6 +++
 drivers/net/mlx5/mlx5.c                |  9 ++++
 drivers/net/mlx5/mlx5.h                |  2 +
 drivers/net/mlx5/mlx5_flow.h           |  5 ++-
 drivers/net/mlx5/mlx5_flow_dv.c        | 78 ++++++++++++++++++++++++++++++++++
 6 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 4115520..2ae2e8f 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -124,6 +124,12 @@ Limitations
 
   Will match any ipv4 packet (VLAN included).
 
+- VLAN pop offload command:
+
+  - Flow rules having a VLAN pop offload command as one of their actions and
+    are lacking a match on VLAN as one of their items are not supported.
+  - The command is not supported on egress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1032,6 +1038,10 @@ Supported hardware offloads
    |                       | | rdma-core 24  |     | N/A       |
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
+   | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
+   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
+   +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
 -----------------
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 27cfbd9..5c2ac15 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -223,3 +223,9 @@ Tested Platforms
    Also, make sure to start the actual text at the margin.
    =========================================================
 
+* **Updated Mellanox mlx5 driver.**
+
+  Updated Mellanox mlx5 driver with new features and improvements, including:
+
+  * Added support for VLAN pop flow offload command.
+
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index dc7b10b..8e10932 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -549,6 +549,7 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = mlx5_glue->dr_create_flow_action_drop();
 	}
 #endif
+	sh->pop_vlan_action = mlx5_glue->dr_create_flow_action_pop_vlan();
 	sh->dv_refcnt++;
 	priv->dr_shared = 1;
 	return 0;
@@ -571,6 +572,10 @@ struct mlx5_dev_spawn_data {
 		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
 		sh->esw_drop_action = NULL;
 	}
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	return err;
 #else
 	(void)priv;
@@ -616,6 +621,10 @@ struct mlx5_dev_spawn_data {
 		sh->esw_drop_action = NULL;
 	}
 #endif
+	if (sh->pop_vlan_action) {
+		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
+		sh->pop_vlan_action = NULL;
+	}
 	pthread_mutex_destroy(&sh->dv_mutex);
 #else
 	(void)priv;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 09ca4b1..a18f588 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -570,6 +570,8 @@ struct mlx5_ibv_shared {
 	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
 	/* TX Direct Rules tables. */
 	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
+	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
+	/* TX Direct Rules tables/ */
 	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
 	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource) encaps_decaps;
 	LIST_HEAD(modify_cmd, mlx5_flow_dv_modify_hdr_resource) modify_cmds;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8d193b6..06b0470 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -154,7 +154,8 @@
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
-				 MLX5_FLOW_ACTION_RAW_DECAP)
+				 MLX5_FLOW_ACTION_RAW_DECAP | \
+				 MLX5_FLOW_ACTION_OF_POP_VLAN)
 
 #define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
 				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
@@ -171,6 +172,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 7b2ba07..fd2e810 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -815,6 +815,61 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the pop VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the pop vlan action.
+ * @param[in] item_flags
+ *   The items found in this flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
+				 uint64_t action_flags,
+				 const struct rte_flow_action *action,
+				 uint64_t item_flags,
+				 const struct rte_flow_attr *attr,
+				 struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+
+	(void)action;
+	(void)attr;
+	if (!priv->sh->pop_vlan_action)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "pop vlan action is not supported");
+	/*
+	 * Check for inconsistencies:
+	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
+	 *  fail strip_vlan in a flow that matches packets without explicitly a
+	 *  matching on VLAN tag ?
+	 */
+	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "no support for multiple vlan pop "
+					  "actions");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL,
+					  "cannot pop vlan without a "
+					  "match on (outer) vlan in the flow");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3109,6 +3164,16 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_COUNT;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			if (flow_dv_validate_action_pop_vlan(dev,
+							     action_flags,
+							     actions,
+							     item_flags, attr,
+							     error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -3283,6 +3348,13 @@ struct field_modify_info modify_tcp[] = {
 						  "action not supported");
 		}
 	}
+	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
+	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION,
+					  actions,
+					  "can't have vxlan and vlan"
+					  " actions in the same rule");
 	/* Eswitch has few restrictions on using items and actions */
 	if (attr->transfer) {
 		if (action_flags & MLX5_FLOW_ACTION_FLAG)
@@ -4801,6 +4873,12 @@ struct field_modify_info modify_tcp[] = {
 						 action,
 						 "cannot create counter"
 						  " object.");
+			break;
+		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
+			dev_flow->dv.actions[actions_n++] =
+						priv->sh->pop_vlan_action;
+			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 3/7] net/mlx5: support pop flow action on VLAN header

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 3/7] net/mlx5: support pop flow action on VLAN header
> 
> This commit adds support for RTE_FLOW_ACTION_TYPE_OF_POP_VLAN via
> direct verbs flow rules.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
>  doc/guides/nics/mlx5.rst               | 10 +++++
>  doc/guides/rel_notes/release_19_11.rst |  6 +++
>  drivers/net/mlx5/mlx5.c                |  9 ++++
>  drivers/net/mlx5/mlx5.h                |  2 +
>  drivers/net/mlx5/mlx5_flow.h           |  5 ++-
>  drivers/net/mlx5/mlx5_flow_dv.c        | 78
> ++++++++++++++++++++++++++++++++++
>  6 files changed, 109 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 4115520..2ae2e8f 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -124,6 +124,12 @@ Limitations
> 
>    Will match any ipv4 packet (VLAN included).
> 
> +- VLAN pop offload command:
> +
> +  - Flow rules having a VLAN pop offload command as one of their actions
> and
> +    are lacking a match on VLAN as one of their items are not supported.
> +  - The command is not supported on egress traffic.
> +
>  - A multi segment packet must have not more segments than reported by
> dev_infos_get()
>    in tx_desc_lim.nb_seg_max field. This value depends on maximal supported
> Tx descriptor
>    size and ``txq_inline_min`` settings and may be from 2 (worst case forced
> by maximal @@ -1032,6 +1038,10 @@ Supported hardware offloads
>     |                       | | rdma-core 24  |     | N/A       |
>     |                       | | ConnectX-5    |     | N/A       |
>     +-----------------------+-----------------+-----------------+
> +   | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
> +   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
> +   |                       | | ConnectX-5    | | ConnectX-5    |
> +   +-----------------------+-----------------+-----------------+
> 
>  Notes for testpmd
>  -----------------
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index 27cfbd9..5c2ac15 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -223,3 +223,9 @@ Tested Platforms
>     Also, make sure to start the actual text at the margin.
>     =========================================================
> 
> +* **Updated Mellanox mlx5 driver.**
> +
> +  Updated Mellanox mlx5 driver with new features and improvements,
> including:
> +
> +  * Added support for VLAN pop flow offload command.
> +
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c index
> dc7b10b..8e10932 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -549,6 +549,7 @@ struct mlx5_dev_spawn_data {
>  		sh->esw_drop_action = mlx5_glue-
> >dr_create_flow_action_drop();
>  	}
>  #endif
> +	sh->pop_vlan_action = mlx5_glue-
> >dr_create_flow_action_pop_vlan();
>  	sh->dv_refcnt++;
>  	priv->dr_shared = 1;
>  	return 0;
> @@ -571,6 +572,10 @@ struct mlx5_dev_spawn_data {
>  		mlx5_glue->destroy_flow_action(sh->esw_drop_action);
>  		sh->esw_drop_action = NULL;
>  	}
> +	if (sh->pop_vlan_action) {
> +		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
> +		sh->pop_vlan_action = NULL;
> +	}
>  	return err;
>  #else
>  	(void)priv;
> @@ -616,6 +621,10 @@ struct mlx5_dev_spawn_data {
>  		sh->esw_drop_action = NULL;
>  	}
>  #endif
> +	if (sh->pop_vlan_action) {
> +		mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
> +		sh->pop_vlan_action = NULL;
> +	}
>  	pthread_mutex_destroy(&sh->dv_mutex);
>  #else
>  	(void)priv;
> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> 09ca4b1..a18f588 100644
> --- a/drivers/net/mlx5/mlx5.h
> +++ b/drivers/net/mlx5/mlx5.h
> @@ -570,6 +570,8 @@ struct mlx5_ibv_shared {
>  	struct mlx5_flow_tbl_resource tx_tbl[MLX5_MAX_TABLES];
>  	/* TX Direct Rules tables. */
>  	void *esw_drop_action; /* Pointer to DR E-Switch drop action. */
> +	void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
> +	/* TX Direct Rules tables/ */
>  	LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
>  	LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource)
> encaps_decaps;
>  	LIST_HEAD(modify_cmd, mlx5_flow_dv_modify_hdr_resource)
> modify_cmds; diff --git a/drivers/net/mlx5/mlx5_flow.h
> b/drivers/net/mlx5/mlx5_flow.h index 8d193b6..06b0470 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -154,7 +154,8 @@
> 
>  #define MLX5_FLOW_DECAP_ACTIONS
> 	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
>  				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
> -				 MLX5_FLOW_ACTION_RAW_DECAP)
> +				 MLX5_FLOW_ACTION_RAW_DECAP | \
> +				 MLX5_FLOW_ACTION_OF_POP_VLAN)
> 
>  #define MLX5_FLOW_MODIFY_HDR_ACTIONS
> (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
>  				      MLX5_FLOW_ACTION_SET_IPV4_DST | \
> @@ -171,6 +172,8 @@
>  				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
>  				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
> 
> +#define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN)
> +
>  #ifndef IPPROTO_MPLS
>  #define IPPROTO_MPLS 137
>  #endif
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 7b2ba07..fd2e810 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -815,6 +815,61 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Validate the pop VLAN action.
> + *
> + * @param[in] action_flags
> + *   Holds the actions detected until now.
> + * @param[in] action
> + *   Pointer to the pop vlan action.
> + * @param[in] item_flags
> + *   The items found in this flow rule.
> + * @param[in] attr
> + *   Pointer to flow attributes.
> + * @param[out] error
> + *   Pointer to error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_pop_vlan(struct rte_eth_dev *dev,
> +				 uint64_t action_flags,
> +				 const struct rte_flow_action *action,
> +				 uint64_t item_flags,
> +				 const struct rte_flow_attr *attr,
> +				 struct rte_flow_error *error)
> +{
> +	struct mlx5_priv *priv = dev->data->dev_private;
> +
> +	(void)action;
> +	(void)attr;
> +	if (!priv->sh->pop_vlan_action)
> +		return rte_flow_error_set(error, ENOTSUP,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> +					  NULL,
> +					  "pop vlan action is not supported");
> +	/*
> +	 * Check for inconsistencies:
> +	 *  fail strip_vlan in a flow that matches packets without VLAN tags.
> +	 *  fail strip_vlan in a flow that matches packets without explicitly a
> +	 *  matching on VLAN tag ?
> +	 */
> +	if (action_flags & MLX5_FLOW_ACTION_OF_POP_VLAN)
> +		return rte_flow_error_set(error, ENOTSUP,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> +					  NULL,
> +					  "no support for multiple vlan pop "
> +					  "actions");
> +	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
> +		return rte_flow_error_set(error, ENOTSUP,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> +					  NULL,
> +					  "cannot pop vlan without a "
> +					  "match on (outer) vlan in the flow");
> +	return 0;
> +}
> +
> +/**
>   * Validate count action.
>   *
>   * @param[in] dev
> @@ -3109,6 +3164,16 @@ struct field_modify_info modify_tcp[] = {
>  			action_flags |= MLX5_FLOW_ACTION_COUNT;
>  			++actions_n;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
> +			if (flow_dv_validate_action_pop_vlan(dev,
> +							     action_flags,
> +							     actions,
> +							     item_flags, attr,
> +							     error))
> +				return -rte_errno;
> +			action_flags |=
> MLX5_FLOW_ACTION_OF_POP_VLAN;
> +			++actions_n;
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			ret =
> flow_dv_validate_action_l2_encap(action_flags,
> @@ -3283,6 +3348,13 @@ struct field_modify_info modify_tcp[] = {
>  						  "action not supported");
>  		}
>  	}
> +	if ((action_flags & MLX5_FLOW_LAYER_TUNNEL) &&
> +	    (action_flags & MLX5_FLOW_VLAN_ACTIONS))
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> +					  actions,
> +					  "can't have vxlan and vlan"
> +					  " actions in the same rule");
>  	/* Eswitch has few restrictions on using items and actions */
>  	if (attr->transfer) {
>  		if (action_flags & MLX5_FLOW_ACTION_FLAG) @@ -4801,6
> +4873,12 @@ struct field_modify_info modify_tcp[] = {
>  						 action,
>  						 "cannot create counter"
>  						  " object.");
> +			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
> +			dev_flow->dv.actions[actions_n++] =
> +						priv->sh->pop_vlan_action;
> +			action_flags |=
> MLX5_FLOW_ACTION_OF_POP_VLAN;
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			if (flow_dv_create_action_l2_encap(dev, actions,
> --
> 1.8.3.1

[dpdk-dev] [PATCH v5 4/7] net/mlx5: support push flow action on VLAN header

[Moti Haimovsky]

This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN using
direct verbs flow rules.
If present in the flow, The VLAN default values are taken from the
VLAN item configuration.
In this commit only the VLAN TPID value can be set since VLAN
modification actions are not supported yet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
v5:
- Fixed bug in retrieving VLAN VID and PCP from the existing VLAN flow item.
---

 doc/guides/nics/mlx5.rst               |   6 +-
 doc/guides/rel_notes/release_19_11.rst |   1 +
 drivers/net/mlx5/mlx5.h                |   2 +
 drivers/net/mlx5/mlx5_flow.h           |  18 ++-
 drivers/net/mlx5/mlx5_flow_dv.c        | 272 +++++++++++++++++++++++++++++++++
 5 files changed, 295 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 2ae2e8f..875a87f 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -130,6 +130,8 @@ Limitations
     are lacking a match on VLAN as one of their items are not supported.
   - The command is not supported on egress traffic.
 
+- VLAN push offload is not supported on ingress traffic.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1039,8 +1041,8 @@ Supported hardware offloads
    |                       | | ConnectX-5    |     | N/A       |
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
-   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
-   |                       | | ConnectX-5    | | ConnectX-5    |
+   | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
+   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 5c2ac15..afe92ab 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -228,4 +228,5 @@ Tested Platforms
   Updated Mellanox mlx5 driver with new features and improvements, including:
 
   * Added support for VLAN pop flow offload command.
+  * Added support for VLAN push flow offload command.
 
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index a18f588..dbdc3ce 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
 	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
 	LIST_HEAD(port_id_action_list, mlx5_flow_dv_port_id_action_resource)
 		port_id_action_list; /* List of port ID actions. */
+	LIST_HEAD(push_vlan_action_list, mlx5_flow_dv_push_vlan_action_resource)
+		push_vlan_action_list; /* List of push VLAN actions. */
 	struct mlx5_flow_counter_mng cmng; /* Counters management structure. */
 	/* Shared interrupt handler section. */
 	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 06b0470..15c9c04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -150,7 +150,8 @@
 
 #define MLX5_FLOW_ENCAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
 				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
-				 MLX5_FLOW_ACTION_RAW_ENCAP)
+				 MLX5_FLOW_ACTION_RAW_ENCAP | \
+				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #define MLX5_FLOW_DECAP_ACTIONS	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
 				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
@@ -172,7 +173,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
 				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
 
-#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN)
+#define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
+				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
 
 #ifndef IPPROTO_MPLS
 #define IPPROTO_MPLS 137
@@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
 	uint32_t port_id; /**< Port ID value. */
 };
 
+/* Push VLAN action resource structure */
+struct mlx5_flow_dv_push_vlan_action_resource {
+	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
+	/* Pointer to next element. */
+	rte_atomic32_t refcnt; /**< Reference counter. */
+	void *action; /**< Direct verbs action object. */
+	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
+	rte_be32_t vlan_tag; /**< VLAN tag value. */
+};
+
 /*
  * Max number of actions per DV flow.
  * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
@@ -335,6 +347,8 @@ struct mlx5_flow_dv {
 	/**< Pointer to port ID action resource. */
 	struct mlx5_vf_vlan vf_vlan;
 	/**< Structure for VF VLAN workaround. */
+	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
+	/**< Pointer to push VLAN action resource in cache. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
 	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
 	/**< Action list. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index fd2e810..2780735 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -50,6 +50,13 @@
 #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1
 #endif
 
+/* VLAN header definitions */
+#define MLX5DV_FLOW_VLAN_PCP_SHIFT 13
+#define MLX5DV_FLOW_VLAN_PCP_MASK (0x7 << MLX5DV_FLOW_VLAN_PCP_SHIFT)
+#define MLX5DV_FLOW_VLAN_VID_MASK 0x0fff
+#define MLX5DV_FLOW_VLAN_PCP_MASK_BE RTE_BE16(MLX5DV_FLOW_VLAN_PCP_MASK)
+#define MLX5DV_FLOW_VLAN_VID_MASK_BE RTE_BE16(MLX5DV_FLOW_VLAN_VID_MASK)
+
 union flow_dv_attr {
 	struct {
 		uint32_t valid:1;
@@ -817,6 +824,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the pop VLAN action.
  *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
  * @param[in] action_flags
  *   Holds the actions detected until now.
  * @param[in] action
@@ -870,6 +879,101 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Get VLAN default info from vlan match info.
+ *
+ * @param[in] dev
+ *   Pointer to the rte_eth_dev structure.
+ * @param[in] item
+ *   the list of item specifications.
+ * @param[out] vlan
+ *   pointer VLAN info to fill to.
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static void
+flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
+				  struct rte_vlan_hdr *vlan)
+{
+	const struct rte_flow_item_vlan nic_mask = {
+		.tci = RTE_BE16(MLX5DV_FLOW_VLAN_PCP_MASK |
+				MLX5DV_FLOW_VLAN_VID_MASK),
+		.inner_type = RTE_BE16(0xffff),
+	};
+
+	if (items == NULL)
+		return;
+	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
+	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
+		;
+	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
+		const struct rte_flow_item_vlan *vlan_m = items->mask;
+		const struct rte_flow_item_vlan *vlan_v = items->spec;
+
+		if (!vlan_m)
+			vlan_m = &nic_mask;
+		/* Only full match values are accepted */
+		if ((vlan_m->tci & MLX5DV_FLOW_VLAN_PCP_MASK_BE) ==
+		     MLX5DV_FLOW_VLAN_PCP_MASK_BE) {
+			vlan->vlan_tci &= MLX5DV_FLOW_VLAN_PCP_MASK;
+			vlan->vlan_tci |=
+				rte_be_to_cpu_16(vlan_v->tci &
+						 MLX5DV_FLOW_VLAN_PCP_MASK_BE);
+		}
+		if ((vlan_m->tci & MLX5DV_FLOW_VLAN_VID_MASK_BE) ==
+		     MLX5DV_FLOW_VLAN_VID_MASK_BE) {
+			vlan->vlan_tci &= ~MLX5DV_FLOW_VLAN_VID_MASK;
+			vlan->vlan_tci |=
+				rte_be_to_cpu_16(vlan_v->tci &
+						 MLX5DV_FLOW_VLAN_VID_MASK_BE);
+		}
+		if (vlan_m->inner_type == nic_mask.inner_type)
+			vlan->eth_proto = rte_be_to_cpu_16(vlan_v->inner_type &
+							   vlan_m->inner_type);
+	}
+}
+
+/**
+ * Validate the push VLAN action.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] action
+ *   Pointer to the encap action.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_push_vlan(uint64_t action_flags,
+				  const struct rte_flow_action *action,
+				  const struct rte_flow_attr *attr,
+				  struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_push_vlan *push_vlan = action->conf;
+
+	if (push_vlan->ethertype != RTE_BE16(RTE_ETHER_TYPE_VLAN) &&
+	    push_vlan->ethertype != RTE_BE16(RTE_ETHER_TYPE_QINQ))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "invalid vlan ethertype");
+	if (action_flags &
+		(MLX5_FLOW_ACTION_OF_POP_VLAN | MLX5_FLOW_ACTION_OF_PUSH_VLAN))
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "no support for multiple VLAN "
+					  "actions");
+	(void)attr;
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -1300,6 +1404,77 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Find existing push vlan resource or create and register a new one.
+ *
+ * @param dev[in, out]
+ *   Pointer to rte_eth_dev structure.
+ * @param[in, out] resource
+ *   Pointer to port ID action resource.
+ * @parm[in, out] dev_flow
+ *   Pointer to the dev_flow.
+ * @param[out] error
+ *   pointer to error structure.
+ *
+ * @return
+ *   0 on success otherwise -errno and errno is set.
+ */
+static int
+flow_dv_push_vlan_action_resource_register
+		       (struct rte_eth_dev *dev,
+			struct mlx5_flow_dv_push_vlan_action_resource *resource,
+			struct mlx5_flow *dev_flow,
+			struct rte_flow_error *error)
+{
+	struct mlx5_priv *priv = dev->data->dev_private;
+	struct mlx5_ibv_shared *sh = priv->sh;
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
+	struct mlx5dv_dr_domain *domain;
+
+	/* Lookup a matching resource from cache. */
+	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
+		if (resource->vlan_tag == cache_resource->vlan_tag &&
+		    resource->ft_type == cache_resource->ft_type) {
+			DRV_LOG(DEBUG, "push-VLAN action resource resource %p: "
+				"refcnt %d++",
+				(void *)cache_resource,
+				rte_atomic32_read(&cache_resource->refcnt));
+			rte_atomic32_inc(&cache_resource->refcnt);
+			dev_flow->dv.push_vlan_res = cache_resource;
+			return 0;
+		}
+	}
+	/* Register new push_vlan action resource. */
+	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
+	if (!cache_resource)
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
+					  "cannot allocate resource memory");
+	*cache_resource = *resource;
+	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
+		domain = sh->fdb_domain;
+	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
+		domain = sh->rx_domain;
+	else
+		domain = sh->tx_domain;
+	cache_resource->action =
+		mlx5_glue->dr_create_flow_action_push_vlan(domain,
+							   resource->vlan_tag);
+	if (!cache_resource->action) {
+		rte_free(cache_resource);
+		return rte_flow_error_set(error, ENOMEM,
+					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+					  NULL, "cannot create action");
+	}
+	rte_atomic32_init(&cache_resource->refcnt);
+	rte_atomic32_inc(&cache_resource->refcnt);
+	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource, next);
+	dev_flow->dv.push_vlan_res = cache_resource;
+	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	return 0;
+}
+/**
  * Get the size of specific rte_flow_item_type
  *
  * @param[in] item_type
@@ -1719,6 +1894,44 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Create action push VLAN.
+ *
+ * @param[in] dev
+ *   Pointer to rte_eth_dev structure.
+ * @param[in] vlan_tag
+ *   the vlan tag to push to the Ethernet header.
+ * @param[in, out] dev_flow
+ *   Pointer to the mlx5_flow.
+ * @param[in] attr
+ *   Pointer to the flow attributes.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
+				const struct rte_flow_attr *attr,
+				const struct rte_vlan_hdr *vlan,
+				struct mlx5_flow *dev_flow,
+				struct rte_flow_error *error)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource res;
+
+	res.vlan_tag =
+		rte_cpu_to_be_32(((uint32_t)vlan->eth_proto) << 16 |
+				 vlan->vlan_tci);
+	if (attr->transfer)
+		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
+	else
+		res.ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
+					     MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
+	return flow_dv_push_vlan_action_resource_register
+					    (dev, &res, dev_flow, error);
+}
+
+/**
  * Validate the modify-header actions.
  *
  * @param[in] action_flags
@@ -3174,6 +3387,15 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			ret = flow_dv_validate_action_push_vlan(action_flags,
+								actions, attr,
+								error);
+			if (ret < 0)
+				return ret;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			++actions_n;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4765,6 +4987,8 @@ struct field_modify_info modify_tcp[] = {
 	void *match_mask = matcher.mask.buf;
 	void *match_value = dev_flow->dv.value.buf;
 	uint8_t next_protocol = 0xff;
+	struct rte_vlan_hdr vlan = { 0 };
+	bool vlan_inherited = false;
 
 	flow->group = attr->group;
 	if (attr->transfer)
@@ -4879,6 +5103,21 @@ struct field_modify_info modify_tcp[] = {
 						priv->sh->pop_vlan_action;
 			action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+			if (!vlan_inherited) {
+				flow_dev_get_vlan_info_from_items(items, &vlan);
+				vlan_inherited = true;
+			}
+			vlan.eth_proto = rte_be_to_cpu_16
+			     ((((const struct rte_flow_action_of_push_vlan *)
+						   actions->conf)->ethertype));
+			if (flow_dv_create_action_push_vlan
+					    (dev, attr, &vlan, dev_flow, error))
+				return -rte_errno;
+			dev_flow->dv.actions[actions_n++] =
+					   dev_flow->dv.push_vlan_res->action;
+			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
@@ -5526,6 +5765,37 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Release push vlan action resource.
+ *
+ * @param flow
+ *   Pointer to mlx5_flow.
+ *
+ * @return
+ *   1 while a reference on it exists, 0 when freed.
+ */
+static int
+flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow)
+{
+	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
+		flow->dv.push_vlan_res;
+
+	assert(cache_resource->action);
+	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
+		(void *)cache_resource,
+		rte_atomic32_read(&cache_resource->refcnt));
+	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
+		claim_zero(mlx5_glue->destroy_flow_action
+				(cache_resource->action));
+		LIST_REMOVE(cache_resource, next);
+		rte_free(cache_resource);
+		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
+			(void *)cache_resource);
+		return 0;
+	}
+	return 1;
+}
+
+/**
  * Remove the flow from the NIC but keeps it in memory.
  *
  * @param[in] dev
@@ -5597,6 +5867,8 @@ struct field_modify_info modify_tcp[] = {
 			flow_dv_jump_tbl_resource_release(dev_flow);
 		if (dev_flow->dv.port_id_action)
 			flow_dv_port_id_action_resource_release(dev_flow);
+		if (dev_flow->dv.push_vlan_res)
+			flow_dv_push_vlan_action_resource_release(dev_flow);
 		rte_free(dev_flow);
 	}
 }
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 4/7] net/mlx5: support push flow action on VLAN header

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 4/7] net/mlx5: support push flow action on VLAN header
> 
> This commit adds support for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN
> using direct verbs flow rules.
> If present in the flow, The VLAN default values are taken from the VLAN item
> configuration.
> In this commit only the VLAN TPID value can be set since VLAN modification
> actions are not supported yet.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
> v5:
> - Fixed bug in retrieving VLAN VID and PCP from the existing VLAN flow item.
> ---
> 
>  doc/guides/nics/mlx5.rst               |   6 +-
>  doc/guides/rel_notes/release_19_11.rst |   1 +
>  drivers/net/mlx5/mlx5.h                |   2 +
>  drivers/net/mlx5/mlx5_flow.h           |  18 ++-
>  drivers/net/mlx5/mlx5_flow_dv.c        | 272
> +++++++++++++++++++++++++++++++++
>  5 files changed, 295 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 2ae2e8f..875a87f 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -130,6 +130,8 @@ Limitations
>      are lacking a match on VLAN as one of their items are not supported.
>    - The command is not supported on egress traffic.
> 
> +- VLAN push offload is not supported on ingress traffic.
> +
>  - A multi segment packet must have not more segments than reported by
> dev_infos_get()
>    in tx_desc_lim.nb_seg_max field. This value depends on maximal supported
> Tx descriptor
>    size and ``txq_inline_min`` settings and may be from 2 (worst case forced
> by maximal @@ -1039,8 +1041,8 @@ Supported hardware offloads
>     |                       | | ConnectX-5    |     | N/A       |
>     +-----------------------+-----------------+-----------------+
>     | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
> -   | | (of_pop_vlan)       | | OFED 4.6-4    | | OFED 4.6-4    |
> -   |                       | | ConnectX-5    | | ConnectX-5    |
> +   | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
> +   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
>     +-----------------------+-----------------+-----------------+
> 
>  Notes for testpmd
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index 5c2ac15..afe92ab 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -228,4 +228,5 @@ Tested Platforms
>    Updated Mellanox mlx5 driver with new features and improvements,
> including:
> 
>    * Added support for VLAN pop flow offload command.
> +  * Added support for VLAN push flow offload command.
> 
> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> a18f588..dbdc3ce 100644
> --- a/drivers/net/mlx5/mlx5.h
> +++ b/drivers/net/mlx5/mlx5.h
> @@ -579,6 +579,8 @@ struct mlx5_ibv_shared {
>  	LIST_HEAD(jump, mlx5_flow_dv_jump_tbl_resource) jump_tbl;
>  	LIST_HEAD(port_id_action_list,
> mlx5_flow_dv_port_id_action_resource)
>  		port_id_action_list; /* List of port ID actions. */
> +	LIST_HEAD(push_vlan_action_list,
> mlx5_flow_dv_push_vlan_action_resource)
> +		push_vlan_action_list; /* List of push VLAN actions. */
>  	struct mlx5_flow_counter_mng cmng; /* Counters management
> structure. */
>  	/* Shared interrupt handler section. */
>  	pthread_mutex_t intr_mutex; /* Interrupt config mutex. */ diff --git
> a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h index
> 06b0470..15c9c04 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -150,7 +150,8 @@
> 
>  #define MLX5_FLOW_ENCAP_ACTIONS
> 	(MLX5_FLOW_ACTION_VXLAN_ENCAP | \
>  				 MLX5_FLOW_ACTION_NVGRE_ENCAP | \
> -				 MLX5_FLOW_ACTION_RAW_ENCAP)
> +				 MLX5_FLOW_ACTION_RAW_ENCAP | \
> +				 MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> 
>  #define MLX5_FLOW_DECAP_ACTIONS
> 	(MLX5_FLOW_ACTION_VXLAN_DECAP | \
>  				 MLX5_FLOW_ACTION_NVGRE_DECAP | \
> @@ -172,7 +173,8 @@
>  				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
>  				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
> 
> -#define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN)
> +#define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN | \
> +				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> 
>  #ifndef IPPROTO_MPLS
>  #define IPPROTO_MPLS 137
> @@ -309,6 +311,16 @@ struct mlx5_flow_dv_port_id_action_resource {
>  	uint32_t port_id; /**< Port ID value. */  };
> 
> +/* Push VLAN action resource structure */ struct
> +mlx5_flow_dv_push_vlan_action_resource {
> +	LIST_ENTRY(mlx5_flow_dv_push_vlan_action_resource) next;
> +	/* Pointer to next element. */
> +	rte_atomic32_t refcnt; /**< Reference counter. */
> +	void *action; /**< Direct verbs action object. */
> +	uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
> +	rte_be32_t vlan_tag; /**< VLAN tag value. */ };
> +
>  /*
>   * Max number of actions per DV flow.
>   * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
> @@ -335,6 +347,8 @@ struct mlx5_flow_dv {
>  	/**< Pointer to port ID action resource. */
>  	struct mlx5_vf_vlan vf_vlan;
>  	/**< Structure for VF VLAN workaround. */
> +	struct mlx5_flow_dv_push_vlan_action_resource *push_vlan_res;
> +	/**< Pointer to push VLAN action resource in cache. */
>  #ifdef HAVE_IBV_FLOW_DV_SUPPORT
>  	void *actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
>  	/**< Action list. */
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index fd2e810..2780735 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -50,6 +50,13 @@
>  #define MLX5DV_DR_ACTION_FLAGS_ROOT_LEVEL 1  #endif
> 
> +/* VLAN header definitions */
> +#define MLX5DV_FLOW_VLAN_PCP_SHIFT 13
> +#define MLX5DV_FLOW_VLAN_PCP_MASK (0x7 <<
> MLX5DV_FLOW_VLAN_PCP_SHIFT)
> +#define MLX5DV_FLOW_VLAN_VID_MASK 0x0fff #define
> +MLX5DV_FLOW_VLAN_PCP_MASK_BE
> RTE_BE16(MLX5DV_FLOW_VLAN_PCP_MASK)
> +#define MLX5DV_FLOW_VLAN_VID_MASK_BE
> +RTE_BE16(MLX5DV_FLOW_VLAN_VID_MASK)
> +
>  union flow_dv_attr {
>  	struct {
>  		uint32_t valid:1;
> @@ -817,6 +824,8 @@ struct field_modify_info modify_tcp[] = {
>  /**
>   * Validate the pop VLAN action.
>   *
> + * @param[in] dev
> + *   Pointer to the rte_eth_dev structure.
>   * @param[in] action_flags
>   *   Holds the actions detected until now.
>   * @param[in] action
> @@ -870,6 +879,101 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Get VLAN default info from vlan match info.
> + *
> + * @param[in] dev
> + *   Pointer to the rte_eth_dev structure.
> + * @param[in] item
> + *   the list of item specifications.
> + * @param[out] vlan
> + *   pointer VLAN info to fill to.
> + * @param[out] error
> + *   Pointer to error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static void
> +flow_dev_get_vlan_info_from_items(const struct rte_flow_item *items,
> +				  struct rte_vlan_hdr *vlan)
> +{
> +	const struct rte_flow_item_vlan nic_mask = {
> +		.tci = RTE_BE16(MLX5DV_FLOW_VLAN_PCP_MASK |
> +				MLX5DV_FLOW_VLAN_VID_MASK),
> +		.inner_type = RTE_BE16(0xffff),
> +	};
> +
> +	if (items == NULL)
> +		return;
> +	for (; items->type != RTE_FLOW_ITEM_TYPE_END &&
> +	       items->type != RTE_FLOW_ITEM_TYPE_VLAN; items++)
> +		;
> +	if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
> +		const struct rte_flow_item_vlan *vlan_m = items->mask;
> +		const struct rte_flow_item_vlan *vlan_v = items->spec;
> +
> +		if (!vlan_m)
> +			vlan_m = &nic_mask;
> +		/* Only full match values are accepted */
> +		if ((vlan_m->tci & MLX5DV_FLOW_VLAN_PCP_MASK_BE) ==
> +		     MLX5DV_FLOW_VLAN_PCP_MASK_BE) {
> +			vlan->vlan_tci &= MLX5DV_FLOW_VLAN_PCP_MASK;
> +			vlan->vlan_tci |=
> +				rte_be_to_cpu_16(vlan_v->tci &
> +
> MLX5DV_FLOW_VLAN_PCP_MASK_BE);
> +		}
> +		if ((vlan_m->tci & MLX5DV_FLOW_VLAN_VID_MASK_BE) ==
> +		     MLX5DV_FLOW_VLAN_VID_MASK_BE) {
> +			vlan->vlan_tci &=
> ~MLX5DV_FLOW_VLAN_VID_MASK;
> +			vlan->vlan_tci |=
> +				rte_be_to_cpu_16(vlan_v->tci &
> +
> MLX5DV_FLOW_VLAN_VID_MASK_BE);
> +		}
> +		if (vlan_m->inner_type == nic_mask.inner_type)
> +			vlan->eth_proto = rte_be_to_cpu_16(vlan_v-
> >inner_type &
> +							   vlan_m-
> >inner_type);
> +	}
> +}
> +
> +/**
> + * Validate the push VLAN action.
> + *
> + * @param[in] action_flags
> + *   Holds the actions detected until now.
> + * @param[in] action
> + *   Pointer to the encap action.
> + * @param[in] attr
> + *   Pointer to flow attributes
> + * @param[out] error
> + *   Pointer to error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_push_vlan(uint64_t action_flags,
> +				  const struct rte_flow_action *action,
> +				  const struct rte_flow_attr *attr,
> +				  struct rte_flow_error *error)
> +{
> +	const struct rte_flow_action_of_push_vlan *push_vlan = action-
> >conf;
> +
> +	if (push_vlan->ethertype != RTE_BE16(RTE_ETHER_TYPE_VLAN) &&
> +	    push_vlan->ethertype != RTE_BE16(RTE_ETHER_TYPE_QINQ))
> +		return rte_flow_error_set(error, EINVAL,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "invalid vlan ethertype");
> +	if (action_flags &
> +		(MLX5_FLOW_ACTION_OF_POP_VLAN |
> MLX5_FLOW_ACTION_OF_PUSH_VLAN))
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "no support for multiple VLAN "
> +					  "actions");
> +	(void)attr;
> +	return 0;
> +}
> +
> +/**
>   * Validate count action.
>   *
>   * @param[in] dev
> @@ -1300,6 +1404,77 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Find existing push vlan resource or create and register a new one.
> + *
> + * @param dev[in, out]
> + *   Pointer to rte_eth_dev structure.
> + * @param[in, out] resource
> + *   Pointer to port ID action resource.
> + * @parm[in, out] dev_flow
> + *   Pointer to the dev_flow.
> + * @param[out] error
> + *   pointer to error structure.
> + *
> + * @return
> + *   0 on success otherwise -errno and errno is set.
> + */
> +static int
> +flow_dv_push_vlan_action_resource_register
> +		       (struct rte_eth_dev *dev,
> +			struct mlx5_flow_dv_push_vlan_action_resource
> *resource,
> +			struct mlx5_flow *dev_flow,
> +			struct rte_flow_error *error)
> +{
> +	struct mlx5_priv *priv = dev->data->dev_private;
> +	struct mlx5_ibv_shared *sh = priv->sh;
> +	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource;
> +	struct mlx5dv_dr_domain *domain;
> +
> +	/* Lookup a matching resource from cache. */
> +	LIST_FOREACH(cache_resource, &sh->push_vlan_action_list, next) {
> +		if (resource->vlan_tag == cache_resource->vlan_tag &&
> +		    resource->ft_type == cache_resource->ft_type) {
> +			DRV_LOG(DEBUG, "push-VLAN action resource
> resource %p: "
> +				"refcnt %d++",
> +				(void *)cache_resource,
> +				rte_atomic32_read(&cache_resource-
> >refcnt));
> +			rte_atomic32_inc(&cache_resource->refcnt);
> +			dev_flow->dv.push_vlan_res = cache_resource;
> +			return 0;
> +		}
> +	}
> +	/* Register new push_vlan action resource. */
> +	cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource),
> 0);
> +	if (!cache_resource)
> +		return rte_flow_error_set(error, ENOMEM,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> +					  "cannot allocate resource
> memory");
> +	*cache_resource = *resource;
> +	if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_FDB)
> +		domain = sh->fdb_domain;
> +	else if (resource->ft_type == MLX5DV_FLOW_TABLE_TYPE_NIC_RX)
> +		domain = sh->rx_domain;
> +	else
> +		domain = sh->tx_domain;
> +	cache_resource->action =
> +		mlx5_glue->dr_create_flow_action_push_vlan(domain,
> +							   resource-
> >vlan_tag);
> +	if (!cache_resource->action) {
> +		rte_free(cache_resource);
> +		return rte_flow_error_set(error, ENOMEM,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> +					  NULL, "cannot create action");
> +	}
> +	rte_atomic32_init(&cache_resource->refcnt);
> +	rte_atomic32_inc(&cache_resource->refcnt);
> +	LIST_INSERT_HEAD(&sh->push_vlan_action_list, cache_resource,
> next);
> +	dev_flow->dv.push_vlan_res = cache_resource;
> +	DRV_LOG(DEBUG, "new push vlan action resource %p: refcnt %d++",
> +		(void *)cache_resource,
> +		rte_atomic32_read(&cache_resource->refcnt));
> +	return 0;
> +}
> +/**
>   * Get the size of specific rte_flow_item_type
>   *
>   * @param[in] item_type
> @@ -1719,6 +1894,44 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Create action push VLAN.
> + *
> + * @param[in] dev
> + *   Pointer to rte_eth_dev structure.
> + * @param[in] vlan_tag
> + *   the vlan tag to push to the Ethernet header.
> + * @param[in, out] dev_flow
> + *   Pointer to the mlx5_flow.
> + * @param[in] attr
> + *   Pointer to the flow attributes.
> + * @param[out] error
> + *   Pointer to the error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_create_action_push_vlan(struct rte_eth_dev *dev,
> +				const struct rte_flow_attr *attr,
> +				const struct rte_vlan_hdr *vlan,
> +				struct mlx5_flow *dev_flow,
> +				struct rte_flow_error *error)
> +{
> +	struct mlx5_flow_dv_push_vlan_action_resource res;
> +
> +	res.vlan_tag =
> +		rte_cpu_to_be_32(((uint32_t)vlan->eth_proto) << 16 |
> +				 vlan->vlan_tci);
> +	if (attr->transfer)
> +		res.ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
> +	else
> +		res.ft_type = attr->egress ?
> MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
> +
> MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
> +	return flow_dv_push_vlan_action_resource_register
> +					    (dev, &res, dev_flow, error);
> +}
> +
> +/**
>   * Validate the modify-header actions.
>   *
>   * @param[in] action_flags
> @@ -3174,6 +3387,15 @@ struct field_modify_info modify_tcp[] = {
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_POP_VLAN;
>  			++actions_n;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
> +			ret =
> flow_dv_validate_action_push_vlan(action_flags,
> +								actions, attr,
> +								error);
> +			if (ret < 0)
> +				return ret;
> +			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
> +			++actions_n;
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			ret =
> flow_dv_validate_action_l2_encap(action_flags,
> @@ -4765,6 +4987,8 @@ struct field_modify_info modify_tcp[] = {
>  	void *match_mask = matcher.mask.buf;
>  	void *match_value = dev_flow->dv.value.buf;
>  	uint8_t next_protocol = 0xff;
> +	struct rte_vlan_hdr vlan = { 0 };
> +	bool vlan_inherited = false;
> 
>  	flow->group = attr->group;
>  	if (attr->transfer)
> @@ -4879,6 +5103,21 @@ struct field_modify_info modify_tcp[] = {
>  						priv->sh->pop_vlan_action;
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_POP_VLAN;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
> +			if (!vlan_inherited) {
> +				flow_dev_get_vlan_info_from_items(items,
> &vlan);
> +				vlan_inherited = true;
> +			}
> +			vlan.eth_proto = rte_be_to_cpu_16
> +			     ((((const struct rte_flow_action_of_push_vlan *)
> +						   actions->conf)-
> >ethertype));
> +			if (flow_dv_create_action_push_vlan
> +					    (dev, attr, &vlan, dev_flow, error))
> +				return -rte_errno;
> +			dev_flow->dv.actions[actions_n++] =
> +					   dev_flow->dv.push_vlan_res-
> >action;
> +			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			if (flow_dv_create_action_l2_encap(dev, actions,
> @@ -5526,6 +5765,37 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Release push vlan action resource.
> + *
> + * @param flow
> + *   Pointer to mlx5_flow.
> + *
> + * @return
> + *   1 while a reference on it exists, 0 when freed.
> + */
> +static int
> +flow_dv_push_vlan_action_resource_release(struct mlx5_flow *flow) {
> +	struct mlx5_flow_dv_push_vlan_action_resource *cache_resource =
> +		flow->dv.push_vlan_res;
> +
> +	assert(cache_resource->action);
> +	DRV_LOG(DEBUG, "push VLAN action resource %p: refcnt %d--",
> +		(void *)cache_resource,
> +		rte_atomic32_read(&cache_resource->refcnt));
> +	if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
> +		claim_zero(mlx5_glue->destroy_flow_action
> +				(cache_resource->action));
> +		LIST_REMOVE(cache_resource, next);
> +		rte_free(cache_resource);
> +		DRV_LOG(DEBUG, "push vlan action resource %p: removed",
> +			(void *)cache_resource);
> +		return 0;
> +	}
> +	return 1;
> +}
> +
> +/**
>   * Remove the flow from the NIC but keeps it in memory.
>   *
>   * @param[in] dev
> @@ -5597,6 +5867,8 @@ struct field_modify_info modify_tcp[] = {
>  			flow_dv_jump_tbl_resource_release(dev_flow);
>  		if (dev_flow->dv.port_id_action)
> 
> 	flow_dv_port_id_action_resource_release(dev_flow);
> +		if (dev_flow->dv.push_vlan_res)
> +
> 	flow_dv_push_vlan_action_resource_release(dev_flow);
>  		rte_free(dev_flow);
>  	}
>  }
> --
> 1.8.3.1

[dpdk-dev] [PATCH v5 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VLAN priority (PCP) field
in about-to-be-pushed VLAN header.
This feature can only modify the PCP field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
v4:
- Fixed typo in an error message.
---
 doc/guides/nics/mlx5.rst               |  5 ++-
 doc/guides/rel_notes/release_19_11.rst |  1 +
 drivers/net/mlx5/mlx5_flow_dv.c        | 62 ++++++++++++++++++++++++++++++++++
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 875a87f..01215f4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -132,6 +132,8 @@ Limitations
 
 - VLAN push offload is not supported on ingress traffic.
 
+- VLAN set PCP offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1042,7 +1044,8 @@ Supported hardware offloads
    +-----------------------+-----------------+-----------------+
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
-   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
+   | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
+   | | of_set_vlan_pcp)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index afe92ab..5067a1c 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -229,4 +229,5 @@ Tested Platforms
 
   * Added support for VLAN pop flow offload command.
   * Added support for VLAN push flow offload command.
+  * Added support for VLAN set PCP offload command.
 
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 2780735..73459a0 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -974,6 +974,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN PCP.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
+
+	if (conf->vlan_pcp > 7)
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN PCP value is too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN PCP action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3396,6 +3437,13 @@ struct field_modify_info modify_tcp[] = {
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			++actions_n;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			ret = flow_dv_validate_action_set_vlan_pcp
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count PCP with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -4989,6 +5037,7 @@ struct field_modify_info modify_tcp[] = {
 	uint8_t next_protocol = 0xff;
 	struct rte_vlan_hdr vlan = { 0 };
 	bool vlan_inherited = false;
+	uint16_t vlan_tci;
 
 	flow->group = attr->group;
 	if (attr->transfer)
@@ -5118,6 +5167,19 @@ struct field_modify_info modify_tcp[] = {
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
+			if (!vlan_inherited) {
+				flow_dev_get_vlan_info_from_items(items, &vlan);
+				vlan_inherited = true;
+			}
+			vlan_tci =
+			    ((const struct rte_flow_action_of_set_vlan_pcp *)
+						       actions->conf)->vlan_pcp;
+			vlan_tci = vlan_tci << MLX5DV_FLOW_VLAN_PCP_SHIFT;
+			vlan.vlan_tci &= ~MLX5DV_FLOW_VLAN_PCP_MASK;
+			vlan.vlan_tci |= vlan_tci;
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 5/7] net/mlx5: support modify VLAN priority on VLAN hdr
> 
> This commit adds support for modifying the VLAN priority (PCP) field in
> about-to-be-pushed VLAN header.
> This feature can only modify the PCP field of a new VLAN header yet to be
> pushed. It does not support modifying an existing or already pushed VLAN
> headers.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
> v4:
> - Fixed typo in an error message.
> ---
>  doc/guides/nics/mlx5.rst               |  5 ++-
>  doc/guides/rel_notes/release_19_11.rst |  1 +
>  drivers/net/mlx5/mlx5_flow_dv.c        | 62
> ++++++++++++++++++++++++++++++++++
>  3 files changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 875a87f..01215f4 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -132,6 +132,8 @@ Limitations
> 
>  - VLAN push offload is not supported on ingress traffic.
> 
> +- VLAN set PCP offload is not supported on existing headers.
> +
>  - A multi segment packet must have not more segments than reported by
> dev_infos_get()
>    in tx_desc_lim.nb_seg_max field. This value depends on maximal supported
> Tx descriptor
>    size and ``txq_inline_min`` settings and may be from 2 (worst case forced
> by maximal @@ -1042,7 +1044,8 @@ Supported hardware offloads
>     +-----------------------+-----------------+-----------------+
>     | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
>     | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
> -   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
> +   | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
> +   | | of_set_vlan_pcp)    |                 |                 |
>     +-----------------------+-----------------+-----------------+
> 
>  Notes for testpmd
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index afe92ab..5067a1c 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -229,4 +229,5 @@ Tested Platforms
> 
>    * Added support for VLAN pop flow offload command.
>    * Added support for VLAN push flow offload command.
> +  * Added support for VLAN set PCP offload command.
> 
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 2780735..73459a0 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -974,6 +974,47 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Validate the set VLAN PCP.
> + *
> + * @param[in] action_flags
> + *   Holds the actions detected until now.
> + * @param[in] actions
> + *   Pointer to the list of actions remaining in the flow rule.
> + * @param[in] attr
> + *   Pointer to flow attributes
> + * @param[out] error
> + *   Pointer to error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
> +				     const struct rte_flow_action actions[],
> +				     struct rte_flow_error *error)
> +{
> +	const struct rte_flow_action *action = actions;
> +	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
> +
> +	if (conf->vlan_pcp > 7)
> +		return rte_flow_error_set(error, EINVAL,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "VLAN PCP value is too big");
> +	if (mlx5_flow_find_action(actions,
> +
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "set VLAN PCP can only be used "
> +					  "with push VLAN action");
> +	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "set VLAN PCP action must precede
> "
> +					  "the push VLAN action");
> +	return 0;
> +}
> +
> +/**
>   * Validate count action.
>   *
>   * @param[in] dev
> @@ -3396,6 +3437,13 @@ struct field_modify_info modify_tcp[] = {
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
>  			++actions_n;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
> +			ret = flow_dv_validate_action_set_vlan_pcp
> +						(action_flags, actions, error);
> +			if (ret < 0)
> +				return ret;
> +			/* Count PCP with push_vlan command. */
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			ret =
> flow_dv_validate_action_l2_encap(action_flags,
> @@ -4989,6 +5037,7 @@ struct field_modify_info modify_tcp[] = {
>  	uint8_t next_protocol = 0xff;
>  	struct rte_vlan_hdr vlan = { 0 };
>  	bool vlan_inherited = false;
> +	uint16_t vlan_tci;
> 
>  	flow->group = attr->group;
>  	if (attr->transfer)
> @@ -5118,6 +5167,19 @@ struct field_modify_info modify_tcp[] = {
>  					   dev_flow->dv.push_vlan_res-
> >action;
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
> +			if (!vlan_inherited) {
> +				flow_dev_get_vlan_info_from_items(items,
> &vlan);
> +				vlan_inherited = true;
> +			}
> +			vlan_tci =
> +			    ((const struct rte_flow_action_of_set_vlan_pcp *)
> +						       actions->conf)-
> >vlan_pcp;
> +			vlan_tci = vlan_tci <<
> MLX5DV_FLOW_VLAN_PCP_SHIFT;
> +			vlan.vlan_tci &= ~MLX5DV_FLOW_VLAN_PCP_MASK;
> +			vlan.vlan_tci |= vlan_tci;
> +			/* Push VLAN command will use this value */
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			if (flow_dv_create_action_l2_encap(dev, actions,
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH v5 5/7] net/mlx5: support modify VLAN priority on VLAN hdr

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 5/7] net/mlx5: support modify VLAN priority on VLAN hdr
> 
> This commit adds support for modifying the VLAN priority (PCP) field in
> about-to-be-pushed VLAN header.
> This feature can only modify the PCP field of a new VLAN header yet to be
> pushed. It does not support modifying an existing or already pushed VLAN
> headers.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
> v4:
> - Fixed typo in an error message.
> ---
>  doc/guides/nics/mlx5.rst               |  5 ++-
>  doc/guides/rel_notes/release_19_11.rst |  1 +
>  drivers/net/mlx5/mlx5_flow_dv.c        | 62
> ++++++++++++++++++++++++++++++++++
>  3 files changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 875a87f..01215f4 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -132,6 +132,8 @@ Limitations
> 
>  - VLAN push offload is not supported on ingress traffic.
> 
> +- VLAN set PCP offload is not supported on existing headers.
> +
>  - A multi segment packet must have not more segments than reported by
> dev_infos_get()
>    in tx_desc_lim.nb_seg_max field. This value depends on maximal supported
> Tx descriptor
>    size and ``txq_inline_min`` settings and may be from 2 (worst case forced
> by maximal @@ -1042,7 +1044,8 @@ Supported hardware offloads
>     +-----------------------+-----------------+-----------------+
>     | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
>     | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
> -   | | of_push_vlan)       | | ConnectX-5    | | ConnectX-5    |
> +   | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
> +   | | of_set_vlan_pcp)    |                 |                 |
>     +-----------------------+-----------------+-----------------+
> 
>  Notes for testpmd
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index afe92ab..5067a1c 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -229,4 +229,5 @@ Tested Platforms
> 
>    * Added support for VLAN pop flow offload command.
>    * Added support for VLAN push flow offload command.
> +  * Added support for VLAN set PCP offload command.
> 
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 2780735..73459a0 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -974,6 +974,47 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Validate the set VLAN PCP.
> + *
> + * @param[in] action_flags
> + *   Holds the actions detected until now.
> + * @param[in] actions
> + *   Pointer to the list of actions remaining in the flow rule.
> + * @param[in] attr
> + *   Pointer to flow attributes
> + * @param[out] error
> + *   Pointer to error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_set_vlan_pcp(uint64_t action_flags,
> +				     const struct rte_flow_action actions[],
> +				     struct rte_flow_error *error)
> +{
> +	const struct rte_flow_action *action = actions;
> +	const struct rte_flow_action_of_set_vlan_pcp *conf = action->conf;
> +
> +	if (conf->vlan_pcp > 7)
> +		return rte_flow_error_set(error, EINVAL,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "VLAN PCP value is too big");
> +	if (mlx5_flow_find_action(actions,
> +
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "set VLAN PCP can only be used "
> +					  "with push VLAN action");
> +	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> +		return rte_flow_error_set(error, ENOTSUP,
> +					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> +					  "set VLAN PCP action must precede
> "
> +					  "the push VLAN action");
> +	return 0;
> +}
> +
> +/**
>   * Validate count action.
>   *
>   * @param[in] dev
> @@ -3396,6 +3437,13 @@ struct field_modify_info modify_tcp[] = {
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
>  			++actions_n;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
> +			ret = flow_dv_validate_action_set_vlan_pcp
> +						(action_flags, actions, error);
> +			if (ret < 0)
> +				return ret;
> +			/* Count PCP with push_vlan command. */
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			ret =
> flow_dv_validate_action_l2_encap(action_flags,
> @@ -4989,6 +5037,7 @@ struct field_modify_info modify_tcp[] = {
>  	uint8_t next_protocol = 0xff;
>  	struct rte_vlan_hdr vlan = { 0 };
>  	bool vlan_inherited = false;
> +	uint16_t vlan_tci;
> 
>  	flow->group = attr->group;
>  	if (attr->transfer)
> @@ -5118,6 +5167,19 @@ struct field_modify_info modify_tcp[] = {
>  					   dev_flow->dv.push_vlan_res-
> >action;
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
>  			break;
> +		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
> +			if (!vlan_inherited) {
> +				flow_dev_get_vlan_info_from_items(items,
> &vlan);
> +				vlan_inherited = true;
> +			}
> +			vlan_tci =
> +			    ((const struct rte_flow_action_of_set_vlan_pcp *)
> +						       actions->conf)-
> >vlan_pcp;
> +			vlan_tci = vlan_tci <<
> MLX5DV_FLOW_VLAN_PCP_SHIFT;
> +			vlan.vlan_tci &= ~MLX5DV_FLOW_VLAN_PCP_MASK;
> +			vlan.vlan_tci |= vlan_tci;
> +			/* Push VLAN command will use this value */
> +			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
>  			if (flow_dv_create_action_l2_encap(dev, actions,
> --
> 1.8.3.1

[dpdk-dev] [PATCH v5 6/7] net/mlx5: supp modify VLAN ID on new VLAN header

[Moti Haimovsky]

This commit adds support for modifying the VLAN ID (VID) field
in an about-to-be-pushed VLAN header.
This feature can only modify the VID field of a new VLAN header yet
to be pushed. It does not support modifying an existing or already
pushed VLAN headers.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
v4:
- Fixed typo in an error message.
- Fixed bug in verifying VLAN VID value, used 0xFFFE instead of 0xFFE.
---
 doc/guides/nics/mlx5.rst               |  5 ++-
 doc/guides/rel_notes/release_19_11.rst |  1 +
 drivers/net/mlx5/mlx5_flow_dv.c        | 59 ++++++++++++++++++++++++++++++++++
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 01215f4..3a2a366 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -134,6 +134,8 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
+- VLAN set VID offload is not supported on existing headers.
+
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1045,7 +1047,8 @@ Supported hardware offloads
    | | VLAN                | | DPDK 19.11    | | DPDK 19.11    |
    | | (of_pop_vlan /      | | OFED 4.6-4    | | OFED 4.6-4    |
    | | of_push_vlan /      | | ConnectX-5    | | ConnectX-5    |
-   | | of_set_vlan_pcp)    |                 |                 |
+   | | of_set_vlan_pcp /   |                 |                 |
+   | | of_set_vlan_vid)    |                 |                 |
    +-----------------------+-----------------+-----------------+
 
 Notes for testpmd
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index 5067a1c..66297d8 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -230,4 +230,5 @@ Tested Platforms
   * Added support for VLAN pop flow offload command.
   * Added support for VLAN push flow offload command.
   * Added support for VLAN set PCP offload command.
+  * Added support for VLAN set VID offload command.
 
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 73459a0..4b68aa6 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1015,6 +1015,47 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Validate the set VLAN VID.
+ *
+ * @param[in] action_flags
+ *   Holds the actions detected until now.
+ * @param[in] actions
+ *   Pointer to the list of actions remaining in the flow rule.
+ * @param[in] attr
+ *   Pointer to flow attributes
+ * @param[out] error
+ *   Pointer to error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+				     const struct rte_flow_action actions[],
+				     struct rte_flow_error *error)
+{
+	const struct rte_flow_action *action = actions;
+	const struct rte_flow_action_of_set_vlan_vid *conf = action->conf;
+
+	if (conf->vlan_vid > RTE_BE16(0xFFE))
+		return rte_flow_error_set(error, EINVAL,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "VLAN VID value is too big");
+	if (mlx5_flow_find_action(actions,
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID can only be used "
+					  "with push VLAN action");
+	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
+		return rte_flow_error_set(error, ENOTSUP,
+					  RTE_FLOW_ERROR_TYPE_ACTION, action,
+					  "set VLAN VID action must precede "
+					  "the push VLAN action");
+	return 0;
+}
+
+/**
  * Validate count action.
  *
  * @param[in] dev
@@ -3444,6 +3485,13 @@ struct field_modify_info modify_tcp[] = {
 				return ret;
 			/* Count PCP with push_vlan command. */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			ret = flow_dv_validate_action_set_vlan_vid
+						(action_flags, actions, error);
+			if (ret < 0)
+				return ret;
+			/* Count VID with push_vlan command. */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			ret = flow_dv_validate_action_l2_encap(action_flags,
@@ -5180,6 +5228,17 @@ struct field_modify_info modify_tcp[] = {
 			vlan.vlan_tci |= vlan_tci;
 			/* Push VLAN command will use this value */
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			if (!vlan_inherited) {
+				flow_dev_get_vlan_info_from_items(items, &vlan);
+				vlan_inherited = true;
+			}
+			vlan.vlan_tci &= ~MLX5DV_FLOW_VLAN_VID_MASK;
+			vlan.vlan_tci |= rte_be_to_cpu_16
+			    (((const struct rte_flow_action_of_set_vlan_vid *)
+						     actions->conf)->vlan_vid);
+			/* Push VLAN command will use this value */
+			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 			if (flow_dv_create_action_l2_encap(dev, actions,
-- 
1.8.3.1

[dpdk-dev] [PATCH v5 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Moti Haimovsky]

This commit adds support for modifying the VID of the outermost VLAN
header already present in the packet.

Signed-off-by: Moti Haimovsky <motih@mellanox.com>
---
 doc/guides/nics/mlx5.rst        | 20 ++++-----
 drivers/net/mlx5/mlx5_flow.h    |  3 +-
 drivers/net/mlx5/mlx5_flow_dv.c | 89 ++++++++++++++++++++++++++++++++++++-----
 drivers/net/mlx5/mlx5_prm.h     |  1 +
 4 files changed, 92 insertions(+), 21 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 3a2a366..c2e9003 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -134,8 +134,6 @@ Limitations
 
 - VLAN set PCP offload is not supported on existing headers.
 
-- VLAN set VID offload is not supported on existing headers.
-
 - A multi segment packet must have not more segments than reported by dev_infos_get()
   in tx_desc_lim.nb_seg_max field. This value depends on maximal supported Tx descriptor
   size and ``txq_inline_min`` settings and may be from 2 (worst case forced by maximal
@@ -1021,13 +1019,17 @@ Supported hardware offloads
    | | (set_ipv4_src /     | | OFED 4.6-2    | | OFED 4.6-2    |
    | | set_ipv4_dst /      | | rdma-core 24  | | rdma-core 23  |
    | | set_ipv6_src /      | | ConnectX-5    | | ConnectX-5    |
-   | | set_ipv6_dst /      |                 |                 |
-   | | set_tp_src /        |                 |                 |
-   | | set_tp_dst /        |                 |                 |
-   | | dec_ttl /           |                 |                 |
-   | | set_ttl /           |                 |                 |
-   | | set_mac_src /       |                 |                 |
-   | | set_mac_dst)        |                 |                 |
+   | | set_ipv6_dst /      | |               | |               |
+   | | set_tp_src /        | |               | |               |
+   | | set_tp_dst /        | |               | |               |
+   | | dec_ttl /           | |               | |               |
+   | | set_ttl /           | |               | |               |
+   | | set_mac_src /       | |               | |               |
+   | | set_mac_dst)        | |               | |               |
+   | |                     | |               | |               |
+   | | (of_set_vlan_vid)   | | DPDK 19.11    | | DPDK 19.11    |
+   |                       | | OFED 4.6-4    | | OFED 4.6-4    |
+   |                       | | ConnectX-5    | | ConnectX-5    |
    +-----------------------+-----------------+-----------------+
    | Jump                  | | DPDK 19.05    | | DPDK 19.02    |
    |                       | | OFED 4.6-4    | | OFED 4.6-4    |
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 15c9c04..95abbb8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -171,7 +171,8 @@
 				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
 				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
-				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
+				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
+				      MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
 
 #define MLX5_FLOW_VLAN_ACTIONS (MLX5_FLOW_ACTION_OF_POP_VLAN | \
 				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 4b68aa6..330a868 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -115,6 +115,12 @@ struct field_modify_info modify_eth[] = {
 	{0, 0, 0},
 };
 
+struct field_modify_info modify_vlan_out_first_vid[] = {
+	/* Size in bits !!! */
+	{12, 0, MLX5_MODI_OUT_FIRST_VID},
+	{0, 0, 0},
+};
+
 struct field_modify_info modify_ipv4[] = {
 	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
 	{4, 12, MLX5_MODI_OUT_SIPV4},
@@ -397,6 +403,46 @@ struct field_modify_info modify_tcp[] = {
 }
 
 /**
+ * Convert modify-header set VLAN VID action to DV specification.
+ *
+ * @param[in,out] resource
+ *   Pointer to the modify-header resource.
+ * @param[in] action
+ *   Pointer to action specification.
+ * @param[out] error
+ *   Pointer to the error structure.
+ *
+ * @return
+ *   0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+flow_dv_convert_action_modify_vlan_vid
+			(struct mlx5_flow_dv_modify_hdr_resource *resource,
+			 const struct rte_flow_action *action,
+			 struct rte_flow_error *error)
+{
+	const struct rte_flow_action_of_set_vlan_vid *conf =
+		(const struct rte_flow_action_of_set_vlan_vid *)(action->conf);
+	int i = resource->actions_num;
+	struct mlx5_modification_cmd *actions = &resource->actions[i];
+	struct field_modify_info *field = modify_vlan_out_first_vid;
+
+	if (i >= MLX5_MODIFY_NUM)
+		return rte_flow_error_set(error, EINVAL,
+			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+			 "too many items to modify");
+	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
+	actions[i].field = field->id;
+	actions[i].length = field->size;
+	actions[i].offset = field->offset;
+	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
+	actions[i].data1 = conf->vlan_vid;
+	actions[i].data1 = actions[i].data1 << 16;
+	resource->actions_num = ++i;
+	return 0;
+}
+
+/**
  * Convert modify-header set TP action to DV specification.
  *
  * @param[in,out] resource
@@ -1017,8 +1063,8 @@ struct field_modify_info modify_tcp[] = {
 /**
  * Validate the set VLAN VID.
  *
- * @param[in] action_flags
- *   Holds the actions detected until now.
+ * @param[in] item_flags
+ *   Holds the items detected in this rule.
  * @param[in] actions
  *   Pointer to the list of actions remaining in the flow rule.
  * @param[in] attr
@@ -1030,7 +1076,7 @@ struct field_modify_info modify_tcp[] = {
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
+flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
 				     const struct rte_flow_action actions[],
 				     struct rte_flow_error *error)
 {
@@ -1041,17 +1087,27 @@ struct field_modify_info modify_tcp[] = {
 		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
 					  "VLAN VID value is too big");
+	/* If a push VLAN action follows then it will handle this action */
 	if (mlx5_flow_find_action(actions,
-				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
+				  RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+		return 0;
+
+	/*
+	 * Action is on an existing VLAN header:
+	 *    Need to verify this is a single modify CID action.
+	 *   Rule mast include a match on outer VLAN.
+	 */
+	if (mlx5_flow_find_action(++action,
+				  RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
 		return rte_flow_error_set(error, ENOTSUP,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID can only be used "
-					  "with push VLAN action");
-	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
-		return rte_flow_error_set(error, ENOTSUP,
+					  "Multiple VLAN VID modifications are "
+					  "not supported");
+	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
+		return rte_flow_error_set(error, EINVAL,
 					  RTE_FLOW_ERROR_TYPE_ACTION, action,
-					  "set VLAN VID action must precede "
-					  "the push VLAN action");
+					  "match on VLAN is required in order "
+					  "to set VLAN VID");
 	return 0;
 }
 
@@ -3487,7 +3543,7 @@ struct field_modify_info modify_tcp[] = {
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 			ret = flow_dv_validate_action_set_vlan_vid
-						(action_flags, actions, error);
+						(item_flags, actions, error);
 			if (ret < 0)
 				return ret;
 			/* Count VID with push_vlan command. */
@@ -5214,6 +5270,8 @@ struct field_modify_info modify_tcp[] = {
 			dev_flow->dv.actions[actions_n++] =
 					   dev_flow->dv.push_vlan_res->action;
 			action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+			/* Push VLAN command is also handling this VLAN_VID */
+			action_flags &= ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			if (!vlan_inherited) {
@@ -5238,6 +5296,15 @@ struct field_modify_info modify_tcp[] = {
 			    (((const struct rte_flow_action_of_set_vlan_vid *)
 						     actions->conf)->vlan_vid);
 			/* Push VLAN command will use this value */
+			if (mlx5_flow_find_action
+				(actions,
+				 RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
+				break;
+			/* If no VLAN push - this is a modify header action */
+			if (flow_dv_convert_action_modify_vlan_vid
+							(&res, actions, error))
+				return -rte_errno;
+			action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
 			break;
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index d62837e..e5afc1c 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -413,6 +413,7 @@ enum mlx5_modification_field {
 	MLX5_MODI_OUT_DIPV6_31_0,
 	MLX5_MODI_OUT_SIPV4,
 	MLX5_MODI_OUT_DIPV4,
+	MLX5_MODI_OUT_FIRST_VID,
 	MLX5_MODI_IN_SMAC_47_16 = 0x31,
 	MLX5_MODI_IN_SMAC_15_0,
 	MLX5_MODI_IN_ETHERTYPE,
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v5 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 7/7] net/mlx5: supp modify VLAN ID on existing VLAN hdr
> 
> This commit adds support for modifying the VID of the outermost VLAN
> header already present in the packet.
> 
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

> ---
>  doc/guides/nics/mlx5.rst        | 20 ++++-----
>  drivers/net/mlx5/mlx5_flow.h    |  3 +-
>  drivers/net/mlx5/mlx5_flow_dv.c | 89
> ++++++++++++++++++++++++++++++++++++-----
>  drivers/net/mlx5/mlx5_prm.h     |  1 +
>  4 files changed, 92 insertions(+), 21 deletions(-)
> 
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 3a2a366..c2e9003 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -134,8 +134,6 @@ Limitations
> 
>  - VLAN set PCP offload is not supported on existing headers.
> 
> -- VLAN set VID offload is not supported on existing headers.
> -
>  - A multi segment packet must have not more segments than reported by
> dev_infos_get()
>    in tx_desc_lim.nb_seg_max field. This value depends on maximal supported
> Tx descriptor
>    size and ``txq_inline_min`` settings and may be from 2 (worst case forced
> by maximal @@ -1021,13 +1019,17 @@ Supported hardware offloads
>     | | (set_ipv4_src /     | | OFED 4.6-2    | | OFED 4.6-2    |
>     | | set_ipv4_dst /      | | rdma-core 24  | | rdma-core 23  |
>     | | set_ipv6_src /      | | ConnectX-5    | | ConnectX-5    |
> -   | | set_ipv6_dst /      |                 |                 |
> -   | | set_tp_src /        |                 |                 |
> -   | | set_tp_dst /        |                 |                 |
> -   | | dec_ttl /           |                 |                 |
> -   | | set_ttl /           |                 |                 |
> -   | | set_mac_src /       |                 |                 |
> -   | | set_mac_dst)        |                 |                 |
> +   | | set_ipv6_dst /      | |               | |               |
> +   | | set_tp_src /        | |               | |               |
> +   | | set_tp_dst /        | |               | |               |
> +   | | dec_ttl /           | |               | |               |
> +   | | set_ttl /           | |               | |               |
> +   | | set_mac_src /       | |               | |               |
> +   | | set_mac_dst)        | |               | |               |
> +   | |                     | |               | |               |
> +   | | (of_set_vlan_vid)   | | DPDK 19.11    | | DPDK 19.11    |
> +   |                       | | OFED 4.6-4    | | OFED 4.6-4    |
> +   |                       | | ConnectX-5    | | ConnectX-5    |
>     +-----------------------+-----------------+-----------------+
>     | Jump                  | | DPDK 19.05    | | DPDK 19.02    |
>     |                       | | OFED 4.6-4    | | OFED 4.6-4    |
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 15c9c04..95abbb8 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -171,7 +171,8 @@
>  				      MLX5_FLOW_ACTION_INC_TCP_SEQ | \
>  				      MLX5_FLOW_ACTION_DEC_TCP_SEQ | \
>  				      MLX5_FLOW_ACTION_INC_TCP_ACK | \
> -				      MLX5_FLOW_ACTION_DEC_TCP_ACK)
> +				      MLX5_FLOW_ACTION_DEC_TCP_ACK | \
> +
> MLX5_FLOW_ACTION_OF_SET_VLAN_VID)
> 
>  #define MLX5_FLOW_VLAN_ACTIONS
> (MLX5_FLOW_ACTION_OF_POP_VLAN | \
>  				MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 4b68aa6..330a868 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -115,6 +115,12 @@ struct field_modify_info modify_eth[] = {
>  	{0, 0, 0},
>  };
> 
> +struct field_modify_info modify_vlan_out_first_vid[] = {
> +	/* Size in bits !!! */
> +	{12, 0, MLX5_MODI_OUT_FIRST_VID},
> +	{0, 0, 0},
> +};
> +
>  struct field_modify_info modify_ipv4[] = {
>  	{1,  8, MLX5_MODI_OUT_IPV4_TTL},
>  	{4, 12, MLX5_MODI_OUT_SIPV4},
> @@ -397,6 +403,46 @@ struct field_modify_info modify_tcp[] = {  }
> 
>  /**
> + * Convert modify-header set VLAN VID action to DV specification.
> + *
> + * @param[in,out] resource
> + *   Pointer to the modify-header resource.
> + * @param[in] action
> + *   Pointer to action specification.
> + * @param[out] error
> + *   Pointer to the error structure.
> + *
> + * @return
> + *   0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_vlan_vid
> +			(struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> +			 const struct rte_flow_action *action,
> +			 struct rte_flow_error *error)
> +{
> +	const struct rte_flow_action_of_set_vlan_vid *conf =
> +		(const struct rte_flow_action_of_set_vlan_vid *)(action-
> >conf);
> +	int i = resource->actions_num;
> +	struct mlx5_modification_cmd *actions = &resource->actions[i];
> +	struct field_modify_info *field = modify_vlan_out_first_vid;
> +
> +	if (i >= MLX5_MODIFY_NUM)
> +		return rte_flow_error_set(error, EINVAL,
> +			 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
> +			 "too many items to modify");
> +	actions[i].action_type = MLX5_MODIFICATION_TYPE_SET;
> +	actions[i].field = field->id;
> +	actions[i].length = field->size;
> +	actions[i].offset = field->offset;
> +	actions[i].data0 = rte_cpu_to_be_32(actions[i].data0);
> +	actions[i].data1 = conf->vlan_vid;
> +	actions[i].data1 = actions[i].data1 << 16;
> +	resource->actions_num = ++i;
> +	return 0;
> +}
> +
> +/**
>   * Convert modify-header set TP action to DV specification.
>   *
>   * @param[in,out] resource
> @@ -1017,8 +1063,8 @@ struct field_modify_info modify_tcp[] = {
>  /**
>   * Validate the set VLAN VID.
>   *
> - * @param[in] action_flags
> - *   Holds the actions detected until now.
> + * @param[in] item_flags
> + *   Holds the items detected in this rule.
>   * @param[in] actions
>   *   Pointer to the list of actions remaining in the flow rule.
>   * @param[in] attr
> @@ -1030,7 +1076,7 @@ struct field_modify_info modify_tcp[] = {
>   *   0 on success, a negative errno value otherwise and rte_errno is set.
>   */
>  static int
> -flow_dv_validate_action_set_vlan_vid(uint64_t action_flags,
> +flow_dv_validate_action_set_vlan_vid(uint64_t item_flags,
>  				     const struct rte_flow_action actions[],
>  				     struct rte_flow_error *error)
>  {
> @@ -1041,17 +1087,27 @@ struct field_modify_info modify_tcp[] = {
>  		return rte_flow_error_set(error, EINVAL,
>  					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
>  					  "VLAN VID value is too big");
> +	/* If a push VLAN action follows then it will handle this action */
>  	if (mlx5_flow_find_action(actions,
> -
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN) == NULL)
> +
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
> +		return 0;
> +
> +	/*
> +	 * Action is on an existing VLAN header:
> +	 *    Need to verify this is a single modify CID action.
> +	 *   Rule mast include a match on outer VLAN.
> +	 */
> +	if (mlx5_flow_find_action(++action,
> +
> RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID))
>  		return rte_flow_error_set(error, ENOTSUP,
>  					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> -					  "set VLAN VID can only be used "
> -					  "with push VLAN action");
> -	if (action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN)
> -		return rte_flow_error_set(error, ENOTSUP,
> +					  "Multiple VLAN VID modifications
> are "
> +					  "not supported");
> +	if (!(item_flags & MLX5_FLOW_LAYER_OUTER_VLAN))
> +		return rte_flow_error_set(error, EINVAL,
>  					  RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> -					  "set VLAN VID action must precede
> "
> -					  "the push VLAN action");
> +					  "match on VLAN is required in order
> "
> +					  "to set VLAN VID");
>  	return 0;
>  }
> 
> @@ -3487,7 +3543,7 @@ struct field_modify_info modify_tcp[] = {
>  			break;
>  		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
>  			ret = flow_dv_validate_action_set_vlan_vid
> -						(action_flags, actions, error);
> +						(item_flags, actions, error);
>  			if (ret < 0)
>  				return ret;
>  			/* Count VID with push_vlan command. */ @@ -
> 5214,6 +5270,8 @@ struct field_modify_info modify_tcp[] = {
>  			dev_flow->dv.actions[actions_n++] =
>  					   dev_flow->dv.push_vlan_res-
> >action;
>  			action_flags |=
> MLX5_FLOW_ACTION_OF_PUSH_VLAN;
> +			/* Push VLAN command is also handling this
> VLAN_VID */
> +			action_flags &=
> ~MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
>  			break;
>  		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
>  			if (!vlan_inherited) {
> @@ -5238,6 +5296,15 @@ struct field_modify_info modify_tcp[] = {
>  			    (((const struct rte_flow_action_of_set_vlan_vid *)
>  						     actions->conf)->vlan_vid);
>  			/* Push VLAN command will use this value */
> +			if (mlx5_flow_find_action
> +				(actions,
> +
> RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN))
> +				break;
> +			/* If no VLAN push - this is a modify header action */
> +			if (flow_dv_convert_action_modify_vlan_vid
> +							(&res, actions, error))
> +				return -rte_errno;
> +			action_flags |=
> MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
>  			break;
>  		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
>  		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
> diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
> index d62837e..e5afc1c 100644
> --- a/drivers/net/mlx5/mlx5_prm.h
> +++ b/drivers/net/mlx5/mlx5_prm.h
> @@ -413,6 +413,7 @@ enum mlx5_modification_field {
>  	MLX5_MODI_OUT_DIPV6_31_0,
>  	MLX5_MODI_OUT_SIPV4,
>  	MLX5_MODI_OUT_DIPV4,
> +	MLX5_MODI_OUT_FIRST_VID,
>  	MLX5_MODI_IN_SMAC_47_16 = 0x31,
>  	MLX5_MODI_IN_SMAC_15_0,
>  	MLX5_MODI_IN_ETHERTYPE,
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH v5 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 18:57
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 0/7] net/mlx5: support for flow action on VLAN header
> 
> VLAN actions support is implemented in librte_ethdev, and in test-pmd
> application, based on [1] Generic flow API.
> These actions conform to the VLAN actions defined in [2] the OpenFlow
> Switch Specification.
> 
> rte_flow defines the following VLAN actions:
>  1. OF_POP_VLAN
>     Pop the outer-most VLAN header from the packet.
>  2. OF_PUSH_VLAN
>     Push a new VLAN header onto the packet.
>  3. OF_SET_VLAN_VID
>     Sets the ID of the outermost VLAN tag.
>  4. OF_SET_VLAN_PCP
>     Sets the 3-bit priority field of the outermost VLAN tag.
> 
> This series of patches adds support for those VLAN actions to the mlx5 PMD
> using the Direct Verbs interface.
> 
> v2:
> - Code rebase on latest commits.
> 
> v3:
> - mlx5 documentation update.
> 
> v4:
> - Update the release notes with new the new features.
> - Minor bug fixes.
> 
> v5:
> - Rebase on top of latest commits.
> - Minor bug fix in vlan push action.
> - Bug fix in the format of the release notes.
> 
> Moti Haimovsky (7):
>   net/mlx5: support for an action search in a list
>   net/mlx5: add VLAN push/pop DR commands to glue
>   net/mlx5: support pop flow action on VLAN header
>   net/mlx5: support push flow action on VLAN header
>   net/mlx5: support modify VLAN priority on VLAN hdr
>   net/mlx5: supp modify VLAN ID on new VLAN header
>   net/mlx5: supp modify VLAN ID on existing VLAN hdr
> 
>  doc/guides/nics/mlx5.rst               |  34 ++-
>  doc/guides/rel_notes/release_19_11.rst |   9 +
>  drivers/net/mlx5/Makefile              |   5 +
>  drivers/net/mlx5/meson.build           |   2 +
>  drivers/net/mlx5/mlx5.c                |   9 +
>  drivers/net/mlx5/mlx5.h                |   4 +
>  drivers/net/mlx5/mlx5_flow.c           |  23 ++
>  drivers/net/mlx5/mlx5_flow.h           |  27 +-
>  drivers/net/mlx5/mlx5_flow_dv.c        | 538
> +++++++++++++++++++++++++++++++++
>  drivers/net/mlx5/mlx5_glue.c           |  29 ++
>  drivers/net/mlx5/mlx5_glue.h           |   6 +
>  drivers/net/mlx5/mlx5_prm.h            |   1 +
>  12 files changed, 677 insertions(+), 10 deletions(-)
> 
> --
> 1.8.3.1
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

Re: [dpdk-dev] [PATCH v5 0/7] net/mlx5: support for flow action on VLAN header

[Raslan Darawsheh]

Hi,

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

> -----Original Message-----
> From: Moti Haimovsky <motih@mellanox.com>
> Sent: Monday, September 9, 2019 6:57 PM
> To: Slava Ovsiienko <viacheslavo@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v5 0/7] net/mlx5: support for flow action on VLAN header
> 
> VLAN actions support is implemented in librte_ethdev, and in test-pmd
> application, based on [1] Generic flow API.
> These actions conform to the VLAN actions defined in [2] the OpenFlow
> Switch Specification.
> 
> rte_flow defines the following VLAN actions:
>  1. OF_POP_VLAN
>     Pop the outer-most VLAN header from the packet.
>  2. OF_PUSH_VLAN
>     Push a new VLAN header onto the packet.
>  3. OF_SET_VLAN_VID
>     Sets the ID of the outermost VLAN tag.
>  4. OF_SET_VLAN_PCP
>     Sets the 3-bit priority field of the outermost VLAN tag.
> 
> This series of patches adds support for those VLAN actions to the mlx5 PMD
> using the Direct Verbs interface.
> 
> v2:
> - Code rebase on latest commits.
> 
> v3:
> - mlx5 documentation update.
> 
> v4:
> - Update the release notes with new the new features.
> - Minor bug fixes.
> 
> v5:
> - Rebase on top of latest commits.
> - Minor bug fix in vlan push action.
> - Bug fix in the format of the release notes.
> 
> Moti Haimovsky (7):
>   net/mlx5: support for an action search in a list
>   net/mlx5: add VLAN push/pop DR commands to glue
>   net/mlx5: support pop flow action on VLAN header
>   net/mlx5: support push flow action on VLAN header
>   net/mlx5: support modify VLAN priority on VLAN hdr
>   net/mlx5: supp modify VLAN ID on new VLAN header
>   net/mlx5: supp modify VLAN ID on existing VLAN hdr
> 
>  doc/guides/nics/mlx5.rst               |  34 ++-
>  doc/guides/rel_notes/release_19_11.rst |   9 +
>  drivers/net/mlx5/Makefile              |   5 +
>  drivers/net/mlx5/meson.build           |   2 +
>  drivers/net/mlx5/mlx5.c                |   9 +
>  drivers/net/mlx5/mlx5.h                |   4 +
>  drivers/net/mlx5/mlx5_flow.c           |  23 ++
>  drivers/net/mlx5/mlx5_flow.h           |  27 +-
>  drivers/net/mlx5/mlx5_flow_dv.c        | 538
> +++++++++++++++++++++++++++++++++
>  drivers/net/mlx5/mlx5_glue.c           |  29 ++
>  drivers/net/mlx5/mlx5_glue.h           |   6 +
>  drivers/net/mlx5/mlx5_prm.h            |   1 +
>  12 files changed, 677 insertions(+), 10 deletions(-)
> 
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Moti,

I have some questions on the patch.
Just want to know how to use it.

Q1. Is it correct understanding that the patch will be reflected in
19.11 if it is approved?

Q2.Which action should I specify when I want to insert VLAN tag
to non-VLAN frame?

OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?

Q3. Is it possible to detag VLAN when it receives VLAN tagged 
frame from outside of the host?

Q4. Is it possible to entag VLAN to non-VLAN frame when 
it sends packet to outside of host?

Q5.Are there any restriction to conbime other ACTIONS like QUEUE?

Q6. Is it possible to apply rte_flow actions for specified tx queue 
of physical NIC?
(e.g. VM connect with PHY:0 using tx queue index:1, I want
to entag VLAN 101 to the traffic from VM to PHY:0 is it possible?)

Thanks in advance!

BR,
Hideyuki Yamashita
NTT TechnoCross

> VLAN actions support is implemented in librte_ethdev, and in
> test-pmd application, based on [1] Generic flow API.
> These actions conform to the VLAN actions defined in
> [2] the OpenFlow Switch Specification.
> 
> rte_flow defines the following VLAN actions:
>  1. OF_POP_VLAN
>     Pop the outer-most VLAN header from the packet.
>  2. OF_PUSH_VLAN
>     Push a new VLAN header onto the packet.
>  3. OF_SET_VLAN_VID
>     Sets the ID of the outermost VLAN tag.
>  4. OF_SET_VLAN_PCP
>     Sets the 3-bit priority field of the outermost VLAN tag.
> 
> This series of patches adds support for those VLAN actions
> to the mlx5 PMD using the Direct Verbs interface.
> 
> Moti Haimovsky (7):
>   net/mlx5: support for an action search in a list
>   net/mlx5: add VLAN push/pop DR commands to glue
>   net/mlx5: support pop flow action on VLAN header
>   net/mlx5: support push flow action on VLAN header
>   net/mlx5: support modify VLAN priority on VLAN hdr
>   net/mlx5: supp modify VLAN ID on new VLAN header
>   net/mlx5: supp modify VLAN ID on existing VLAN hdr
> 
>  drivers/net/mlx5/Makefile       |   5 +
>  drivers/net/mlx5/meson.build    |   2 +
>  drivers/net/mlx5/mlx5.c         |   9 +
>  drivers/net/mlx5/mlx5.h         |   3 +
>  drivers/net/mlx5/mlx5_flow.c    |  23 ++
>  drivers/net/mlx5/mlx5_flow.h    |  27 ++-
>  drivers/net/mlx5/mlx5_flow_dv.c | 521 ++++++++++++++++++++++++++++++++++++++++
>  drivers/net/mlx5/mlx5_glue.c    |  29 +++
>  drivers/net/mlx5/mlx5_glue.h    |   6 +
>  drivers/net/mlx5/mlx5_prm.h     |   1 +
>  10 files changed, 623 insertions(+), 3 deletions(-)
> 
> -- 
> 1.8.3.1

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Can somebody (Mellanox guys?) help me out?

> Hello Moti,
> 
> I have some questions on the patch.
> Just want to know how to use it.
> 
> Q1. Is it correct understanding that the patch will be reflected in
> 19.11 if it is approved?
> 
> Q2.Which action should I specify when I want to insert VLAN tag
> to non-VLAN frame?
> 
> OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> 
> Q3. Is it possible to detag VLAN when it receives VLAN tagged 
> frame from outside of the host?
> 
> Q4. Is it possible to entag VLAN to non-VLAN frame when 
> it sends packet to outside of host?
> 
> Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
> 
> Q6. Is it possible to apply rte_flow actions for specified tx queue 
> of physical NIC?
> (e.g. VM connect with PHY:0 using tx queue index:1, I want
> to entag VLAN 101 to the traffic from VM to PHY:0 is it possible?)
> 
> Thanks in advance!
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > VLAN actions support is implemented in librte_ethdev, and in
> > test-pmd application, based on [1] Generic flow API.
> > These actions conform to the VLAN actions defined in
> > [2] the OpenFlow Switch Specification.
> > 
> > rte_flow defines the following VLAN actions:
> >  1. OF_POP_VLAN
> >     Pop the outer-most VLAN header from the packet.
> >  2. OF_PUSH_VLAN
> >     Push a new VLAN header onto the packet.
> >  3. OF_SET_VLAN_VID
> >     Sets the ID of the outermost VLAN tag.
> >  4. OF_SET_VLAN_PCP
> >     Sets the 3-bit priority field of the outermost VLAN tag.
> > 
> > This series of patches adds support for those VLAN actions
> > to the mlx5 PMD using the Direct Verbs interface.
> > 
> > Moti Haimovsky (7):
> >   net/mlx5: support for an action search in a list
> >   net/mlx5: add VLAN push/pop DR commands to glue
> >   net/mlx5: support pop flow action on VLAN header
> >   net/mlx5: support push flow action on VLAN header
> >   net/mlx5: support modify VLAN priority on VLAN hdr
> >   net/mlx5: supp modify VLAN ID on new VLAN header
> >   net/mlx5: supp modify VLAN ID on existing VLAN hdr
> > 
> >  drivers/net/mlx5/Makefile       |   5 +
> >  drivers/net/mlx5/meson.build    |   2 +
> >  drivers/net/mlx5/mlx5.c         |   9 +
> >  drivers/net/mlx5/mlx5.h         |   3 +
> >  drivers/net/mlx5/mlx5_flow.c    |  23 ++
> >  drivers/net/mlx5/mlx5_flow.h    |  27 ++-
> >  drivers/net/mlx5/mlx5_flow_dv.c | 521 ++++++++++++++++++++++++++++++++++++++++
> >  drivers/net/mlx5/mlx5_glue.c    |  29 +++
> >  drivers/net/mlx5/mlx5_glue.h    |   6 +
> >  drivers/net/mlx5/mlx5_prm.h     |   1 +
> >  10 files changed, 623 insertions(+), 3 deletions(-)
> > 
> > -- 
> > 1.8.3.1
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Friday, October 4, 2019 13:35
> To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Can somebody (Mellanox guys?) help me out?

Hi, Hideyuki

I'm sorry, there are long holidays in IL, so let me try to answer.

> 
> > Hello Moti,
> >
> > I have some questions on the patch.
> > Just want to know how to use it.
> >
> > Q1. Is it correct understanding that the patch will be reflected in
> > 19.11 if it is approved?

Yes, it is merged and should be reflected.

> >
> > Q2.Which action should I specify when I want to insert VLAN tag to
> > non-VLAN frame?
> >
> > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?

All of them, OF_PUSH_VLAN inserts the VLAN header, OF_SET_VLAN_VID and
OF_SET_VLAN_PCP fill the fields with appropriate values.

> >
> > Q3. Is it possible to detag VLAN when it receives VLAN tagged frame
> > from outside of the host?
Do you mean some complex configuration with multiple VMs and engaged E-Switch
feature? Anyway, there are multiple ways to strip (untag) VLAN header:
- with E-Switch rules (including match on specified port)
- with local port rules
- stripping VLAN in Rx queue

> >
> > Q4. Is it possible to entag VLAN to non-VLAN frame when it sends
> > packet to outside of host?
Yes.

> >
> > Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is supported there.

> >
> > Q6. Is it possible to apply rte_flow actions for specified tx queue of
> > physical NIC?
> > (e.g. VM connect with PHY:0 using tx queue index:1, I want to entag
> > VLAN 101 to the traffic from VM to PHY:0 is it possible?)
Directly - no, there is no item to match with specific Tx queue.

If setting VLAN on specific Tx queue is desired we have two options:

- engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide VLAN with
 each packet being transferred to tx_burst

- engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set specific
metadata for all packets on specific queue. Then the rules matching with this metadata
may be inserted.

[snip]

With best regards, Slava

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Dear Slava and experts,

Thanks for your answering me.
Baased on your answer, I tested using testpmd.
And about the outcome, I have several questions.


[1.Test environment]
OS:Ubuntu18.04
NIC1:MCX4121A-ACAT 25G
NIC2:MCX516A-CCAT 100G
Repo:dpdk-next-net

I checked that the following is shown in git log command.
9f1e94469 net/mlx5: fix netlink rdma socket callback routine
50735012c net/mlx5: support reading module EEPROM data
f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
43184603e net/mlx5: support modifying VLAN priority on VLAN header
4f59ffbd8 net/mlx5: support push flow action on VLAN header
b4bd8f5da net/mlx5: support pop flow action on VLAN header
048e3e84c net/mlx5: add VLAN push/pop DR commands to glue

[2.Test result]
I tested the follwoing flows with testpmd included in dpdk-next-net.

A.flow create 0 ingress pattern eth / vlan id is 100 / end actions OF_POP_VLAN / end 
B.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end 
C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions OF_SET_VLAN_VID vlan_vid 200 / end 
D.flow create X ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP vlan_pcp 3 / end 
E.flow create 0 egress pattern eth src is BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end

A-D, resulted in "Caught error type 16 (specific action): cause: 0x7ffcc711db48, action not supported: Operation not supported".
E resulted in "Egress is not supported".

[3. Quetions]
Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
 I think related commits are included so it "should" work and my guess is that my flow is somehow wrong.
Q2. Is it correct understanding that "egress" is not supported for mlx5 PMD?
Q3. If yes, is it possible to entag VLAN tag to the outgoing packet from physical NIC by using rte_flow?

BR,
Hideyuki Yamashita
NTT TechnoCross


> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Friday, October 4, 2019 13:35
> > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Can somebody (Mellanox guys?) help me out?
> 
> Hi, Hideyuki
> 
> I'm sorry, there are long holidays in IL, so let me try to answer.
> 
> > 
> > > Hello Moti,
> > >
> > > I have some questions on the patch.
> > > Just want to know how to use it.
> > >
> > > Q1. Is it correct understanding that the patch will be reflected in
> > > 19.11 if it is approved?
> 
> Yes, it is merged and should be reflected.
> 
> > >
> > > Q2.Which action should I specify when I want to insert VLAN tag to
> > > non-VLAN frame?
> > >
> > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> 
> All of them, OF_PUSH_VLAN inserts the VLAN header, OF_SET_VLAN_VID and
> OF_SET_VLAN_PCP fill the fields with appropriate values.
> 
> > >
> > > Q3. Is it possible to detag VLAN when it receives VLAN tagged frame
> > > from outside of the host?
> Do you mean some complex configuration with multiple VMs and engaged E-Switch
> feature? Anyway, there are multiple ways to strip (untag) VLAN header:
> - with E-Switch rules (including match on specified port)
> - with local port rules
> - stripping VLAN in Rx queue
> 
> > >
> > > Q4. Is it possible to entag VLAN to non-VLAN frame when it sends
> > > packet to outside of host?
> Yes.
> 
> > >
> > > Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
> Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is supported there.
> 
> > >
> > > Q6. Is it possible to apply rte_flow actions for specified tx queue of
> > > physical NIC?
> > > (e.g. VM connect with PHY:0 using tx queue index:1, I want to entag
> > > VLAN 101 to the traffic from VM to PHY:0 is it possible?)
> Directly - no, there is no item to match with specific Tx queue.
> 
> If setting VLAN on specific Tx queue is desired we have two options:
> 
> - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide VLAN with
>  each packet being transferred to tx_burst
> 
> - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set specific
> metadata for all packets on specific queue. Then the rules matching with this metadata
> may be inserted.
> 
> [snip]
> 
> With best regards, Slava

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Dear Slava, Moti and all,

Please let me know if you need more information.
Partial answer is acceptable for me.

Thanks in advaince!

BR,
HIdeyuki Yamashita
NTT TechnoCross

> Dear Slava and experts,
> 
> Thanks for your answering me.
> Baased on your answer, I tested using testpmd.
> And about the outcome, I have several questions.
> 
> 
> [1.Test environment]
> OS:Ubuntu18.04
> NIC1:MCX4121A-ACAT 25G
> NIC2:MCX516A-CCAT 100G
> Repo:dpdk-next-net
> 
> I checked that the following is shown in git log command.
> 9f1e94469 net/mlx5: fix netlink rdma socket callback routine
> 50735012c net/mlx5: support reading module EEPROM data
> f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
> 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> 43184603e net/mlx5: support modifying VLAN priority on VLAN header
> 4f59ffbd8 net/mlx5: support push flow action on VLAN header
> b4bd8f5da net/mlx5: support pop flow action on VLAN header
> 048e3e84c net/mlx5: add VLAN push/pop DR commands to glue
> 
> [2.Test result]
> I tested the follwoing flows with testpmd included in dpdk-next-net.
> 
> A.flow create 0 ingress pattern eth / vlan id is 100 / end actions OF_POP_VLAN / end 
> B.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end 
> C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions OF_SET_VLAN_VID vlan_vid 200 / end 
> D.flow create X ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP vlan_pcp 3 / end 
> E.flow create 0 egress pattern eth src is BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> 
> A-D, resulted in "Caught error type 16 (specific action): cause: 0x7ffcc711db48, action not supported: Operation not supported".
> E resulted in "Egress is not supported".
> 
> [3. Quetions]
> Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
>  I think related commits are included so it "should" work and my guess is that my flow is somehow wrong.
> Q2. Is it correct understanding that "egress" is not supported for mlx5 PMD?
> Q3. If yes, is it possible to entag VLAN tag to the outgoing packet from physical NIC by using rte_flow?
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Friday, October 4, 2019 13:35
> > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > > VLAN header
> > > 
> > > Can somebody (Mellanox guys?) help me out?
> > 
> > Hi, Hideyuki
> > 
> > I'm sorry, there are long holidays in IL, so let me try to answer.
> > 
> > > 
> > > > Hello Moti,
> > > >
> > > > I have some questions on the patch.
> > > > Just want to know how to use it.
> > > >
> > > > Q1. Is it correct understanding that the patch will be reflected in
> > > > 19.11 if it is approved?
> > 
> > Yes, it is merged and should be reflected.
> > 
> > > >
> > > > Q2.Which action should I specify when I want to insert VLAN tag to
> > > > non-VLAN frame?
> > > >
> > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> > 
> > All of them, OF_PUSH_VLAN inserts the VLAN header, OF_SET_VLAN_VID and
> > OF_SET_VLAN_PCP fill the fields with appropriate values.
> > 
> > > >
> > > > Q3. Is it possible to detag VLAN when it receives VLAN tagged frame
> > > > from outside of the host?
> > Do you mean some complex configuration with multiple VMs and engaged E-Switch
> > feature? Anyway, there are multiple ways to strip (untag) VLAN header:
> > - with E-Switch rules (including match on specified port)
> > - with local port rules
> > - stripping VLAN in Rx queue
> > 
> > > >
> > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it sends
> > > > packet to outside of host?
> > Yes.
> > 
> > > >
> > > > Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
> > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is supported there.
> > 
> > > >
> > > > Q6. Is it possible to apply rte_flow actions for specified tx queue of
> > > > physical NIC?
> > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want to entag
> > > > VLAN 101 to the traffic from VM to PHY:0 is it possible?)
> > Directly - no, there is no item to match with specific Tx queue.
> > 
> > If setting VLAN on specific Tx queue is desired we have two options:
> > 
> > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide VLAN with
> >  each packet being transferred to tx_burst
> > 
> > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set specific
> > metadata for all packets on specific queue. Then the rules matching with this metadata
> > may be inserted.
> > 
> > [snip]
> > 
> > With best regards, Slava
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Monday, October 21, 2019 10:12
> To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; Moti Haimovsky
> <motih@mellanox.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Dear Slava, Moti and all,
> 
> Please let me know if you need more information.
> Partial answer is acceptable for me.
> 
> Thanks in advaince!

I'm sorry for delay, your issue is still in progress.
I've tested your rules on my standard configuration - these ones are rejected by FW/SW,
not by DPDK code. Moti tested the flows on custom setup (I suppose experimental FW/kernel).
AFAIK, VLAN feature was planned to GA with OFED 4.7.1,
please, let me check it (hope in few days, there are holidays still lasting in IL).

With best regards, Slava
> 
> BR,
> HIdeyuki Yamashita
> NTT TechnoCross
> 
> > Dear Slava and experts,
> >
> > Thanks for your answering me.
> > Baased on your answer, I tested using testpmd.
> > And about the outcome, I have several questions.
> >
> >
> > [1.Test environment]
> > OS:Ubuntu18.04
> > NIC1:MCX4121A-ACAT 25G
> > NIC2:MCX516A-CCAT 100G
> > Repo:dpdk-next-net
> >
> > I checked that the following is shown in git log command.
> > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine 50735012c
> > net/mlx5: support reading module EEPROM data
> > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
> > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> > 43184603e net/mlx5: support modifying VLAN priority on VLAN header
> > 4f59ffbd8 net/mlx5: support push flow action on VLAN header b4bd8f5da
> > net/mlx5: support pop flow action on VLAN header 048e3e84c net/mlx5:
> > add VLAN push/pop DR commands to glue
> >
> > [2.Test result]
> > I tested the follwoing flows with testpmd included in dpdk-next-net.
> >
> > A.flow create 0 ingress pattern eth / vlan id is 100 / end actions
> > OF_POP_VLAN / end B.flow create 0 ingress pattern eth dst is
> > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end
> > actions OF_SET_VLAN_VID vlan_vid 200 / end D.flow create X ingress
> > pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP
> > vlan_pcp 3 / end E.flow create 0 egress pattern eth src is
> > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> >
> > A-D, resulted in "Caught error type 16 (specific action): cause:
> 0x7ffcc711db48, action not supported: Operation not supported".
> > E resulted in "Egress is not supported".
> >
> > [3. Quetions]
> > Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
> >  I think related commits are included so it "should" work and my guess is
> that my flow is somehow wrong.
> > Q2. Is it correct understanding that "egress" is not supported for mlx5
> PMD?
> > Q3. If yes, is it possible to entag VLAN tag to the outgoing packet from
> physical NIC by using rte_flow?
> >
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> >
> >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Friday, October 4, 2019 13:35
> > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Can somebody (Mellanox guys?) help me out?
> > >
> > > Hi, Hideyuki
> > >
> > > I'm sorry, there are long holidays in IL, so let me try to answer.
> > >
> > > >
> > > > > Hello Moti,
> > > > >
> > > > > I have some questions on the patch.
> > > > > Just want to know how to use it.
> > > > >
> > > > > Q1. Is it correct understanding that the patch will be reflected
> > > > > in
> > > > > 19.11 if it is approved?
> > >
> > > Yes, it is merged and should be reflected.
> > >
> > > > >
> > > > > Q2.Which action should I specify when I want to insert VLAN tag
> > > > > to non-VLAN frame?
> > > > >
> > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> > >
> > > All of them, OF_PUSH_VLAN inserts the VLAN header, OF_SET_VLAN_VID
> > > and OF_SET_VLAN_PCP fill the fields with appropriate values.
> > >
> > > > >
> > > > > Q3. Is it possible to detag VLAN when it receives VLAN tagged
> > > > > frame from outside of the host?
> > > Do you mean some complex configuration with multiple VMs and
> engaged
> > > E-Switch feature? Anyway, there are multiple ways to strip (untag) VLAN
> header:
> > > - with E-Switch rules (including match on specified port)
> > > - with local port rules
> > > - stripping VLAN in Rx queue
> > >
> > > > >
> > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it sends
> > > > > packet to outside of host?
> > > Yes.
> > >
> > > > >
> > > > > Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
> > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is
> supported there.
> > >
> > > > >
> > > > > Q6. Is it possible to apply rte_flow actions for specified tx
> > > > > queue of physical NIC?
> > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want to
> > > > > entag VLAN 101 to the traffic from VM to PHY:0 is it possible?)
> > > Directly - no, there is no item to match with specific Tx queue.
> > >
> > > If setting VLAN on specific Tx queue is desired we have two options:
> > >
> > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide VLAN
> > > with  each packet being transferred to tx_burst
> > >
> > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set
> specific
> > > metadata for all packets on specific queue. Then the rules matching
> > > with this metadata may be inserted.
> > >
> > > [snip]
> > >
> > > With best regards, Slava
> >
> 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Slava,

Thanks for your response back.

While waiting your final response,
I am sending additional info from my side.

1 
I am using "MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64"
as OFED.

tx_h-yamashita@R730n10:~/dpdk-next-net$ pwd
/home/tx_h-yamashita/dpdk-next-net
tx_h-yamashita@R730n10:~/dpdk-next-net$ ls
app          MAINTAINERS
buildtools   Makefile
config       meson.build
devtools     meson_options.txt
doc          mk
drivers      MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64
examples     MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64.tgz
GNUmakefile  README
kernel       usertools
lib          VERSION
license      x86_64-native-linuxapp-gcc

2. 
I am using ConnextX-4 and ConnectX-5.
I attach the result of typing ethtool -i .

Bus info          Device        Class          Description
==========================================================
pci@0000:03:00.0  enp3s0f0      network        MT27710 Family [ConnectX-4 Lx]
pci@0000:03:00.1  enp3s0f1      network        MT27710 Family [ConnectX-4 Lx]
pci@0000:04:00.0  enp4s0f0      network        MT27800 Family [ConnectX-5]
pci@0000:04:00.1  enp4s0f1      network        MT27800 Family [ConnectX-5]

tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp3s0f0
driver: mlx5_core
version: 4.7-1.0.0
firmware-version: 14.25.1020 (MT_0000000266)
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes
tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp4s0f0
driver: mlx5_core
version: 4.7-1.0.0
firmware-version: 16.25.6000 (MT_0000000012)
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

If you needs more info from my side, please let me know.

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki
> 
> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Monday, October 21, 2019 10:12
> > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; Moti Haimovsky
> > <motih@mellanox.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Dear Slava, Moti and all,
> > 
> > Please let me know if you need more information.
> > Partial answer is acceptable for me.
> > 
> > Thanks in advaince!
> 
> I'm sorry for delay, your issue is still in progress.
> I've tested your rules on my standard configuration - these ones are rejected by FW/SW,
> not by DPDK code. Moti tested the flows on custom setup (I suppose experimental FW/kernel).
> AFAIK, VLAN feature was planned to GA with OFED 4.7.1,
> please, let me check it (hope in few days, there are holidays still lasting in IL).
> 
> With best regards, Slava
> > 
> > BR,
> > HIdeyuki Yamashita
> > NTT TechnoCross
> > 
> > > Dear Slava and experts,
> > >
> > > Thanks for your answering me.
> > > Baased on your answer, I tested using testpmd.
> > > And about the outcome, I have several questions.
> > >
> > >
> > > [1.Test environment]
> > > OS:Ubuntu18.04
> > > NIC1:MCX4121A-ACAT 25G
> > > NIC2:MCX516A-CCAT 100G
> > > Repo:dpdk-next-net
> > >
> > > I checked that the following is shown in git log command.
> > > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine 50735012c
> > > net/mlx5: support reading module EEPROM data
> > > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
> > > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> > > 43184603e net/mlx5: support modifying VLAN priority on VLAN header
> > > 4f59ffbd8 net/mlx5: support push flow action on VLAN header b4bd8f5da
> > > net/mlx5: support pop flow action on VLAN header 048e3e84c net/mlx5:
> > > add VLAN push/pop DR commands to glue
> > >
> > > [2.Test result]
> > > I tested the follwoing flows with testpmd included in dpdk-next-net.
> > >
> > > A.flow create 0 ingress pattern eth / vlan id is 100 / end actions
> > > OF_POP_VLAN / end B.flow create 0 ingress pattern eth dst is
> > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > > C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end
> > > actions OF_SET_VLAN_VID vlan_vid 200 / end D.flow create X ingress
> > > pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP
> > > vlan_pcp 3 / end E.flow create 0 egress pattern eth src is
> > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > >
> > > A-D, resulted in "Caught error type 16 (specific action): cause:
> > 0x7ffcc711db48, action not supported: Operation not supported".
> > > E resulted in "Egress is not supported".
> > >
> > > [3. Quetions]
> > > Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
> > >  I think related commits are included so it "should" work and my guess is
> > that my flow is somehow wrong.
> > > Q2. Is it correct understanding that "egress" is not supported for mlx5
> > PMD?
> > > Q3. If yes, is it possible to entag VLAN tag to the outgoing packet from
> > physical NIC by using rte_flow?
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Friday, October 4, 2019 13:35
> > > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Can somebody (Mellanox guys?) help me out?
> > > >
> > > > Hi, Hideyuki
> > > >
> > > > I'm sorry, there are long holidays in IL, so let me try to answer.
> > > >
> > > > >
> > > > > > Hello Moti,
> > > > > >
> > > > > > I have some questions on the patch.
> > > > > > Just want to know how to use it.
> > > > > >
> > > > > > Q1. Is it correct understanding that the patch will be reflected
> > > > > > in
> > > > > > 19.11 if it is approved?
> > > >
> > > > Yes, it is merged and should be reflected.
> > > >
> > > > > >
> > > > > > Q2.Which action should I specify when I want to insert VLAN tag
> > > > > > to non-VLAN frame?
> > > > > >
> > > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> > > >
> > > > All of them, OF_PUSH_VLAN inserts the VLAN header, OF_SET_VLAN_VID
> > > > and OF_SET_VLAN_PCP fill the fields with appropriate values.
> > > >
> > > > > >
> > > > > > Q3. Is it possible to detag VLAN when it receives VLAN tagged
> > > > > > frame from outside of the host?
> > > > Do you mean some complex configuration with multiple VMs and
> > engaged
> > > > E-Switch feature? Anyway, there are multiple ways to strip (untag) VLAN
> > header:
> > > > - with E-Switch rules (including match on specified port)
> > > > - with local port rules
> > > > - stripping VLAN in Rx queue
> > > >
> > > > > >
> > > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it sends
> > > > > > packet to outside of host?
> > > > Yes.
> > > >
> > > > > >
> > > > > > Q5.Are there any restriction to conbime other ACTIONS like QUEUE?
> > > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is
> > supported there.
> > > >
> > > > > >
> > > > > > Q6. Is it possible to apply rte_flow actions for specified tx
> > > > > > queue of physical NIC?
> > > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want to
> > > > > > entag VLAN 101 to the traffic from VM to PHY:0 is it possible?)
> > > > Directly - no, there is no item to match with specific Tx queue.
> > > >
> > > > If setting VLAN on specific Tx queue is desired we have two options:
> > > >
> > > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide VLAN
> > > > with  each packet being transferred to tx_burst
> > > >
> > > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set
> > specific
> > > > metadata for all packets on specific queue. Then the rules matching
> > > > with this metadata may be inserted.
> > > >
> > > > [snip]
> > > >
> > > > With best regards, Slava
> > >
> > 
> > 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki.

Thanks for providing extra information. 

We rechecked the VLAN actions support in OFED 4.7.1, it should be supported.
There are some limitations:
- VLAN pop is supported on ingress direction only
- VLAN push is supported on egress direction only
- not supported in group 0 (this is root table, has some limitations)
 we should insert into group 0 flow with jump to group 1, and then insert
the rule with VLAN actions to group 1

I tried this flow (on my setup OFED 4.7.1.0.0.2):

flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end
It was created successfully.

With best regards, Slava

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Friday, October 25, 2019 7:49
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: Moti Haimovsky <motih@mellanox.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Hello Slava,
> 
> Thanks for your response back.
> 
> While waiting your final response,
> I am sending additional info from my side.
> 
> 1
> I am using "MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64"
> as OFED.
> 
> tx_h-yamashita@R730n10:~/dpdk-next-net$ pwd /home/tx_h-
> yamashita/dpdk-next-net
> tx_h-yamashita@R730n10:~/dpdk-next-net$ ls
> app          MAINTAINERS
> buildtools   Makefile
> config       meson.build
> devtools     meson_options.txt
> doc          mk
> drivers      MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64
> examples     MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64.tgz
> GNUmakefile  README
> kernel       usertools
> lib          VERSION
> license      x86_64-native-linuxapp-gcc
> 
> 2.
> I am using ConnextX-4 and ConnectX-5.
> I attach the result of typing ethtool -i .
> 
> Bus info          Device        Class          Description
> ==========================================================
> pci@0000:03:00.0  enp3s0f0      network        MT27710 Family [ConnectX-4
> Lx]
> pci@0000:03:00.1  enp3s0f1      network        MT27710 Family [ConnectX-4
> Lx]
> pci@0000:04:00.0  enp4s0f0      network        MT27800 Family [ConnectX-5]
> pci@0000:04:00.1  enp4s0f1      network        MT27800 Family [ConnectX-5]
> 
> tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp3s0f0
> driver: mlx5_core
> version: 4.7-1.0.0
> firmware-version: 14.25.1020 (MT_0000000266)
> expansion-rom-version:
> bus-info: 0000:03:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: yes
> tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp4s0f0
> driver: mlx5_core
> version: 4.7-1.0.0
> firmware-version: 16.25.6000 (MT_0000000012)
> expansion-rom-version:
> bus-info: 0000:04:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: yes
> 
> If you needs more info from my side, please let me know.
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Monday, October 21, 2019 10:12
> > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; Moti Haimovsky
> > > <motih@mellanox.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Dear Slava, Moti and all,
> > >
> > > Please let me know if you need more information.
> > > Partial answer is acceptable for me.
> > >
> > > Thanks in advaince!
> >
> > I'm sorry for delay, your issue is still in progress.
> > I've tested your rules on my standard configuration - these ones are
> > rejected by FW/SW, not by DPDK code. Moti tested the flows on custom
> setup (I suppose experimental FW/kernel).
> > AFAIK, VLAN feature was planned to GA with OFED 4.7.1, please, let me
> > check it (hope in few days, there are holidays still lasting in IL).
> >
> > With best regards, Slava
> > >
> > > BR,
> > > HIdeyuki Yamashita
> > > NTT TechnoCross
> > >
> > > > Dear Slava and experts,
> > > >
> > > > Thanks for your answering me.
> > > > Baased on your answer, I tested using testpmd.
> > > > And about the outcome, I have several questions.
> > > >
> > > >
> > > > [1.Test environment]
> > > > OS:Ubuntu18.04
> > > > NIC1:MCX4121A-ACAT 25G
> > > > NIC2:MCX516A-CCAT 100G
> > > > Repo:dpdk-next-net
> > > >
> > > > I checked that the following is shown in git log command.
> > > > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine
> > > > 50735012c
> > > > net/mlx5: support reading module EEPROM data
> > > > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
> > > > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> > > > 43184603e net/mlx5: support modifying VLAN priority on VLAN header
> > > > 4f59ffbd8 net/mlx5: support push flow action on VLAN header
> > > > b4bd8f5da
> > > > net/mlx5: support pop flow action on VLAN header 048e3e84c
> net/mlx5:
> > > > add VLAN push/pop DR commands to glue
> > > >
> > > > [2.Test result]
> > > > I tested the follwoing flows with testpmd included in dpdk-next-net.
> > > >
> > > > A.flow create 0 ingress pattern eth / vlan id is 100 / end actions
> > > > OF_POP_VLAN / end B.flow create 0 ingress pattern eth dst is
> > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > > > C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end
> > > > actions OF_SET_VLAN_VID vlan_vid 200 / end D.flow create X ingress
> > > > pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP
> > > > vlan_pcp 3 / end E.flow create 0 egress pattern eth src is
> > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > > >
> > > > A-D, resulted in "Caught error type 16 (specific action): cause:
> > > 0x7ffcc711db48, action not supported: Operation not supported".
> > > > E resulted in "Egress is not supported".
> > > >
> > > > [3. Quetions]
> > > > Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
> > > >  I think related commits are included so it "should" work and my
> > > > guess is
> > > that my flow is somehow wrong.
> > > > Q2. Is it correct understanding that "egress" is not supported for
> > > > mlx5
> > > PMD?
> > > > Q3. If yes, is it possible to entag VLAN tag to the outgoing
> > > > packet from
> > > physical NIC by using rte_flow?
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > >
> > > > > > -----Original Message-----
> > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > Sent: Friday, October 4, 2019 13:35
> > > > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > > > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > action on VLAN header
> > > > > >
> > > > > > Can somebody (Mellanox guys?) help me out?
> > > > >
> > > > > Hi, Hideyuki
> > > > >
> > > > > I'm sorry, there are long holidays in IL, so let me try to answer.
> > > > >
> > > > > >
> > > > > > > Hello Moti,
> > > > > > >
> > > > > > > I have some questions on the patch.
> > > > > > > Just want to know how to use it.
> > > > > > >
> > > > > > > Q1. Is it correct understanding that the patch will be
> > > > > > > reflected in
> > > > > > > 19.11 if it is approved?
> > > > >
> > > > > Yes, it is merged and should be reflected.
> > > > >
> > > > > > >
> > > > > > > Q2.Which action should I specify when I want to insert VLAN
> > > > > > > tag to non-VLAN frame?
> > > > > > >
> > > > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> > > > >
> > > > > All of them, OF_PUSH_VLAN inserts the VLAN header,
> > > > > OF_SET_VLAN_VID and OF_SET_VLAN_PCP fill the fields with
> appropriate values.
> > > > >
> > > > > > >
> > > > > > > Q3. Is it possible to detag VLAN when it receives VLAN
> > > > > > > tagged frame from outside of the host?
> > > > > Do you mean some complex configuration with multiple VMs and
> > > engaged
> > > > > E-Switch feature? Anyway, there are multiple ways to strip
> > > > > (untag) VLAN
> > > header:
> > > > > - with E-Switch rules (including match on specified port)
> > > > > - with local port rules
> > > > > - stripping VLAN in Rx queue
> > > > >
> > > > > > >
> > > > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it
> > > > > > > sends packet to outside of host?
> > > > > Yes.
> > > > >
> > > > > > >
> > > > > > > Q5.Are there any restriction to conbime other ACTIONS like
> QUEUE?
> > > > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is
> > > supported there.
> > > > >
> > > > > > >
> > > > > > > Q6. Is it possible to apply rte_flow actions for specified
> > > > > > > tx queue of physical NIC?
> > > > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want
> > > > > > > to entag VLAN 101 to the traffic from VM to PHY:0 is it
> > > > > > > possible?)
> > > > > Directly - no, there is no item to match with specific Tx queue.
> > > > >
> > > > > If setting VLAN on specific Tx queue is desired we have two options:
> > > > >
> > > > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide
> VLAN
> > > > > with  each packet being transferred to tx_burst
> > > > >
> > > > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set
> > > specific
> > > > > metadata for all packets on specific queue. Then the rules
> > > > > matching with this metadata may be inserted.
> > > > >
> > > > > [snip]
> > > > >
> > > > > With best regards, Slava
> > > >
> > >
> > >
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hi Slava,

Thanks for your response back and letting me know the limitation.

I tried to input flow you suggested.
But it returns error.

testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end
Caught error type 3 (group field): groups is not supported: Operation not supported

Note that my setup OFED is NOT 4.7.1.0.0.2, but 4.7.1.0.0.1
because that is the latest version which I can download from the
following web site.

https://jp.mellanox.com/page/products_dyn?product_family=26&ssn=u44h3rn8ngcmbdl6v0fvhqrgt3

Do you have any hints?

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki.
> 
> Thanks for providing extra information. 
> 
> We rechecked the VLAN actions support in OFED 4.7.1, it should be supported.
> There are some limitations:
> - VLAN pop is supported on ingress direction only
> - VLAN push is supported on egress direction only
> - not supported in group 0 (this is root table, has some limitations)
>  we should insert into group 0 flow with jump to group 1, and then insert
> the rule with VLAN actions to group 1
> 
> I tried this flow (on my setup OFED 4.7.1.0.0.2):
> 
> flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end
> It was created successfully.
> 
> With best regards, Slava
> 
> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Friday, October 25, 2019 7:49
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: Moti Haimovsky <motih@mellanox.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Hello Slava,
> > 
> > Thanks for your response back.
> > 
> > While waiting your final response,
> > I am sending additional info from my side.
> > 
> > 1
> > I am using "MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64"
> > as OFED.
> > 
> > tx_h-yamashita@R730n10:~/dpdk-next-net$ pwd /home/tx_h-
> > yamashita/dpdk-next-net
> > tx_h-yamashita@R730n10:~/dpdk-next-net$ ls
> > app          MAINTAINERS
> > buildtools   Makefile
> > config       meson.build
> > devtools     meson_options.txt
> > doc          mk
> > drivers      MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64
> > examples     MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64.tgz
> > GNUmakefile  README
> > kernel       usertools
> > lib          VERSION
> > license      x86_64-native-linuxapp-gcc
> > 
> > 2.
> > I am using ConnextX-4 and ConnectX-5.
> > I attach the result of typing ethtool -i .
> > 
> > Bus info          Device        Class          Description
> > ==========================================================
> > pci@0000:03:00.0  enp3s0f0      network        MT27710 Family [ConnectX-4
> > Lx]
> > pci@0000:03:00.1  enp3s0f1      network        MT27710 Family [ConnectX-4
> > Lx]
> > pci@0000:04:00.0  enp4s0f0      network        MT27800 Family [ConnectX-5]
> > pci@0000:04:00.1  enp4s0f1      network        MT27800 Family [ConnectX-5]
> > 
> > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp3s0f0
> > driver: mlx5_core
> > version: 4.7-1.0.0
> > firmware-version: 14.25.1020 (MT_0000000266)
> > expansion-rom-version:
> > bus-info: 0000:03:00.0
> > supports-statistics: yes
> > supports-test: yes
> > supports-eeprom-access: no
> > supports-register-dump: no
> > supports-priv-flags: yes
> > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp4s0f0
> > driver: mlx5_core
> > version: 4.7-1.0.0
> > firmware-version: 16.25.6000 (MT_0000000012)
> > expansion-rom-version:
> > bus-info: 0000:04:00.0
> > supports-statistics: yes
> > supports-test: yes
> > supports-eeprom-access: no
> > supports-register-dump: no
> > supports-priv-flags: yes
> > 
> > If you needs more info from my side, please let me know.
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > > Hi, Hideyuki
> > >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Monday, October 21, 2019 10:12
> > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; Moti Haimovsky
> > > > <motih@mellanox.com>; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Dear Slava, Moti and all,
> > > >
> > > > Please let me know if you need more information.
> > > > Partial answer is acceptable for me.
> > > >
> > > > Thanks in advaince!
> > >
> > > I'm sorry for delay, your issue is still in progress.
> > > I've tested your rules on my standard configuration - these ones are
> > > rejected by FW/SW, not by DPDK code. Moti tested the flows on custom
> > setup (I suppose experimental FW/kernel).
> > > AFAIK, VLAN feature was planned to GA with OFED 4.7.1, please, let me
> > > check it (hope in few days, there are holidays still lasting in IL).
> > >
> > > With best regards, Slava
> > > >
> > > > BR,
> > > > HIdeyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > > > Dear Slava and experts,
> > > > >
> > > > > Thanks for your answering me.
> > > > > Baased on your answer, I tested using testpmd.
> > > > > And about the outcome, I have several questions.
> > > > >
> > > > >
> > > > > [1.Test environment]
> > > > > OS:Ubuntu18.04
> > > > > NIC1:MCX4121A-ACAT 25G
> > > > > NIC2:MCX516A-CCAT 100G
> > > > > Repo:dpdk-next-net
> > > > >
> > > > > I checked that the following is shown in git log command.
> > > > > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine
> > > > > 50735012c
> > > > > net/mlx5: support reading module EEPROM data
> > > > > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header
> > > > > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> > > > > 43184603e net/mlx5: support modifying VLAN priority on VLAN header
> > > > > 4f59ffbd8 net/mlx5: support push flow action on VLAN header
> > > > > b4bd8f5da
> > > > > net/mlx5: support pop flow action on VLAN header 048e3e84c
> > net/mlx5:
> > > > > add VLAN push/pop DR commands to glue
> > > > >
> > > > > [2.Test result]
> > > > > I tested the follwoing flows with testpmd included in dpdk-next-net.
> > > > >
> > > > > A.flow create 0 ingress pattern eth / vlan id is 100 / end actions
> > > > > OF_POP_VLAN / end B.flow create 0 ingress pattern eth dst is
> > > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > > > > C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end
> > > > > actions OF_SET_VLAN_VID vlan_vid 200 / end D.flow create X ingress
> > > > > pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP
> > > > > vlan_pcp 3 / end E.flow create 0 egress pattern eth src is
> > > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end
> > > > >
> > > > > A-D, resulted in "Caught error type 16 (specific action): cause:
> > > > 0x7ffcc711db48, action not supported: Operation not supported".
> > > > > E resulted in "Egress is not supported".
> > > > >
> > > > > [3. Quetions]
> > > > > Q1. What is the appropriate flow to entag/detag VLAN using testpmd?
> > > > >  I think related commits are included so it "should" work and my
> > > > > guess is
> > > > that my flow is somehow wrong.
> > > > > Q2. Is it correct understanding that "egress" is not supported for
> > > > > mlx5
> > > > PMD?
> > > > > Q3. If yes, is it possible to entag VLAN tag to the outgoing
> > > > > packet from
> > > > physical NIC by using rte_flow?
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > Sent: Friday, October 4, 2019 13:35
> > > > > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > > action on VLAN header
> > > > > > >
> > > > > > > Can somebody (Mellanox guys?) help me out?
> > > > > >
> > > > > > Hi, Hideyuki
> > > > > >
> > > > > > I'm sorry, there are long holidays in IL, so let me try to answer.
> > > > > >
> > > > > > >
> > > > > > > > Hello Moti,
> > > > > > > >
> > > > > > > > I have some questions on the patch.
> > > > > > > > Just want to know how to use it.
> > > > > > > >
> > > > > > > > Q1. Is it correct understanding that the patch will be
> > > > > > > > reflected in
> > > > > > > > 19.11 if it is approved?
> > > > > >
> > > > > > Yes, it is merged and should be reflected.
> > > > > >
> > > > > > > >
> > > > > > > > Q2.Which action should I specify when I want to insert VLAN
> > > > > > > > tag to non-VLAN frame?
> > > > > > > >
> > > > > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ?
> > > > > >
> > > > > > All of them, OF_PUSH_VLAN inserts the VLAN header,
> > > > > > OF_SET_VLAN_VID and OF_SET_VLAN_PCP fill the fields with
> > appropriate values.
> > > > > >
> > > > > > > >
> > > > > > > > Q3. Is it possible to detag VLAN when it receives VLAN
> > > > > > > > tagged frame from outside of the host?
> > > > > > Do you mean some complex configuration with multiple VMs and
> > > > engaged
> > > > > > E-Switch feature? Anyway, there are multiple ways to strip
> > > > > > (untag) VLAN
> > > > header:
> > > > > > - with E-Switch rules (including match on specified port)
> > > > > > - with local port rules
> > > > > > - stripping VLAN in Rx queue
> > > > > >
> > > > > > > >
> > > > > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it
> > > > > > > > sends packet to outside of host?
> > > > > > Yes.
> > > > > >
> > > > > > > >
> > > > > > > > Q5.Are there any restriction to conbime other ACTIONS like
> > QUEUE?
> > > > > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is
> > > > supported there.
> > > > > >
> > > > > > > >
> > > > > > > > Q6. Is it possible to apply rte_flow actions for specified
> > > > > > > > tx queue of physical NIC?
> > > > > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want
> > > > > > > > to entag VLAN 101 to the traffic from VM to PHY:0 is it
> > > > > > > > possible?)
> > > > > > Directly - no, there is no item to match with specific Tx queue.
> > > > > >
> > > > > > If setting VLAN on specific Tx queue is desired we have two options:
> > > > > >
> > > > > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide
> > VLAN
> > > > > > with  each packet being transferred to tx_burst
> > > > > >
> > > > > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set
> > > > specific
> > > > > > metadata for all packets on specific queue. Then the rules
> > > > > > matching with this metadata may be inserted.
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > With best regards, Slava
> > > > >
> > > >
> > > >
> > 
>

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Wednesday, October 30, 2019 12:05
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: Moti Haimovsky <motih@mellanox.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Hi Slava,
> 
> Thanks for your response back and letting me know the limitation.
> 
> I tried to input flow you suggested.
> But it returns error.

Did you specify the magic "dv_flow_en=1" devarg in testpmd command line?
Something like this: "-w 82:00.0,dv_flow_en=1"

With best regards, Slava


> 
> testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan
> testpmd> / queue index 0 / end
> Caught error type 3 (group field): groups is not supported: Operation not
> supported
> 
> Note that my setup OFED is NOT 4.7.1.0.0.2, but 4.7.1.0.0.1 because that is
> the latest version which I can download from the following web site.
> 
> https://jp.mellanox.com/page/products_dyn?product_family=26&ssn=u44h3
> rn8ngcmbdl6v0fvhqrgt3
> 
> Do you have any hints?
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki.
> >
> > Thanks for providing extra information.
> >
> > We rechecked the VLAN actions support in OFED 4.7.1, it should be
> supported.
> > There are some limitations:
> > - VLAN pop is supported on ingress direction only
> > - VLAN push is supported on egress direction only
> > - not supported in group 0 (this is root table, has some limitations)
> > we should insert into group 0 flow with jump to group 1, and then
> > insert the rule with VLAN actions to group 1
> >
> > I tried this flow (on my setup OFED 4.7.1.0.0.2):
> >
> > flow create 0 ingress group 1 priority 0 pattern eth dst is
> > 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue
> index 0 / end It was created successfully.
> >
> > With best regards, Slava
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Friday, October 25, 2019 7:49
> > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Cc: Moti Haimovsky <motih@mellanox.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Hello Slava,
> > >
> > > Thanks for your response back.
> > >
> > > While waiting your final response,
> > > I am sending additional info from my side.
> > >
> > > 1
> > > I am using "MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64"
> > > as OFED.
> > >
> > > tx_h-yamashita@R730n10:~/dpdk-next-net$ pwd /home/tx_h-
> > > yamashita/dpdk-next-net tx_h-yamashita@R730n10:~/dpdk-next-net$ ls
> > > app          MAINTAINERS
> > > buildtools   Makefile
> > > config       meson.build
> > > devtools     meson_options.txt
> > > doc          mk
> > > drivers      MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64
> > > examples     MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64.tgz
> > > GNUmakefile  README
> > > kernel       usertools
> > > lib          VERSION
> > > license      x86_64-native-linuxapp-gcc
> > >
> > > 2.
> > > I am using ConnextX-4 and ConnectX-5.
> > > I attach the result of typing ethtool -i .
> > >
> > > Bus info          Device        Class          Description
> > > ==========================================================
> > > pci@0000:03:00.0  enp3s0f0      network        MT27710 Family [ConnectX-
> 4
> > > Lx]
> > > pci@0000:03:00.1  enp3s0f1      network        MT27710 Family [ConnectX-
> 4
> > > Lx]
> > > pci@0000:04:00.0  enp4s0f0      network        MT27800 Family [ConnectX-
> 5]
> > > pci@0000:04:00.1  enp4s0f1      network        MT27800 Family [ConnectX-
> 5]
> > >
> > > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp3s0f0
> > > driver: mlx5_core
> > > version: 4.7-1.0.0
> > > firmware-version: 14.25.1020 (MT_0000000266)
> > > expansion-rom-version:
> > > bus-info: 0000:03:00.0
> > > supports-statistics: yes
> > > supports-test: yes
> > > supports-eeprom-access: no
> > > supports-register-dump: no
> > > supports-priv-flags: yes
> > > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp4s0f0
> > > driver: mlx5_core
> > > version: 4.7-1.0.0
> > > firmware-version: 16.25.6000 (MT_0000000012)
> > > expansion-rom-version:
> > > bus-info: 0000:04:00.0
> > > supports-statistics: yes
> > > supports-test: yes
> > > supports-eeprom-access: no
> > > supports-register-dump: no
> > > supports-priv-flags: yes
> > >
> > > If you needs more info from my side, please let me know.
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > > > Hi, Hideyuki
> > > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Monday, October 21, 2019 10:12
> > > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; Moti Haimovsky
> > > > > <motih@mellanox.com>; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Dear Slava, Moti and all,
> > > > >
> > > > > Please let me know if you need more information.
> > > > > Partial answer is acceptable for me.
> > > > >
> > > > > Thanks in advaince!
> > > >
> > > > I'm sorry for delay, your issue is still in progress.
> > > > I've tested your rules on my standard configuration - these ones
> > > > are rejected by FW/SW, not by DPDK code. Moti tested the flows on
> > > > custom
> > > setup (I suppose experimental FW/kernel).
> > > > AFAIK, VLAN feature was planned to GA with OFED 4.7.1, please, let
> > > > me check it (hope in few days, there are holidays still lasting in IL).
> > > >
> > > > With best regards, Slava
> > > > >
> > > > > BR,
> > > > > HIdeyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > > > Dear Slava and experts,
> > > > > >
> > > > > > Thanks for your answering me.
> > > > > > Baased on your answer, I tested using testpmd.
> > > > > > And about the outcome, I have several questions.
> > > > > >
> > > > > >
> > > > > > [1.Test environment]
> > > > > > OS:Ubuntu18.04
> > > > > > NIC1:MCX4121A-ACAT 25G
> > > > > > NIC2:MCX516A-CCAT 100G
> > > > > > Repo:dpdk-next-net
> > > > > >
> > > > > > I checked that the following is shown in git log command.
> > > > > > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine
> > > > > > 50735012c
> > > > > > net/mlx5: support reading module EEPROM data
> > > > > > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN
> > > > > > header
> > > > > > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header
> > > > > > 43184603e net/mlx5: support modifying VLAN priority on VLAN
> > > > > > header
> > > > > > 4f59ffbd8 net/mlx5: support push flow action on VLAN header
> > > > > > b4bd8f5da
> > > > > > net/mlx5: support pop flow action on VLAN header 048e3e84c
> > > net/mlx5:
> > > > > > add VLAN push/pop DR commands to glue
> > > > > >
> > > > > > [2.Test result]
> > > > > > I tested the follwoing flows with testpmd included in dpdk-next-net.
> > > > > >
> > > > > > A.flow create 0 ingress pattern eth / vlan id is 100 / end
> > > > > > actions OF_POP_VLAN / end B.flow create 0 ingress pattern eth
> > > > > > dst is BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype
> > > > > > 1000 / end C.flow create 0 ingress pattern eth dst is
> > > > > > BB:BB:BB:BB:BB:BB / end actions OF_SET_VLAN_VID vlan_vid 200 /
> > > > > > end D.flow create X ingress pattern eth dst is
> > > > > > BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP vlan_pcp 3 /
> > > > > > end E.flow create 0 egress pattern eth src is
> > > > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 /
> > > > > > end
> > > > > >
> > > > > > A-D, resulted in "Caught error type 16 (specific action): cause:
> > > > > 0x7ffcc711db48, action not supported: Operation not supported".
> > > > > > E resulted in "Egress is not supported".
> > > > > >
> > > > > > [3. Quetions]
> > > > > > Q1. What is the appropriate flow to entag/detag VLAN using
> testpmd?
> > > > > >  I think related commits are included so it "should" work and
> > > > > > my guess is
> > > > > that my flow is somehow wrong.
> > > > > > Q2. Is it correct understanding that "egress" is not supported
> > > > > > for
> > > > > > mlx5
> > > > > PMD?
> > > > > > Q3. If yes, is it possible to entag VLAN tag to the outgoing
> > > > > > packet from
> > > > > physical NIC by using rte_flow?
> > > > > >
> > > > > > BR,
> > > > > > Hideyuki Yamashita
> > > > > > NTT TechnoCross
> > > > > >
> > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > > Sent: Friday, October 4, 2019 13:35
> > > > > > > > To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > > Cc: Moti Haimovsky <motih@mellanox.com>; Slava Ovsiienko
> > > > > > > > <viacheslavo@mellanox.com>; dev@dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for
> > > > > > > > flow action on VLAN header
> > > > > > > >
> > > > > > > > Can somebody (Mellanox guys?) help me out?
> > > > > > >
> > > > > > > Hi, Hideyuki
> > > > > > >
> > > > > > > I'm sorry, there are long holidays in IL, so let me try to answer.
> > > > > > >
> > > > > > > >
> > > > > > > > > Hello Moti,
> > > > > > > > >
> > > > > > > > > I have some questions on the patch.
> > > > > > > > > Just want to know how to use it.
> > > > > > > > >
> > > > > > > > > Q1. Is it correct understanding that the patch will be
> > > > > > > > > reflected in
> > > > > > > > > 19.11 if it is approved?
> > > > > > >
> > > > > > > Yes, it is merged and should be reflected.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Q2.Which action should I specify when I want to insert
> > > > > > > > > VLAN tag to non-VLAN frame?
> > > > > > > > >
> > > > > > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and
> OF_SET_VLAN_PCP ?
> > > > > > >
> > > > > > > All of them, OF_PUSH_VLAN inserts the VLAN header,
> > > > > > > OF_SET_VLAN_VID and OF_SET_VLAN_PCP fill the fields with
> > > appropriate values.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Q3. Is it possible to detag VLAN when it receives VLAN
> > > > > > > > > tagged frame from outside of the host?
> > > > > > > Do you mean some complex configuration with multiple VMs and
> > > > > engaged
> > > > > > > E-Switch feature? Anyway, there are multiple ways to strip
> > > > > > > (untag) VLAN
> > > > > header:
> > > > > > > - with E-Switch rules (including match on specified port)
> > > > > > > - with local port rules
> > > > > > > - stripping VLAN in Rx queue
> > > > > > >
> > > > > > > > >
> > > > > > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when
> > > > > > > > > it sends packet to outside of host?
> > > > > > > Yes.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Q5.Are there any restriction to conbime other ACTIONS
> > > > > > > > > like
> > > QUEUE?
> > > > > > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP
> > > > > > > is
> > > > > supported there.
> > > > > > >
> > > > > > > > >
> > > > > > > > > Q6. Is it possible to apply rte_flow actions for
> > > > > > > > > specified tx queue of physical NIC?
> > > > > > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I
> > > > > > > > > want to entag VLAN 101 to the traffic from VM to PHY:0
> > > > > > > > > is it
> > > > > > > > > possible?)
> > > > > > > Directly - no, there is no item to match with specific Tx queue.
> > > > > > >
> > > > > > > If setting VLAN on specific Tx queue is desired we have two
> options:
> > > > > > >
> > > > > > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and
> provide
> > > VLAN
> > > > > > > with  each packet being transferred to tx_burst
> > > > > > >
> > > > > > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set
> > > > > specific
> > > > > > > metadata for all packets on specific queue. Then the rules
> > > > > > > matching with this metadata may be inserted.
> > > > > > >
> > > > > > > [snip]
> > > > > > >
> > > > > > > With best regards, Slava
> > > > > >
> > > > >
> > > > >
> > >
> >
> 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Slava,

Thanks for your help.
I added magic phrase. with chaging PCI number with proper one in my env.
It changes situation but still result in error.

I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
Your help is appreciated.

I think it is getting closer.


tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-gcc/app$
sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem 512,512
--huge-dir=/mnt/h
uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2 --txq=16 --rxq=16
EAL: Detected 48 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: PCI device 0000:03:00.0 on NUMA socket 0
EAL:   probe driver: 15b3:1015 net_mlx5
net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device mlx5_3

Interactive-mode selected
testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456, size=2176, socket=1
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will pair with itself.

Configuring Port 0 (socket 0)
Port 0: B8:59:9F:DB:22:20
Checking link statuses...
Done
testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end
Caught error type 1 (cause unspecified): cannot create table: Cannot allocate memory


BR,
Hideyuki Yamashita

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Wednesday, October 30, 2019 12:46
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Hello Slava,
> 
> Thanks for your help.
> I added magic phrase. with chaging PCI number with proper one in my env.

> It changes situation but still result in error.
> 
> I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> Your help is appreciated.
> 
> I think it is getting closer.
> tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> gcc/app$
> sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem 512,512 -
> -huge-dir=/mnt/h uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2

mlx5 PMD supports two flow engines:
- Verbs, this is legacy one, almost no new features are being added, just bug fixes,
  provides slow rule insertion rate, etc.
- Direct Rules, the new one, all new features are being added here.

(We had one more intermediate engine  - Direct Verbs, it was dropped,
but prefix dv in dv_flow_en remains 😊)

Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX, ConnectX-5, ConnectX-6, etc.
Direct Rules is supported for NICs starting from ConnectX-5.
"dv_flow_en=1" partameter engages Direct Rules, but I see you run testpmd
over 03:00.0 which is ConnectX-4, not  supporting Direct Rules.
Please, run over ConnectX-5 you have on your host.

As for error - it is not related to memory, rdma core just failed to create the group table,
because ConnectX-4 does not support DR.

With best regards, Slava

> --txq=16 --rxq=16
> EAL: Detected 48 lcore(s)
> EAL: Detected 2 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: Selected IOVA mode 'PA'
> EAL: Probing VFIO support...
> EAL: PCI device 0000:03:00.0 on NUMA socket 0
> EAL:   probe driver: 15b3:1015 net_mlx5
> net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device
> mlx5_3
> 
> Interactive-mode selected
> testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> size=2176, socket=0
> testpmd: preferred mempool ops selected: ring_mp_mc
> testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> size=2176, socket=1
> testpmd: preferred mempool ops selected: ring_mp_mc
> 
> Warning! port-topology=paired and odd forward ports number, the last port
> will pair with itself.
> 
> Configuring Port 0 (socket 0)
> Port 0: B8:59:9F:DB:22:20
> Checking link statuses...
> Done
> testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan
> testpmd> / queue index 0 / end
> Caught error type 1 (cause unspecified): cannot create table: Cannot allocate
> memory
> 
> 
> BR,
> Hideyuki Yamashita

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Dear Slava,

Your guess is corrrect.
When I put flow into Connect-X5, it was successful.

General question.
Are there any way to input flow to ConnectX-4?
In another word, are there any way to activate Verb?
And which type of flow is supported in Verb?

-----------------------------------------------------------
tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --socket-mem 512,512 --huge-dir=/mnt/h
uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2 --txq=16 --rxq=16
[sudo] password for tx_h-yamashita:
EAL: Detected 48 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: PCI device 0000:04:00.0 on NUMA socket 0
EAL:   probe driver: 15b3:1017 net_mlx5
net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device mlx5_          1

Interactive-mode selected

testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456, size=2176, socke          t=0
testpmd: preferred mempool ops selected: ring_mp_mc
testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456, size=2176, socke          t=1
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will p          air with itself.

Configuring Port 0 (socket 0)
Port 0: B8:59:9F:C1:4A:CE
Checking link statuses...
Done
testpmd>
testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  / queue index 0 / end
Flow rule #0 created
testpmd>
--------------------------------------------------------------------------------------------------------------

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki
> 
> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Wednesday, October 30, 2019 12:46
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Hello Slava,
> > 
> > Thanks for your help.
> > I added magic phrase. with chaging PCI number with proper one in my env.
> 
> > It changes situation but still result in error.
> > 
> > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > Your help is appreciated.
> > 
> > I think it is getting closer.
> > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > gcc/app$
> > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem 512,512 -
> > -huge-dir=/mnt/h uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2
> 
> mlx5 PMD supports two flow engines:
> - Verbs, this is legacy one, almost no new features are being added, just bug fixes,
>   provides slow rule insertion rate, etc.
> - Direct Rules, the new one, all new features are being added here.
> 
> (We had one more intermediate engine  - Direct Verbs, it was dropped,
> but prefix dv in dv_flow_en remains ??)
> 
> Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX, ConnectX-5, ConnectX-6, etc.
> Direct Rules is supported for NICs starting from ConnectX-5.
> "dv_flow_en=1" partameter engages Direct Rules, but I see you run testpmd
> over 03:00.0 which is ConnectX-4, not  supporting Direct Rules.
> Please, run over ConnectX-5 you have on your host.
> 
> As for error - it is not related to memory, rdma core just failed to create the group table,
> because ConnectX-4 does not support DR.
> 
> With best regards, Slava
> 
> > --txq=16 --rxq=16
> > EAL: Detected 48 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > EAL: Selected IOVA mode 'PA'
> > EAL: Probing VFIO support...
> > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > EAL:   probe driver: 15b3:1015 net_mlx5
> > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device
> > mlx5_3
> > 
> > Interactive-mode selected
> > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > size=2176, socket=0
> > testpmd: preferred mempool ops selected: ring_mp_mc
> > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > size=2176, socket=1
> > testpmd: preferred mempool ops selected: ring_mp_mc
> > 
> > Warning! port-topology=paired and odd forward ports number, the last port
> > will pair with itself.
> > 
> > Configuring Port 0 (socket 0)
> > Port 0: B8:59:9F:DB:22:20
> > Checking link statuses...
> > Done
> > testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> > testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan
> > testpmd> / queue index 0 / end
> > Caught error type 1 (cause unspecified): cannot create table: Cannot allocate
> > memory
> > 
> > 
> > BR,
> > Hideyuki Yamashita
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Thursday, October 31, 2019 11:52
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Dear Slava,
> 
> Your guess is corrrect.
> When I put flow into Connect-X5, it was successful.
Very nice.

> 
> General question.
As we know - general questions are the most hard ones to answer 😊.

> Are there any way to input flow to ConnectX-4?
As usual - with RTE flow API.  Just omit dv_flow_en, or specify dv_flow_en=0
and mlx5 PMD will handle RTE flow API via Verbs engine, supported by ConnectX-4. 

> In another word, are there any way to activate Verb?
> And which type of flow is supported in Verb?
Please, see flow_verbs_validate() routine in the mlx5_flow_verbs.c,
it shows which RTE flow items and actions are actually supported by Verbs.

With best regards, Slava


> 
> -----------------------------------------------------------
> tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --socket-
> mem 512,512 --huge-dir=/mnt/h
> uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2 --txq=16 --rxq=16
> [sudo] password for tx_h-yamashita:
> EAL: Detected 48 lcore(s)
> EAL: Detected 2 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: Selected IOVA mode 'PA'
> EAL: Probing VFIO support...
> EAL: PCI device 0000:04:00.0 on NUMA socket 0
> EAL:   probe driver: 15b3:1017 net_mlx5
> net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device
> mlx5_          1
> 
> Interactive-mode selected
> 
> testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> size=2176, socke          t=0
> testpmd: preferred mempool ops selected: ring_mp_mc
> testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> size=2176, socke          t=1
> testpmd: preferred mempool ops selected: ring_mp_mc
> 
> Warning! port-topology=paired and odd forward ports number, the last port
> will p          air with itself.
> 
> Configuring Port 0 (socket 0)
> Port 0: B8:59:9F:C1:4A:CE
> Checking link statuses...
> Done
> testpmd>
> testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst is
> 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  / queue
> index 0 / end
> Flow rule #0 created
> testpmd>
> ---------------------------------------------------------------------------------------------
> -----------------
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Wednesday, October 30, 2019 12:46
> > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Hello Slava,
> > >
> > > Thanks for your help.
> > > I added magic phrase. with chaging PCI number with proper one in my
> env.
> >
> > > It changes situation but still result in error.
> > >
> > > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > > Your help is appreciated.
> > >
> > > I think it is getting closer.
> > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > gcc/app$
> > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem
> > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > --portmask=0x1 --nb-cores=2
> >
> > mlx5 PMD supports two flow engines:
> > - Verbs, this is legacy one, almost no new features are being added, just
> bug fixes,
> >   provides slow rule insertion rate, etc.
> > - Direct Rules, the new one, all new features are being added here.
> >
> > (We had one more intermediate engine  - Direct Verbs, it was dropped,
> > but prefix dv in dv_flow_en remains ??)
> >
> > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX, ConnectX-5,
> ConnectX-6, etc.
> > Direct Rules is supported for NICs starting from ConnectX-5.
> > "dv_flow_en=1" partameter engages Direct Rules, but I see you run
> > testpmd over 03:00.0 which is ConnectX-4, not  supporting Direct Rules.
> > Please, run over ConnectX-5 you have on your host.
> >
> > As for error - it is not related to memory, rdma core just failed to
> > create the group table, because ConnectX-4 does not support DR.
> >
> > With best regards, Slava
> >
> > > --txq=16 --rxq=16
> > > EAL: Detected 48 lcore(s)
> > > EAL: Detected 2 NUMA nodes
> > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > EAL: Selected IOVA mode 'PA'
> > > EAL: Probing VFIO support...
> > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on
> > > device
> > > mlx5_3
> > >
> > > Interactive-mode selected
> > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > size=2176, socket=0
> > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > size=2176, socket=1
> > > testpmd: preferred mempool ops selected: ring_mp_mc
> > >
> > > Warning! port-topology=paired and odd forward ports number, the last
> > > port will pair with itself.
> > >
> > > Configuring Port 0 (socket 0)
> > > Port 0: B8:59:9F:DB:22:20
> > > Checking link statuses...
> > > Done
> > > testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> > > testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions
> > > testpmd> of_pop_vlan / queue index 0 / end
> > > Caught error type 1 (cause unspecified): cannot create table: Cannot
> > > allocate memory
> > >
> > >
> > > BR,
> > > Hideyuki Yamashita
> >
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Dear Slava,

Thanks for your response.

Inputting other flows failed while some flows are created.
Please help on the following two cases.

1) I would like to detag vlan tag which has specific destionation MAC
address.  No condition about vlan id value.

testpmd> flow create 0 ingress group 1 pattern eth dst is AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan / queue index 1 / end
Caught error type 10 (item specification): VLAN cannot be empty: Invalid argument
testpmd> flow create 0 ingress group 1 pattern eth dst is AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions of_pop_vlan / queue index 1 / end
Flow rule #0 created

2) I would like to entag vlan tag

testpmd> flow create 0 egress group 1 pattern eth src is BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp vlan_pcp 3 / end
Caught error type 16 (specific action): cause: 0x7ffdc9d98348, match on VLAN is required in order to set VLAN VID: Invalid argument

Thanks!

BR,
Hideyuki Yamashita
NTT TechnoCross



> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Thursday, October 31, 2019 11:52
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Dear Slava,
> > 
> > Your guess is corrrect.
> > When I put flow into Connect-X5, it was successful.
> Very nice.
> 
> > 
> > General question.
> As we know - general questions are the most hard ones to answer ??.
> 
> > Are there any way to input flow to ConnectX-4?
> As usual - with RTE flow API.  Just omit dv_flow_en, or specify dv_flow_en=0
> and mlx5 PMD will handle RTE flow API via Verbs engine, supported by ConnectX-4. 
> 
> > In another word, are there any way to activate Verb?
> > And which type of flow is supported in Verb?
> Please, see flow_verbs_validate() routine in the mlx5_flow_verbs.c,
> it shows which RTE flow items and actions are actually supported by Verbs.
> 
> With best regards, Slava
> 
> 
> > 
> > -----------------------------------------------------------
> > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --socket-
> > mem 512,512 --huge-dir=/mnt/h
> > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2 --txq=16 --rxq=16
> > [sudo] password for tx_h-yamashita:
> > EAL: Detected 48 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > EAL: Selected IOVA mode 'PA'
> > EAL: Probing VFIO support...
> > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > EAL:   probe driver: 15b3:1017 net_mlx5
> > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device
> > mlx5_          1
> > 
> > Interactive-mode selected
> > 
> > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > size=2176, socke          t=0
> > testpmd: preferred mempool ops selected: ring_mp_mc
> > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > size=2176, socke          t=1
> > testpmd: preferred mempool ops selected: ring_mp_mc
> > 
> > Warning! port-topology=paired and odd forward ports number, the last port
> > will p          air with itself.
> > 
> > Configuring Port 0 (socket 0)
> > Port 0: B8:59:9F:C1:4A:CE
> > Checking link statuses...
> > Done
> > testpmd>
> > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst is
> > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  / queue
> > index 0 / end
> > Flow rule #0 created
> > testpmd>
> > ---------------------------------------------------------------------------------------------
> > -----------------
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > > Hi, Hideyuki
> > >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Wednesday, October 30, 2019 12:46
> > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Hello Slava,
> > > >
> > > > Thanks for your help.
> > > > I added magic phrase. with chaging PCI number with proper one in my
> > env.
> > >
> > > > It changes situation but still result in error.
> > > >
> > > > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > > > Your help is appreciated.
> > > >
> > > > I think it is getting closer.
> > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > > gcc/app$
> > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem
> > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > --portmask=0x1 --nb-cores=2
> > >
> > > mlx5 PMD supports two flow engines:
> > > - Verbs, this is legacy one, almost no new features are being added, just
> > bug fixes,
> > >   provides slow rule insertion rate, etc.
> > > - Direct Rules, the new one, all new features are being added here.
> > >
> > > (We had one more intermediate engine  - Direct Verbs, it was dropped,
> > > but prefix dv in dv_flow_en remains ??)
> > >
> > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX, ConnectX-5,
> > ConnectX-6, etc.
> > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > "dv_flow_en=1" partameter engages Direct Rules, but I see you run
> > > testpmd over 03:00.0 which is ConnectX-4, not  supporting Direct Rules.
> > > Please, run over ConnectX-5 you have on your host.
> > >
> > > As for error - it is not related to memory, rdma core just failed to
> > > create the group table, because ConnectX-4 does not support DR.
> > >
> > > With best regards, Slava
> > >
> > > > --txq=16 --rxq=16
> > > > EAL: Detected 48 lcore(s)
> > > > EAL: Detected 2 NUMA nodes
> > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > EAL: Selected IOVA mode 'PA'
> > > > EAL: Probing VFIO support...
> > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on
> > > > device
> > > > mlx5_3
> > > >
> > > > Interactive-mode selected
> > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > > size=2176, socket=0
> > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > > size=2176, socket=1
> > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > >
> > > > Warning! port-topology=paired and odd forward ports number, the last
> > > > port will pair with itself.
> > > >
> > > > Configuring Port 0 (socket 0)
> > > > Port 0: B8:59:9F:DB:22:20
> > > > Checking link statuses...
> > > > Done
> > > > testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> > > > testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions
> > > > testpmd> of_pop_vlan / queue index 0 / end
> > > > Caught error type 1 (cause unspecified): cannot create table: Cannot
> > > > allocate memory
> > > >
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > >
> > 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Dear Slava,

Additional question.
When I use testpmd in dpdk-next-net repo, it works in general.
However when I use dpdk19.11-rc1,  testpmd does not recognize connectX-5
NIC.

Is it correct that ConnectX-5 will be recognized in 19.11 release
finally?
If yes, which release candidate the necessary change will be mergerd and
available?

BR,
Hideyuki Yamashita
NTT TechnoCross


> Dear Slava,
> 
> Thanks for your response.
> 
> Inputting other flows failed while some flows are created.
> Please help on the following two cases.
> 
> 1) I would like to detag vlan tag which has specific destionation MAC
> address.  No condition about vlan id value.
> 
> testpmd> flow create 0 ingress group 1 pattern eth dst is AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan / queue index 1 / end
> Caught error type 10 (item specification): VLAN cannot be empty: Invalid argument
> testpmd> flow create 0 ingress group 1 pattern eth dst is AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions of_pop_vlan / queue index 1 / end
> Flow rule #0 created
> 
> 2) I would like to entag vlan tag
> 
> testpmd> flow create 0 egress group 1 pattern eth src is BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp vlan_pcp 3 / end
> Caught error type 16 (specific action): cause: 0x7ffdc9d98348, match on VLAN is required in order to set VLAN VID: Invalid argument
> 
> Thanks!
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> 
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Thursday, October 31, 2019 11:52
> > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > > VLAN header
> > > 
> > > Dear Slava,
> > > 
> > > Your guess is corrrect.
> > > When I put flow into Connect-X5, it was successful.
> > Very nice.
> > 
> > > 
> > > General question.
> > As we know - general questions are the most hard ones to answer ??.
> > 
> > > Are there any way to input flow to ConnectX-4?
> > As usual - with RTE flow API.  Just omit dv_flow_en, or specify dv_flow_en=0
> > and mlx5 PMD will handle RTE flow API via Verbs engine, supported by ConnectX-4. 
> > 
> > > In another word, are there any way to activate Verb?
> > > And which type of flow is supported in Verb?
> > Please, see flow_verbs_validate() routine in the mlx5_flow_verbs.c,
> > it shows which RTE flow items and actions are actually supported by Verbs.
> > 
> > With best regards, Slava
> > 
> > 
> > > 
> > > -----------------------------------------------------------
> > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --socket-
> > > mem 512,512 --huge-dir=/mnt/h
> > > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2 --txq=16 --rxq=16
> > > [sudo] password for tx_h-yamashita:
> > > EAL: Detected 48 lcore(s)
> > > EAL: Detected 2 NUMA nodes
> > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > EAL: Selected IOVA mode 'PA'
> > > EAL: Probing VFIO support...
> > > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > > EAL:   probe driver: 15b3:1017 net_mlx5
> > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on device
> > > mlx5_          1
> > > 
> > > Interactive-mode selected
> > > 
> > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > size=2176, socke          t=0
> > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > size=2176, socke          t=1
> > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > 
> > > Warning! port-topology=paired and odd forward ports number, the last port
> > > will p          air with itself.
> > > 
> > > Configuring Port 0 (socket 0)
> > > Port 0: B8:59:9F:C1:4A:CE
> > > Checking link statuses...
> > > Done
> > > testpmd>
> > > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst is
> > > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  / queue
> > > index 0 / end
> > > Flow rule #0 created
> > > testpmd>
> > > ---------------------------------------------------------------------------------------------
> > > -----------------
> > > 
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > > 
> > > > Hi, Hideyuki
> > > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Wednesday, October 30, 2019 12:46
> > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Hello Slava,
> > > > >
> > > > > Thanks for your help.
> > > > > I added magic phrase. with chaging PCI number with proper one in my
> > > env.
> > > >
> > > > > It changes situation but still result in error.
> > > > >
> > > > > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > > > > Your help is appreciated.
> > > > >
> > > > > I think it is getting closer.
> > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > > > gcc/app$
> > > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1 --socket-mem
> > > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > > --portmask=0x1 --nb-cores=2
> > > >
> > > > mlx5 PMD supports two flow engines:
> > > > - Verbs, this is legacy one, almost no new features are being added, just
> > > bug fixes,
> > > >   provides slow rule insertion rate, etc.
> > > > - Direct Rules, the new one, all new features are being added here.
> > > >
> > > > (We had one more intermediate engine  - Direct Verbs, it was dropped,
> > > > but prefix dv in dv_flow_en remains ??)
> > > >
> > > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX, ConnectX-5,
> > > ConnectX-6, etc.
> > > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > > "dv_flow_en=1" partameter engages Direct Rules, but I see you run
> > > > testpmd over 03:00.0 which is ConnectX-4, not  supporting Direct Rules.
> > > > Please, run over ConnectX-5 you have on your host.
> > > >
> > > > As for error - it is not related to memory, rdma core just failed to
> > > > create the group table, because ConnectX-4 does not support DR.
> > > >
> > > > With best regards, Slava
> > > >
> > > > > --txq=16 --rxq=16
> > > > > EAL: Detected 48 lcore(s)
> > > > > EAL: Detected 2 NUMA nodes
> > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > EAL: Selected IOVA mode 'PA'
> > > > > EAL: Probing VFIO support...
> > > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on
> > > > > device
> > > > > mlx5_3
> > > > >
> > > > > Interactive-mode selected
> > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > > > size=2176, socket=0
> > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > > > size=2176, socket=1
> > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > >
> > > > > Warning! port-topology=paired and odd forward ports number, the last
> > > > > port will pair with itself.
> > > > >
> > > > > Configuring Port 0 (socket 0)
> > > > > Port 0: B8:59:9F:DB:22:20
> > > > > Checking link statuses...
> > > > > Done
> > > > > testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is
> > > > > testpmd> 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions
> > > > > testpmd> of_pop_vlan / queue index 0 / end
> > > > > Caught error type 1 (cause unspecified): cannot create table: Cannot
> > > > > allocate memory
> > > > >
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > >
> > > 
> > 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Wednesday, November 6, 2019 13:04
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Dear Slava,
> 
> Additional question.
> When I use testpmd in dpdk-next-net repo, it works in general.
> However when I use dpdk19.11-rc1,  testpmd does not recognize connectX-5
> NIC.

It is quite strange, it should be, ConnectX-5 is base Mellanox NIC now.
Could you, please:
- configure "CONFIG_RTE_LIBRTE_MLX5_DEBUG=y" in ./config/common_base
- reconfigure DPDK and rebuild testpmd
- run testpmd with --log-level=99 --log-level=pmd.net.mlx5:8 (before -- separator)
- see (and provide) the log, where it drops the eth_dev object spawning

> 
> Is it correct that ConnectX-5 will be recognized in 19.11 release finally?

It should be recognized in 19.11rc1, possible we have some configuration issue,
let's have a look at.

> If yes, which release candidate the necessary change will be mergerd and
> available?
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > Dear Slava,
> >
> > Thanks for your response.
> >
> > Inputting other flows failed while some flows are created.
> > Please help on the following two cases.
> >
> > 1) I would like to detag vlan tag which has specific destionation MAC
> > address.  No condition about vlan id value.
> >
> > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > testpmd> AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan /
> > testpmd> queue index 1 / end
> > Caught error type 10 (item specification): VLAN cannot be empty:
> > Invalid argument
> > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > testpmd> AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions of_pop_vlan
> > testpmd> / queue index 1 / end
> > Flow rule #0 created

I'll check, possible this validation reject is imposed by HW limitations - it requires the VLAN header presence
and (IIRC) VID match. If possible - we'll fix.

> >
> > 2) I would like to entag vlan tag
> >
> > testpmd> flow create 0 egress group 1 pattern eth src is
> > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > testpmd> vlan_pcp 3 / end
> > Caught error type 16 (specific action): cause: 0x7ffdc9d98348, match
> > on VLAN is required in order to set VLAN VID: Invalid argument
> >

It is fixed (and patch Is already merged - http://patches.dpdk.org/patch/62295/),
let's try coming 19.11rc2. I inserted your Flow successfully on current Upstream..

With best regards, Slava



> > Thanks!
> >
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> >
> >
> >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Thursday, October 31, 2019 11:52
> > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Dear Slava,
> > > >
> > > > Your guess is corrrect.
> > > > When I put flow into Connect-X5, it was successful.
> > > Very nice.
> > >
> > > >
> > > > General question.
> > > As we know - general questions are the most hard ones to answer ??.
> > >
> > > > Are there any way to input flow to ConnectX-4?
> > > As usual - with RTE flow API.  Just omit dv_flow_en, or specify
> > > dv_flow_en=0 and mlx5 PMD will handle RTE flow API via Verbs engine,
> supported by ConnectX-4.
> > >
> > > > In another word, are there any way to activate Verb?
> > > > And which type of flow is supported in Verb?
> > > Please, see flow_verbs_validate() routine in the mlx5_flow_verbs.c,
> > > it shows which RTE flow items and actions are actually supported by
> Verbs.
> > >
> > > With best regards, Slava
> > >
> > >
> > > >
> > > > -----------------------------------------------------------
> > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --
> socket-
> > > > mem 512,512 --huge-dir=/mnt/h
> > > > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2
> > > > --txq=16 --rxq=16 [sudo] password for tx_h-yamashita:
> > > > EAL: Detected 48 lcore(s)
> > > > EAL: Detected 2 NUMA nodes
> > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > EAL: Selected IOVA mode 'PA'
> > > > EAL: Probing VFIO support...
> > > > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > > > EAL:   probe driver: 15b3:1017 net_mlx5
> > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on
> device
> > > > mlx5_          1
> > > >
> > > > Interactive-mode selected
> > > >
> > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > > size=2176, socke          t=0
> > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > > size=2176, socke          t=1
> > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > >
> > > > Warning! port-topology=paired and odd forward ports number, the last
> port
> > > > will p          air with itself.
> > > >
> > > > Configuring Port 0 (socket 0)
> > > > Port 0: B8:59:9F:C1:4A:CE
> > > > Checking link statuses...
> > > > Done
> > > > testpmd>
> > > > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst
> > > > testpmd> is
> > > > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  /
> queue
> > > > index 0 / end
> > > > Flow rule #0 created
> > > > testpmd>
> > > > ------------------------------------------------------------------
> > > > ---------------------------
> > > > -----------------
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > > > Hi, Hideyuki
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > Sent: Wednesday, October 30, 2019 12:46
> > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > Cc: dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > action on VLAN header
> > > > > >
> > > > > > Hello Slava,
> > > > > >
> > > > > > Thanks for your help.
> > > > > > I added magic phrase. with chaging PCI number with proper one
> > > > > > in my
> > > > env.
> > > > >
> > > > > > It changes situation but still result in error.
> > > > > >
> > > > > > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > > > > > Your help is appreciated.
> > > > > >
> > > > > > I think it is getting closer.
> > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> linuxapp-
> > > > > > gcc/app$
> > > > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1
> > > > > > --socket-mem
> > > > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > > > --portmask=0x1 --nb-cores=2
> > > > >
> > > > > mlx5 PMD supports two flow engines:
> > > > > - Verbs, this is legacy one, almost no new features are being
> > > > > added, just
> > > > bug fixes,
> > > > >   provides slow rule insertion rate, etc.
> > > > > - Direct Rules, the new one, all new features are being added here.
> > > > >
> > > > > (We had one more intermediate engine  - Direct Verbs, it was
> > > > > dropped, but prefix dv in dv_flow_en remains ??)
> > > > >
> > > > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX,
> > > > > ConnectX-5,
> > > > ConnectX-6, etc.
> > > > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > > > "dv_flow_en=1" partameter engages Direct Rules, but I see you
> > > > > run testpmd over 03:00.0 which is ConnectX-4, not  supporting Direct
> Rules.
> > > > > Please, run over ConnectX-5 you have on your host.
> > > > >
> > > > > As for error - it is not related to memory, rdma core just
> > > > > failed to create the group table, because ConnectX-4 does not
> support DR.
> > > > >
> > > > > With best regards, Slava
> > > > >
> > > > > > --txq=16 --rxq=16
> > > > > > EAL: Detected 48 lcore(s)
> > > > > > EAL: Detected 2 NUMA nodes
> > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > EAL: Probing VFIO support...
> > > > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port
> > > > > > 1 on device
> > > > > > mlx5_3
> > > > > >
> > > > > > Interactive-mode selected
> > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> > > > > > n=171456, size=2176, socket=0
> > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> > > > > > n=171456, size=2176, socket=1
> > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > >
> > > > > > Warning! port-topology=paired and odd forward ports number,
> > > > > > the last port will pair with itself.
> > > > > >
> > > > > > Configuring Port 0 (socket 0)
> > > > > > Port 0: B8:59:9F:DB:22:20
> > > > > > Checking link statuses...
> > > > > > Done
> > > > > > testpmd> flow create 0 ingress group 1 priority 0 pattern eth
> > > > > > testpmd> dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end
> > > > > > testpmd> actions of_pop_vlan / queue index 0 / end
> > > > > > Caught error type 1 (cause unspecified): cannot create table:
> > > > > > Cannot allocate memory
> > > > > >
> > > > > >
> > > > > > BR,
> > > > > > Hideyuki Yamashita
> > > > >
> > > >
> > >
> >
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hi Slava,

Thanks for your response.

1. As you pointed out, it was configuration issue (CONFIG_RTE_LIBRTE_MLX5_DEBUG=y)!
When I turned out the configuration, 19.11 rc1 recognized Connect-X5
corrcetly.

Thanks for your help.

2. How about the question I put in my previouse email
(how to create flow for entag VLAN tag on not-tagged packet)

Thanks again.


BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki
> 
> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Wednesday, November 6, 2019 13:04
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Dear Slava,
> > 
> > Additional question.
> > When I use testpmd in dpdk-next-net repo, it works in general.
> > However when I use dpdk19.11-rc1,  testpmd does not recognize connectX-5
> > NIC.
> 
> It is quite strange, it should be, ConnectX-5 is base Mellanox NIC now.
> Could you, please:
> - configure "CONFIG_RTE_LIBRTE_MLX5_DEBUG=y" in ./config/common_base
> - reconfigure DPDK and rebuild testpmd
> - run testpmd with --log-level=99 --log-level=pmd.net.mlx5:8 (before -- separator)
> - see (and provide) the log, where it drops the eth_dev object spawning
> 
> > 
> > Is it correct that ConnectX-5 will be recognized in 19.11 release finally?
> 
> It should be recognized in 19.11rc1, possible we have some configuration issue,
> let's have a look at.
> 
> > If yes, which release candidate the necessary change will be mergerd and
> > available?
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > 
> > > Dear Slava,
> > >
> > > Thanks for your response.
> > >
> > > Inputting other flows failed while some flows are created.
> > > Please help on the following two cases.
> > >
> > > 1) I would like to detag vlan tag which has specific destionation MAC
> > > address.  No condition about vlan id value.
> > >
> > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > testpmd> AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan /
> > > testpmd> queue index 1 / end
> > > Caught error type 10 (item specification): VLAN cannot be empty:
> > > Invalid argument
> > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > testpmd> AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions of_pop_vlan
> > > testpmd> / queue index 1 / end
> > > Flow rule #0 created
> 
> I'll check, possible this validation reject is imposed by HW limitations - it requires the VLAN header presence
> and (IIRC) VID match. If possible - we'll fix.
> 
> > >
> > > 2) I would like to entag vlan tag
> > >
> > > testpmd> flow create 0 egress group 1 pattern eth src is
> > > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > > testpmd> vlan_pcp 3 / end
> > > Caught error type 16 (specific action): cause: 0x7ffdc9d98348, match
> > > on VLAN is required in order to set VLAN VID: Invalid argument
> > >
> 
> It is fixed (and patch Is already merged - http://patches.dpdk.org/patch/62295/),
> let's try coming 19.11rc2. I inserted your Flow successfully on current Upstream..
> 
> With best regards, Slava
> 
> 
> 
> > > Thanks!
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Thursday, October 31, 2019 11:52
> > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Dear Slava,
> > > > >
> > > > > Your guess is corrrect.
> > > > > When I put flow into Connect-X5, it was successful.
> > > > Very nice.
> > > >
> > > > >
> > > > > General question.
> > > > As we know - general questions are the most hard ones to answer ??.
> > > >
> > > > > Are there any way to input flow to ConnectX-4?
> > > > As usual - with RTE flow API.  Just omit dv_flow_en, or specify
> > > > dv_flow_en=0 and mlx5 PMD will handle RTE flow API via Verbs engine,
> > supported by ConnectX-4.
> > > >
> > > > > In another word, are there any way to activate Verb?
> > > > > And which type of flow is supported in Verb?
> > > > Please, see flow_verbs_validate() routine in the mlx5_flow_verbs.c,
> > > > it shows which RTE flow items and actions are actually supported by
> > Verbs.
> > > >
> > > > With best regards, Slava
> > > >
> > > >
> > > > >
> > > > > -----------------------------------------------------------
> > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-linuxapp-
> > > > > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1 --
> > socket-
> > > > > mem 512,512 --huge-dir=/mnt/h
> > > > > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2
> > > > > --txq=16 --rxq=16 [sudo] password for tx_h-yamashita:
> > > > > EAL: Detected 48 lcore(s)
> > > > > EAL: Detected 2 NUMA nodes
> > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > EAL: Selected IOVA mode 'PA'
> > > > > EAL: Probing VFIO support...
> > > > > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > > > > EAL:   probe driver: 15b3:1017 net_mlx5
> > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port 1 on
> > device
> > > > > mlx5_          1
> > > > >
> > > > > Interactive-mode selected
> > > > >
> > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=171456,
> > > > > size=2176, socke          t=0
> > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>: n=171456,
> > > > > size=2176, socke          t=1
> > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > >
> > > > > Warning! port-topology=paired and odd forward ports number, the last
> > port
> > > > > will p          air with itself.
> > > > >
> > > > > Configuring Port 0 (socket 0)
> > > > > Port 0: B8:59:9F:C1:4A:CE
> > > > > Checking link statuses...
> > > > > Done
> > > > > testpmd>
> > > > > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth dst
> > > > > testpmd> is
> > > > > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan  /
> > queue
> > > > > index 0 / end
> > > > > Flow rule #0 created
> > > > > testpmd>
> > > > > ------------------------------------------------------------------
> > > > > ---------------------------
> > > > > -----------------
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > > > Hi, Hideyuki
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > Sent: Wednesday, October 30, 2019 12:46
> > > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > > Cc: dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > > action on VLAN header
> > > > > > >
> > > > > > > Hello Slava,
> > > > > > >
> > > > > > > Thanks for your help.
> > > > > > > I added magic phrase. with chaging PCI number with proper one
> > > > > > > in my
> > > > > env.
> > > > > >
> > > > > > > It changes situation but still result in error.
> > > > > > >
> > > > > > > I used /usertools/dpdk-setup.sh to allocate hugepage dynamically.
> > > > > > > Your help is appreciated.
> > > > > > >
> > > > > > > I think it is getting closer.
> > > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> > linuxapp-
> > > > > > > gcc/app$
> > > > > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1
> > > > > > > --socket-mem
> > > > > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > > > > --portmask=0x1 --nb-cores=2
> > > > > >
> > > > > > mlx5 PMD supports two flow engines:
> > > > > > - Verbs, this is legacy one, almost no new features are being
> > > > > > added, just
> > > > > bug fixes,
> > > > > >   provides slow rule insertion rate, etc.
> > > > > > - Direct Rules, the new one, all new features are being added here.
> > > > > >
> > > > > > (We had one more intermediate engine  - Direct Verbs, it was
> > > > > > dropped, but prefix dv in dv_flow_en remains ??)
> > > > > >
> > > > > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX,
> > > > > > ConnectX-5,
> > > > > ConnectX-6, etc.
> > > > > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > > > > "dv_flow_en=1" partameter engages Direct Rules, but I see you
> > > > > > run testpmd over 03:00.0 which is ConnectX-4, not  supporting Direct
> > Rules.
> > > > > > Please, run over ConnectX-5 you have on your host.
> > > > > >
> > > > > > As for error - it is not related to memory, rdma core just
> > > > > > failed to create the group table, because ConnectX-4 does not
> > support DR.
> > > > > >
> > > > > > With best regards, Slava
> > > > > >
> > > > > > > --txq=16 --rxq=16
> > > > > > > EAL: Detected 48 lcore(s)
> > > > > > > EAL: Detected 2 NUMA nodes
> > > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > > EAL: Probing VFIO support...
> > > > > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port
> > > > > > > 1 on device
> > > > > > > mlx5_3
> > > > > > >
> > > > > > > Interactive-mode selected
> > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> > > > > > > n=171456, size=2176, socket=0
> > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> > > > > > > n=171456, size=2176, socket=1
> > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > >
> > > > > > > Warning! port-topology=paired and odd forward ports number,
> > > > > > > the last port will pair with itself.
> > > > > > >
> > > > > > > Configuring Port 0 (socket 0)
> > > > > > > Port 0: B8:59:9F:DB:22:20
> > > > > > > Checking link statuses...
> > > > > > > Done
> > > > > > > testpmd> flow create 0 ingress group 1 priority 0 pattern eth
> > > > > > > testpmd> dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end
> > > > > > > testpmd> actions of_pop_vlan / queue index 0 / end
> > > > > > > Caught error type 1 (cause unspecified): cannot create table:
> > > > > > > Cannot allocate memory
> > > > > > >
> > > > > > >
> > > > > > > BR,
> > > > > > > Hideyuki Yamashita
> > > > > >
> > > > >
> > > >
> > >
> > 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Thursday, November 7, 2019 6:46
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Hi Slava,
> 
> Thanks for your response.
> 
> 1. As you pointed out, it was configuration issue
> (CONFIG_RTE_LIBRTE_MLX5_DEBUG=y)!
> When I turned out the configuration, 19.11 rc1 recognized Connect-X5
> corrcetly.
No-no, it is not configuration, this just enables debug features and Is helpful to locate
the reason why ConnectX-5 was not detected on your setup. In release product, of coarse,
the CONFIG_RTE_LIBRTE_MLX5_DEBUG must be "n"
Or was it just missed "CONFIG_RTE_LIBRTE_MLX5_PMD=y" ?

> 
> Thanks for your help.
> 
> 2. How about the question I put in my previouse email (how to create flow
> for entag VLAN tag on not-tagged packet)

I'm sorry, I did not express my answer in clear way.
This issue is fixed, now you entagging Flow can be created successfully, I rechecked.

Now it works:

> > > > testpmd> flow create 0 egress group 1 pattern eth src is
> > > > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > > > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > > > testpmd> vlan_pcp 3 / end

Please, take (coming on Friday) 19.11rc2 and try.

With best regards, Slava

> 
> Thanks again.
> 
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Wednesday, November 6, 2019 13:04
> > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Dear Slava,
> > >
> > > Additional question.
> > > When I use testpmd in dpdk-next-net repo, it works in general.
> > > However when I use dpdk19.11-rc1,  testpmd does not recognize
> > > connectX-5 NIC.
> >
> > It is quite strange, it should be, ConnectX-5 is base Mellanox NIC now.
> > Could you, please:
> > - configure "CONFIG_RTE_LIBRTE_MLX5_DEBUG=y" in
> ./config/common_base
> > - reconfigure DPDK and rebuild testpmd
> > - run testpmd with --log-level=99 --log-level=pmd.net.mlx5:8 (before
> > -- separator)
> > - see (and provide) the log, where it drops the eth_dev object
> > spawning
> >
> > >
> > > Is it correct that ConnectX-5 will be recognized in 19.11 release finally?
> >
> > It should be recognized in 19.11rc1, possible we have some
> > configuration issue, let's have a look at.
> >
> > > If yes, which release candidate the necessary change will be mergerd
> > > and available?
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > >
> > > > Dear Slava,
> > > >
> > > > Thanks for your response.
> > > >
> > > > Inputting other flows failed while some flows are created.
> > > > Please help on the following two cases.
> > > >
> > > > 1) I would like to detag vlan tag which has specific destionation
> > > > MAC address.  No condition about vlan id value.
> > > >
> > > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > > testpmd> AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan
> > > > testpmd> / queue index 1 / end
> > > > Caught error type 10 (item specification): VLAN cannot be empty:
> > > > Invalid argument
> > > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > > testpmd> AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions
> > > > testpmd> of_pop_vlan / queue index 1 / end
> > > > Flow rule #0 created
> >
> > I'll check, possible this validation reject is imposed by HW
> > limitations - it requires the VLAN header presence and (IIRC) VID match. If
> possible - we'll fix.
> >
> > > >
> > > > 2) I would like to entag vlan tag
> > > >
> > > > testpmd> flow create 0 egress group 1 pattern eth src is
> > > > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > > > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > > > testpmd> vlan_pcp 3 / end
> > > > Caught error type 16 (specific action): cause: 0x7ffdc9d98348,
> > > > match on VLAN is required in order to set VLAN VID: Invalid
> > > > argument
> > > >
> >
> > It is fixed (and patch Is already merged -
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> >
> es.dpdk.org%2Fpatch%2F62295%2F&amp;data=02%7C01%7Cviacheslavo%4
> 0mellan
> >
> ox.com%7Ca17dfb64b04f430237ff08d7633d7346%7Ca652971c7d2e4d9ba6
> a4d14925
> >
> 6f461b%7C0%7C1%7C637086987908448715&amp;sdata=Uvi1bWYT%2BaHo
> TSHkQ8AF6%
> > 2FnTx%2FP5UrMqtZ3gAzjqGAA%3D&amp;reserved=0),
> > let's try coming 19.11rc2. I inserted your Flow successfully on current
> Upstream..
> >
> > With best regards, Slava
> >
> >
> >
> > > > Thanks!
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > >
> > > >
> > > > > > -----Original Message-----
> > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > Sent: Thursday, October 31, 2019 11:52
> > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > Cc: dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > action on VLAN header
> > > > > >
> > > > > > Dear Slava,
> > > > > >
> > > > > > Your guess is corrrect.
> > > > > > When I put flow into Connect-X5, it was successful.
> > > > > Very nice.
> > > > >
> > > > > >
> > > > > > General question.
> > > > > As we know - general questions are the most hard ones to answer ??.
> > > > >
> > > > > > Are there any way to input flow to ConnectX-4?
> > > > > As usual - with RTE flow API.  Just omit dv_flow_en, or specify
> > > > > dv_flow_en=0 and mlx5 PMD will handle RTE flow API via Verbs
> > > > > engine,
> > > supported by ConnectX-4.
> > > > >
> > > > > > In another word, are there any way to activate Verb?
> > > > > > And which type of flow is supported in Verb?
> > > > > Please, see flow_verbs_validate() routine in the
> > > > > mlx5_flow_verbs.c, it shows which RTE flow items and actions are
> > > > > actually supported by
> > > Verbs.
> > > > >
> > > > > With best regards, Slava
> > > > >
> > > > >
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> linuxapp-
> > > > > > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1
> --
> > > socket-
> > > > > > mem 512,512 --huge-dir=/mnt/h
> > > > > > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2
> > > > > > --txq=16 --rxq=16 [sudo] password for tx_h-yamashita:
> > > > > > EAL: Detected 48 lcore(s)
> > > > > > EAL: Detected 2 NUMA nodes
> > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > EAL: Probing VFIO support...
> > > > > > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > > > > > EAL:   probe driver: 15b3:1017 net_mlx5
> > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port
> > > > > > 1 on
> > > device
> > > > > > mlx5_          1
> > > > > >
> > > > > > Interactive-mode selected
> > > > > >
> > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> n=171456,
> > > > > > size=2176, socke          t=0
> > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> n=171456,
> > > > > > size=2176, socke          t=1
> > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > >
> > > > > > Warning! port-topology=paired and odd forward ports number,
> > > > > > the last
> > > port
> > > > > > will p          air with itself.
> > > > > >
> > > > > > Configuring Port 0 (socket 0)
> > > > > > Port 0: B8:59:9F:C1:4A:CE
> > > > > > Checking link statuses...
> > > > > > Done
> > > > > > testpmd>
> > > > > > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth
> > > > > > testpmd> dst is
> > > > > > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan
> /
> > > queue
> > > > > > index 0 / end
> > > > > > Flow rule #0 created
> > > > > > testpmd>
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ---------------------------
> > > > > > -----------------
> > > > > >
> > > > > > BR,
> > > > > > Hideyuki Yamashita
> > > > > > NTT TechnoCross
> > > > > >
> > > > > > > Hi, Hideyuki
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > > Sent: Wednesday, October 30, 2019 12:46
> > > > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > > > Cc: dev@dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for
> > > > > > > > flow action on VLAN header
> > > > > > > >
> > > > > > > > Hello Slava,
> > > > > > > >
> > > > > > > > Thanks for your help.
> > > > > > > > I added magic phrase. with chaging PCI number with proper
> > > > > > > > one in my
> > > > > > env.
> > > > > > >
> > > > > > > > It changes situation but still result in error.
> > > > > > > >
> > > > > > > > I used /usertools/dpdk-setup.sh to allocate hugepage
> dynamically.
> > > > > > > > Your help is appreciated.
> > > > > > > >
> > > > > > > > I think it is getting closer.
> > > > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> > > linuxapp-
> > > > > > > > gcc/app$
> > > > > > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1
> > > > > > > > --socket-mem
> > > > > > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > > > > > --portmask=0x1 --nb-cores=2
> > > > > > >
> > > > > > > mlx5 PMD supports two flow engines:
> > > > > > > - Verbs, this is legacy one, almost no new features are
> > > > > > > being added, just
> > > > > > bug fixes,
> > > > > > >   provides slow rule insertion rate, etc.
> > > > > > > - Direct Rules, the new one, all new features are being added
> here.
> > > > > > >
> > > > > > > (We had one more intermediate engine  - Direct Verbs, it was
> > > > > > > dropped, but prefix dv in dv_flow_en remains ??)
> > > > > > >
> > > > > > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX,
> > > > > > > ConnectX-5,
> > > > > > ConnectX-6, etc.
> > > > > > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > > > > > "dv_flow_en=1" partameter engages Direct Rules, but I see
> > > > > > > you run testpmd over 03:00.0 which is ConnectX-4, not
> > > > > > > supporting Direct
> > > Rules.
> > > > > > > Please, run over ConnectX-5 you have on your host.
> > > > > > >
> > > > > > > As for error - it is not related to memory, rdma core just
> > > > > > > failed to create the group table, because ConnectX-4 does
> > > > > > > not
> > > support DR.
> > > > > > >
> > > > > > > With best regards, Slava
> > > > > > >
> > > > > > > > --txq=16 --rxq=16
> > > > > > > > EAL: Detected 48 lcore(s)
> > > > > > > > EAL: Detected 2 NUMA nodes
> > > > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > > > EAL: Probing VFIO support...
> > > > > > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > > > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx
> > > > > > > > port
> > > > > > > > 1 on device
> > > > > > > > mlx5_3
> > > > > > > >
> > > > > > > > Interactive-mode selected
> > > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> > > > > > > > n=171456, size=2176, socket=0
> > > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> > > > > > > > n=171456, size=2176, socket=1
> > > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > >
> > > > > > > > Warning! port-topology=paired and odd forward ports
> > > > > > > > number, the last port will pair with itself.
> > > > > > > >
> > > > > > > > Configuring Port 0 (socket 0) Port 0: B8:59:9F:DB:22:20
> > > > > > > > Checking link statuses...
> > > > > > > > Done
> > > > > > > > testpmd> flow create 0 ingress group 1 priority 0 pattern
> > > > > > > > testpmd> eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 /
> > > > > > > > testpmd> end actions of_pop_vlan / queue index 0 / end
> > > > > > > > Caught error type 1 (cause unspecified): cannot create table:
> > > > > > > > Cannot allocate memory
> > > > > > > >
> > > > > > > >
> > > > > > > > BR,
> > > > > > > > Hideyuki Yamashita
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Slava,

About 1, when I turned on "CONFIG_RTE_LIBRTE_MLX5_PMD=y" it worked.
About 2, I used the latest dpdk-next-net, creating flow for entag VLAN
was successful as following:

Configuring Port 0 (socket 0)
Port 0: B8:59:9F:C1:4A:CE
Configuring Port 1 (socket 0)
Port 1: B8:59:9F:C1:4A:CF
Checking link statuses...
Done
testpmd> flow create 0 egress group 1 pattern eth src is BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp vlan_pcp 3 / end
Flow rule #0 created
testpmd> flow create 0 egress group 0 pattern eth
 dst [TOKEN]: destination MAC
 src [TOKEN]: source MAC
 type [TOKEN]: EtherType
 / [TOKEN]: specify next pattern item
testpmd> flow create 0 egress group 0 pattern eth / a
 any [TOKEN]: match any protocol for the current layer
 arp_eth_ipv4 [TOKEN]: match ARP header for Ethernet/IPv4
testpmd> flow create 0 egress group 0 pattern eth / end actions jump group 1
Bad arguments
testpmd> flow create 0 egress group 0 pattern eth / end actions jump group 1 / end
Flow rule #1 created

In short, my questions resolved!
Thanks!

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki

> > 1. As you pointed out, it was configuration issue
> > (CONFIG_RTE_LIBRTE_MLX5_DEBUG=y)!
> > When I turned out the configuration, 19.11 rc1 recognized Connect-X5
> > corrcetly.
> No-no, it is not configuration, this just enables debug features and Is helpful to locate
> the reason why ConnectX-5 was not detected on your setup. In release product, of coarse,
> the CONFIG_RTE_LIBRTE_MLX5_DEBUG must be "n"
> Or was it just missed "CONFIG_RTE_LIBRTE_MLX5_PMD=y" ?
> 
> > 
> > Thanks for your help.
> > 
> > 2. How about the question I put in my previouse email (how to create flow
> > for entag VLAN tag on not-tagged packet)
> 
> I'm sorry, I did not express my answer in clear way.
> This issue is fixed, now you entagging Flow can be created successfully, I rechecked.
> 
> Now it works:
> 
> > > > > testpmd> flow create 0 egress group 1 pattern eth src is
> > > > > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > > > > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > > > > testpmd> vlan_pcp 3 / end
> 
> Please, take (coming on Friday) 19.11rc2 and try.
> 
> With best regards, Slava



> > 
> > Thanks again.
> > 
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > > Hi, Hideyuki
> > >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Wednesday, November 6, 2019 13:04
> > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Dear Slava,
> > > >
> > > > Additional question.
> > > > When I use testpmd in dpdk-next-net repo, it works in general.
> > > > However when I use dpdk19.11-rc1,  testpmd does not recognize
> > > > connectX-5 NIC.
> > >
> > > It is quite strange, it should be, ConnectX-5 is base Mellanox NIC now.
> > > Could you, please:
> > > - configure "CONFIG_RTE_LIBRTE_MLX5_DEBUG=y" in
> > ./config/common_base
> > > - reconfigure DPDK and rebuild testpmd
> > > - run testpmd with --log-level=99 --log-level=pmd.net.mlx5:8 (before
> > > -- separator)
> > > - see (and provide) the log, where it drops the eth_dev object
> > > spawning
> > >
> > > >
> > > > Is it correct that ConnectX-5 will be recognized in 19.11 release finally?
> > >
> > > It should be recognized in 19.11rc1, possible we have some
> > > configuration issue, let's have a look at.
> > >
> > > > If yes, which release candidate the necessary change will be mergerd
> > > > and available?
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > >
> > > > > Dear Slava,
> > > > >
> > > > > Thanks for your response.
> > > > >
> > > > > Inputting other flows failed while some flows are created.
> > > > > Please help on the following two cases.
> > > > >
> > > > > 1) I would like to detag vlan tag which has specific destionation
> > > > > MAC address.  No condition about vlan id value.
> > > > >
> > > > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > > > testpmd> AA:AA:AA:AA:AA:AA / vlan / any / end actions of_pop_vlan
> > > > > testpmd> / queue index 1 / end
> > > > > Caught error type 10 (item specification): VLAN cannot be empty:
> > > > > Invalid argument
> > > > > testpmd> flow create 0 ingress group 1 pattern eth dst is
> > > > > testpmd> AA:AA:AA:AA:AA:AA / vlan vid is 100 / end actions
> > > > > testpmd> of_pop_vlan / queue index 1 / end
> > > > > Flow rule #0 created
> > >
> > > I'll check, possible this validation reject is imposed by HW
> > > limitations - it requires the VLAN header presence and (IIRC) VID match. If
> > possible - we'll fix.
> > >
> > > > >
> > > > > 2) I would like to entag vlan tag
> > > > >
> > > > > testpmd> flow create 0 egress group 1 pattern eth src is
> > > > > testpmd> BB:BB:BB:BB:BB:BB  / end actions of_push_vlan ethertype
> > > > > testpmd> 0x8100 / of_set_vlan_vid vlan_vid 100 / of_set_vlan_pcp
> > > > > testpmd> vlan_pcp 3 / end
> > > > > Caught error type 16 (specific action): cause: 0x7ffdc9d98348,
> > > > > match on VLAN is required in order to set VLAN VID: Invalid
> > > > > argument
> > > > >
> > >
> > > It is fixed (and patch Is already merged -
> > >
> > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> > >
> > es.dpdk.org%2Fpatch%2F62295%2F&amp;data=02%7C01%7Cviacheslavo%4
> > 0mellan
> > >
> > ox.com%7Ca17dfb64b04f430237ff08d7633d7346%7Ca652971c7d2e4d9ba6
> > a4d14925
> > >
> > 6f461b%7C0%7C1%7C637086987908448715&amp;sdata=Uvi1bWYT%2BaHo
> > TSHkQ8AF6%
> > > 2FnTx%2FP5UrMqtZ3gAzjqGAA%3D&amp;reserved=0),
> > > let's try coming 19.11rc2. I inserted your Flow successfully on current
> > Upstream..
> > >
> > > With best regards, Slava
> > >
> > >
> > >
> > > > > Thanks!
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > >
> > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > Sent: Thursday, October 31, 2019 11:52
> > > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > > Cc: dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > > > action on VLAN header
> > > > > > >
> > > > > > > Dear Slava,
> > > > > > >
> > > > > > > Your guess is corrrect.
> > > > > > > When I put flow into Connect-X5, it was successful.
> > > > > > Very nice.
> > > > > >
> > > > > > >
> > > > > > > General question.
> > > > > > As we know - general questions are the most hard ones to answer ??.
> > > > > >
> > > > > > > Are there any way to input flow to ConnectX-4?
> > > > > > As usual - with RTE flow API.  Just omit dv_flow_en, or specify
> > > > > > dv_flow_en=0 and mlx5 PMD will handle RTE flow API via Verbs
> > > > > > engine,
> > > > supported by ConnectX-4.
> > > > > >
> > > > > > > In another word, are there any way to activate Verb?
> > > > > > > And which type of flow is supported in Verb?
> > > > > > Please, see flow_verbs_validate() routine in the
> > > > > > mlx5_flow_verbs.c, it shows which RTE flow items and actions are
> > > > > > actually supported by
> > > > Verbs.
> > > > > >
> > > > > > With best regards, Slava
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> > linuxapp-
> > > > > > > gcc/app$ sudo ./te          stpmd -c 0xF -n 4 -w 04:00.0,dv_flow_en=1
> > --
> > > > socket-
> > > > > > > mem 512,512 --huge-dir=/mnt/h
> > > > > > > uge1G --log-level port:8 -- -i --portmask=0x1 --nb-cores=2
> > > > > > > --txq=16 --rxq=16 [sudo] password for tx_h-yamashita:
> > > > > > > EAL: Detected 48 lcore(s)
> > > > > > > EAL: Detected 2 NUMA nodes
> > > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > > EAL: Probing VFIO support...
> > > > > > > EAL: PCI device 0000:04:00.0 on NUMA socket 0
> > > > > > > EAL:   probe driver: 15b3:1017 net_mlx5
> > > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx port
> > > > > > > 1 on
> > > > device
> > > > > > > mlx5_          1
> > > > > > >
> > > > > > > Interactive-mode selected
> > > > > > >
> > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> > n=171456,
> > > > > > > size=2176, socke          t=0
> > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> > n=171456,
> > > > > > > size=2176, socke          t=1
> > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > >
> > > > > > > Warning! port-topology=paired and odd forward ports number,
> > > > > > > the last
> > > > port
> > > > > > > will p          air with itself.
> > > > > > >
> > > > > > > Configuring Port 0 (socket 0)
> > > > > > > Port 0: B8:59:9F:C1:4A:CE
> > > > > > > Checking link statuses...
> > > > > > > Done
> > > > > > > testpmd>
> > > > > > > testpmd>  flow create 0 ingress group 1 priority 0 pattern eth
> > > > > > > testpmd> dst is
> > > > > > > 00:16:3e:2          e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan
> > /
> > > > queue
> > > > > > > index 0 / end
> > > > > > > Flow rule #0 created
> > > > > > > testpmd>
> > > > > > > --------------------------------------------------------------
> > > > > > > ----
> > > > > > > ---------------------------
> > > > > > > -----------------
> > > > > > >
> > > > > > > BR,
> > > > > > > Hideyuki Yamashita
> > > > > > > NTT TechnoCross
> > > > > > >
> > > > > > > > Hi, Hideyuki
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > > > > > Sent: Wednesday, October 30, 2019 12:46
> > > > > > > > > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > > > > > Cc: dev@dpdk.org
> > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for
> > > > > > > > > flow action on VLAN header
> > > > > > > > >
> > > > > > > > > Hello Slava,
> > > > > > > > >
> > > > > > > > > Thanks for your help.
> > > > > > > > > I added magic phrase. with chaging PCI number with proper
> > > > > > > > > one in my
> > > > > > > env.
> > > > > > > >
> > > > > > > > > It changes situation but still result in error.
> > > > > > > > >
> > > > > > > > > I used /usertools/dpdk-setup.sh to allocate hugepage
> > dynamically.
> > > > > > > > > Your help is appreciated.
> > > > > > > > >
> > > > > > > > > I think it is getting closer.
> > > > > > > > > tx_h-yamashita@R730n10:~/dpdk-next-net/x86_64-native-
> > > > linuxapp-
> > > > > > > > > gcc/app$
> > > > > > > > > sudo ./testpmd -c 0xF -n 4 -w 03:00.0,dv_flow_en=1
> > > > > > > > > --socket-mem
> > > > > > > > > 512,512 - -huge-dir=/mnt/h uge1G --log-level port:8 -- -i
> > > > > > > > > --portmask=0x1 --nb-cores=2
> > > > > > > >
> > > > > > > > mlx5 PMD supports two flow engines:
> > > > > > > > - Verbs, this is legacy one, almost no new features are
> > > > > > > > being added, just
> > > > > > > bug fixes,
> > > > > > > >   provides slow rule insertion rate, etc.
> > > > > > > > - Direct Rules, the new one, all new features are being added
> > here.
> > > > > > > >
> > > > > > > > (We had one more intermediate engine  - Direct Verbs, it was
> > > > > > > > dropped, but prefix dv in dv_flow_en remains ??)
> > > > > > > >
> > > > > > > > Verbs are supported over all NICs - ConnectX-4,ConnectX-4LX,
> > > > > > > > ConnectX-5,
> > > > > > > ConnectX-6, etc.
> > > > > > > > Direct Rules is supported for NICs starting from ConnectX-5.
> > > > > > > > "dv_flow_en=1" partameter engages Direct Rules, but I see
> > > > > > > > you run testpmd over 03:00.0 which is ConnectX-4, not
> > > > > > > > supporting Direct
> > > > Rules.
> > > > > > > > Please, run over ConnectX-5 you have on your host.
> > > > > > > >
> > > > > > > > As for error - it is not related to memory, rdma core just
> > > > > > > > failed to create the group table, because ConnectX-4 does
> > > > > > > > not
> > > > support DR.
> > > > > > > >
> > > > > > > > With best regards, Slava
> > > > > > > >
> > > > > > > > > --txq=16 --rxq=16
> > > > > > > > > EAL: Detected 48 lcore(s)
> > > > > > > > > EAL: Detected 2 NUMA nodes
> > > > > > > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > > > > > > > > EAL: Selected IOVA mode 'PA'
> > > > > > > > > EAL: Probing VFIO support...
> > > > > > > > > EAL: PCI device 0000:03:00.0 on NUMA socket 0
> > > > > > > > > EAL:   probe driver: 15b3:1015 net_mlx5
> > > > > > > > > net_mlx5: mlx5.c:1852: mlx5_dev_spawn(): can't query devx
> > > > > > > > > port
> > > > > > > > > 1 on device
> > > > > > > > > mlx5_3
> > > > > > > > >
> > > > > > > > > Interactive-mode selected
> > > > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>:
> > > > > > > > > n=171456, size=2176, socket=0
> > > > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > > > testpmd: create a new mbuf pool <mbuf_pool_socket_1>:
> > > > > > > > > n=171456, size=2176, socket=1
> > > > > > > > > testpmd: preferred mempool ops selected: ring_mp_mc
> > > > > > > > >
> > > > > > > > > Warning! port-topology=paired and odd forward ports
> > > > > > > > > number, the last port will pair with itself.
> > > > > > > > >
> > > > > > > > > Configuring Port 0 (socket 0) Port 0: B8:59:9F:DB:22:20
> > > > > > > > > Checking link statuses...
> > > > > > > > > Done
> > > > > > > > > testpmd> flow create 0 ingress group 1 priority 0 pattern
> > > > > > > > > testpmd> eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 /
> > > > > > > > > testpmd> end actions of_pop_vlan / queue index 0 / end
> > > > > > > > > Caught error type 1 (cause unspecified): cannot create table:
> > > > > > > > > Cannot allocate memory
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > BR,
> > > > > > > > > Hideyuki Yamashita
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Slava,

As I reported to you, creating flow was successful with Connect-X5.
However when I sent packets to the NIC from outer side of
the host, I have problem.


[Case 1]
Packet distribution on multi-queue based on dst MAC address.

NIC config:
04:00.0 Mellanox Connect-X5
0.5.00.0 Intel XXV710

testpmd startup param:
sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-filter-mode=perfect

flow command:
testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 / end actions queue index 1 / end
Flow rule #0 created
testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / end actions queue index 1 / end
Flow rule #0 created

Packet reception:(no VLAN tag)
port 0/queue 0: received 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
  ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
port 1/queue 0: sent 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
  ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN

port 1/queue 1: received 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
  ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
port 0/queue 1: sent 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
  ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN

Result:
Matched packet queued to queue=0 port=0. Not queue=1, port=0.

Expectation:
When receiving packet which has dst MAC 11:22:33:44:55:66 should be
received on queue=1 port=0.

Question:
Why matching packet is NOT enqueued into queue=1 on port=0?


[Case 2]
Packet distribution on multi-queue based on VLAN tag

testpmd startup param:
sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-filter-mode=perfect

flow command:
flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end actions queue index 1 / of_pop_vlan / end
flow create 0 ingress group 0 pattern eth / end actions jump group 1 / end

Packet Reception: (VLAN100)
port 0/queue 1: received 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
  ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
port 1/queue 1: sent 1 packets
  src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
  ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN

Result:
Matched packetd queued to queue=1, port=0
Other packet(VLAN101 packet) discarded.

Expectation:
Matched packet queued to queue =1, port=0
Non Matched packet queued to queue=0, port=0

Question:
Is above behavior collect?
What is the default behavior of unmatchedd packets (queue to queue=0 or
discard packet)

BR,
Hideyuki Yamashita
NTT TechnoCross



　

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Slava,

Note that I am using the following dpdk rc.
DPDK 19.11 rc-1

BR,
HIdeyuki Yamashita
NTT TechnoCross

> Hello Slava,
> 
> As I reported to you, creating flow was successful with Connect-X5.
> However when I sent packets to the NIC from outer side of
> the host, I have problem.
> 
> 
> [Case 1]
> Packet distribution on multi-queue based on dst MAC address.
> 
> NIC config:
> 04:00.0 Mellanox Connect-X5
> 0.5.00.0 Intel XXV710
> 
> testpmd startup param:
> sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-filter-mode=perfect
> 
> flow command:
> testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 / end actions queue index 1 / end
> Flow rule #0 created
> testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / end actions queue index 1 / end
> Flow rule #0 created
> 
> Packet reception:(no VLAN tag)
> port 0/queue 0: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> port 1/queue 0: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> port 1/queue 1: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> port 0/queue 1: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> Result:
> Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> 
> Expectation:
> When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> received on queue=1 port=0.
> 
> Question:
> Why matching packet is NOT enqueued into queue=1 on port=0?
> 
> 
> [Case 2]
> Packet distribution on multi-queue based on VLAN tag
> 
> testpmd startup param:
> sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-filter-mode=perfect
> 
> flow command:
> flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end actions queue index 1 / of_pop_vlan / end
> flow create 0 ingress group 0 pattern eth / end actions jump group 1 / end
> 
> Packet Reception: (VLAN100)
> port 0/queue 1: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> port 1/queue 1: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  - sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> Result:
> Matched packetd queued to queue=1, port=0
> Other packet(VLAN101 packet) discarded.
> 
> Expectation:
> Matched packet queued to queue =1, port=0
> Non Matched packet queued to queue=0, port=0
> 
> Question:
> Is above behavior collect?
> What is the default behavior of unmatchedd packets (queue to queue=0 or
> discard packet)
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> 
> 　
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Slava Ovsiienko]

Hi, Hideyuki

The frame in your report is broadcast/multicast. Please, try unicast one.
For broadcast we have the ticket, currently issue is under investigation.
Anyway, thanks for reporting.

With best regards, Slava

> -----Original Message-----
> From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Sent: Thursday, November 14, 2019 7:02
> To: dev@dpdk.org
> Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> VLAN header
> 
> Hello Slava,
> 
> As I reported to you, creating flow was successful with Connect-X5.
> However when I sent packets to the NIC from outer side of the host, I have
> problem.
> 
> 
> [Case 1]
> Packet distribution on multi-queue based on dst MAC address.
> 
> NIC config:
> 04:00.0 Mellanox Connect-X5
> 0.5.00.0 Intel XXV710
> 
> testpmd startup param:
> sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-
> filter-mode=perfect
> 
> flow command:
> testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 /
> testpmd> end actions queue index 1 / end
> Flow rule #0 created
> testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66 type
> testpmd> mask 0xffff / end actions queue index 1 / end
> Flow rule #0 created
> 
> Packet reception:(no VLAN tag)
> port 0/queue 0: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> port 1/queue 1: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw
> ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw
> ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> Result:
> Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> 
> Expectation:
> When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> received on queue=1 port=0.
> 
> Question:
> Why matching packet is NOT enqueued into queue=1 on port=0?
> 
> 
> [Case 2]
> Packet distribution on multi-queue based on VLAN tag
> 
> testpmd startup param:
> sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-
> filter-mode=perfect
> 
> flow command:
> flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end actions queue
> index 1 / of_pop_vlan / end flow create 0 ingress group 0 pattern eth / end
> actions jump group 1 / end
> 
> Packet Reception: (VLAN100)
> port 0/queue 1: received 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
>   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56
> - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
>   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> 
> Result:
> Matched packetd queued to queue=1, port=0 Other packet(VLAN101 packet)
> discarded.
> 
> Expectation:
> Matched packet queued to queue =1, port=0 Non Matched packet queued to
> queue=0, port=0
> 
> Question:
> Is above behavior collect?
> What is the default behavior of unmatchedd packets (queue to queue=0 or
> discard packet)
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> 
> 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hi Slava,


Thanks for your response.

1. Is the bug number is the follwoing?
https://bugs.dpdk.org/show_bug.cgi?id=96

2.I've sent packets using scapy with the follwing script
and I think it is unicast ICMP.
How did you thought the packets are broadcast/muticast?
Note that I am not familiar with log of testpmd.

----------------------------------------------------------------------------------------------
from scapy.all import *

vlan_vid = 100
vlan_prio = 0
vlan_id = 0
vlan_flg = True
src_mac = "CC:CC:CC:CC:CC:CC" 
dst_mac = "11:22:33:44:55:66" 
dst_ip = "192.168.200.101" 
iface = "p7p1" 
pps = 5
loop = 5

def icmp_send():
    ls(Dot1Q)
    if vlan_flg:
        pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid, prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
    else:
        pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
    pkt.show()
    sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)

icmp_send()
-----------------------------------------------------------------------------

Thanks!

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi, Hideyuki
> 
> The frame in your report is broadcast/multicast. Please, try unicast one.
> For broadcast we have the ticket, currently issue is under investigation.
> Anyway, thanks for reporting.
> 
> With best regards, Slava
> 
> > -----Original Message-----
> > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > Sent: Thursday, November 14, 2019 7:02
> > To: dev@dpdk.org
> > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on
> > VLAN header
> > 
> > Hello Slava,
> > 
> > As I reported to you, creating flow was successful with Connect-X5.
> > However when I sent packets to the NIC from outer side of the host, I have
> > problem.
> > 
> > 
> > [Case 1]
> > Packet distribution on multi-queue based on dst MAC address.
> > 
> > NIC config:
> > 04:00.0 Mellanox Connect-X5
> > 0.5.00.0 Intel XXV710
> > 
> > testpmd startup param:
> > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-
> > filter-mode=perfect
> > 
> > flow command:
> > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 /
> > testpmd> end actions queue index 1 / end
> > Flow rule #0 created
> > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66 type
> > testpmd> mask 0xffff / end actions queue index 1 / end
> > Flow rule #0 created
> > 
> > Packet reception:(no VLAN tag)
> > port 0/queue 0: received 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > 
> > port 1/queue 1: received 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw
> > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=60
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  - sw
> > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > 
> > Result:
> > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > 
> > Expectation:
> > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > received on queue=1 port=0.
> > 
> > Question:
> > Why matching packet is NOT enqueued into queue=1 on port=0?
> > 
> > 
> > [Case 2]
> > Packet distribution on multi-queue based on VLAN tag
> > 
> > testpmd startup param:
> > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --pkt-
> > filter-mode=perfect
> > 
> > flow command:
> > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end actions queue
> > index 1 / of_pop_vlan / end flow create 0 ingress group 0 pattern eth / end
> > actions jump group 1 / end
> > 
> > Packet Reception: (VLAN100)
> > port 0/queue 1: received 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 - length=56
> > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG  -
> > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > 
> > Result:
> > Matched packetd queued to queue=1, port=0 Other packet(VLAN101 packet)
> > discarded.
> > 
> > Expectation:
> > Matched packet queued to queue =1, port=0 Non Matched packet queued to
> > queue=0, port=0
> > 
> > Question:
> > Is above behavior collect?
> > What is the default behavior of unmatchedd packets (queue to queue=0 or
> > discard packet)
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > 
> > 
> > 
> > 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Matan Azrad]

Hi

This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2 multicast packet.

When you run Testpmd application the multicast configuration is forwarded to the device by default.

So, you have 2 rules:
The default which try to match on the above dst mac bit and to do RSS action for all the queues.
Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bit is on) and more and to send it to queue 1.

So, your flow is sub flow of the default flow.

Since the current behavior in our driver is to put all the multicast rules in the same priority - the behavior for the case is unpredictable:
1. you can get the packet twice for the 2 rules.
2. you can get the packet onl for the default RSS action.
3. you can get the packet only on queue 1 as in your rule.

Unfortunately, here, you got option 1 I think (you get the packet twice in your application).

This behavior in our driver to put the 2 rules in same behavior is in discussion by us - maybe it will be changed later.

To workaround the issue:
1. do not configure the default rules (run with --flow-isolate-all in testpmd cmdline).
2. do not configure 2 different multicast rules (even with different priorities).

Enjoy, let me know if you need more help....

Matan

From: Hideyuki Yamashita
> Hi Slava,
> 
> 
> Thanks for your response.
> 
> 1. Is the bug number is the follwoing?
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> 
> 2.I've sent packets using scapy with the follwing script and I think it is unicast
> ICMP.
> How did you thought the packets are broadcast/muticast?
> Note that I am not familiar with log of testpmd.
> 
> ----------------------------------------------------------------------------------------------
> from scapy.all import *
> 
> vlan_vid = 100
> vlan_prio = 0
> vlan_id = 0
> vlan_flg = True
> src_mac = "CC:CC:CC:CC:CC:CC"
> dst_mac = "11:22:33:44:55:66"
> dst_ip = "192.168.200.101"
> iface = "p7p1"
> pps = 5
> loop = 5
> 
> def icmp_send():
>     ls(Dot1Q)
>     if vlan_flg:
>         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
>     else:
>         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
>     pkt.show()
>     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> 
> icmp_send()
> -----------------------------------------------------------------------------
> 
> Thanks!
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki
> >
> > The frame in your report is broadcast/multicast. Please, try unicast one.
> > For broadcast we have the ticket, currently issue is under investigation.
> > Anyway, thanks for reporting.
> >
> > With best regards, Slava
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > Sent: Thursday, November 14, 2019 7:02
> > > To: dev@dpdk.org
> > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Hello Slava,
> > >
> > > As I reported to you, creating flow was successful with Connect-X5.
> > > However when I sent packets to the NIC from outer side of the host,
> > > I have problem.
> > >
> > >
> > > [Case 1]
> > > Packet distribution on multi-queue based on dst MAC address.
> > >
> > > NIC config:
> > > 04:00.0 Mellanox Connect-X5
> > > 0.5.00.0 Intel XXV710
> > >
> > > testpmd startup param:
> > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> pkt-
> > > filter-mode=perfect
> > >
> > > flow command:
> > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > testpmd> / end actions queue index 1 / end
> > > Flow rule #0 created
> > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > Flow rule #0 created
> > >
> > > Packet reception:(no VLAN tag)
> > > port 0/queue 0: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > port 1/queue 1: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> sw
> > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> sw
> > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > Result:
> > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > >
> > > Expectation:
> > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > received on queue=1 port=0.
> > >
> > > Question:
> > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > >
> > >
> > > [Case 2]
> > > Packet distribution on multi-queue based on VLAN tag
> > >
> > > testpmd startup param:
> > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> pkt-
> > > filter-mode=perfect
> > >
> > > flow command:
> > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > group 0 pattern eth / end actions jump group 1 / end
> > >
> > > Packet Reception: (VLAN100)
> > > port 0/queue 1: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=56
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=56
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > Result:
> > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > packet) discarded.
> > >
> > > Expectation:
> > > Matched packet queued to queue =1, port=0 Non Matched packet
> queued
> > > to queue=0, port=0
> > >
> > > Question:
> > > Is above behavior collect?
> > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > or discard packet)
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > >
> > >
> > >
> > >
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Matan and Slava,

Thanks for your quick response.

1. What you were saying is correct.
 When I create flow with dst mac 10:22:33:44:55:66 instead of
11:22:33:44:55:66, received packets are queued to specified queue.

Thanks for your advice!

Q1. What is the problem with broadcast/multicast address? 
Q2. What is the bug number on Bugzilla of DPDK?
Q3. What is the default behavior of unmatched packets?
Discard packet or queue those to default queue(e.g. queue=0)?

When I tested packet distribution with vlan id, unmatched packets 
looked discarded..
I would like to know what is the default handling.

Thanks!

Best Regards,
Hideyuki Yamashita
NTT TechnoCross


> Hi
> 
> This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2 multicast packet.
> 
> When you run Testpmd application the multicast configuration is forwarded to the device by default.
> 
> So, you have 2 rules:
> The default which try to match on the above dst mac bit and to do RSS action for all the queues.
> Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bit is on) and more and to send it to queue 1.
> 
> So, your flow is sub flow of the default flow.
> 
> Since the current behavior in our driver is to put all the multicast rules in the same priority - the behavior for the case is unpredictable:
> 1. you can get the packet twice for the 2 rules.
> 2. you can get the packet onl for the default RSS action.
> 3. you can get the packet only on queue 1 as in your rule.
> 
> Unfortunately, here, you got option 1 I think (you get the packet twice in your application).
> 
> This behavior in our driver to put the 2 rules in same behavior is in discussion by us - maybe it will be changed later.
> 
> To workaround the issue:
> 1. do not configure the default rules (run with --flow-isolate-all in testpmd cmdline).
> 2. do not configure 2 different multicast rules (even with different priorities).
> 
> Enjoy, let me know if you need more help....
> 
> Matan
> 
> From: Hideyuki Yamashita
> > Hi Slava,
> > 
> > 
> > Thanks for your response.
> > 
> > 1. Is the bug number is the follwoing?
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> > 
> > 2.I've sent packets using scapy with the follwing script and I think it is unicast
> > ICMP.
> > How did you thought the packets are broadcast/muticast?
> > Note that I am not familiar with log of testpmd.
> > 
> > ----------------------------------------------------------------------------------------------
> > from scapy.all import *
> > 
> > vlan_vid = 100
> > vlan_prio = 0
> > vlan_id = 0
> > vlan_flg = True
> > src_mac = "CC:CC:CC:CC:CC:CC"
> > dst_mac = "11:22:33:44:55:66"
> > dst_ip = "192.168.200.101"
> > iface = "p7p1"
> > pps = 5
> > loop = 5
> > 
> > def icmp_send():
> >     ls(Dot1Q)
> >     if vlan_flg:
> >         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> > prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
> >     else:
> >         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
> >     pkt.show()
> >     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> > 
> > icmp_send()
> > -----------------------------------------------------------------------------
> > 
> > Thanks!
> > 
> > BR,
> > Hideyuki Yamashita
> > NTT TechnoCross
> > 
> > > Hi, Hideyuki
> > >
> > > The frame in your report is broadcast/multicast. Please, try unicast one.
> > > For broadcast we have the ticket, currently issue is under investigation.
> > > Anyway, thanks for reporting.
> > >
> > > With best regards, Slava
> > >
> > > > -----Original Message-----
> > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > Sent: Thursday, November 14, 2019 7:02
> > > > To: dev@dpdk.org
> > > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > action on VLAN header
> > > >
> > > > Hello Slava,
> > > >
> > > > As I reported to you, creating flow was successful with Connect-X5.
> > > > However when I sent packets to the NIC from outer side of the host,
> > > > I have problem.
> > > >
> > > >
> > > > [Case 1]
> > > > Packet distribution on multi-queue based on dst MAC address.
> > > >
> > > > NIC config:
> > > > 04:00.0 Mellanox Connect-X5
> > > > 0.5.00.0 Intel XXV710
> > > >
> > > > testpmd startup param:
> > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > pkt-
> > > > filter-mode=perfect
> > > >
> > > > flow command:
> > > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > > testpmd> / end actions queue index 1 / end
> > > > Flow rule #0 created
> > > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > > Flow rule #0 created
> > > >
> > > > Packet reception:(no VLAN tag)
> > > > port 0/queue 0: received 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=60
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > L4_NONFRAG  -
> > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=60
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > L4_NONFRAG  -
> > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > >
> > > > port 1/queue 1: received 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=60
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > sw
> > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=60
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > sw
> > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > >
> > > > Result:
> > > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > > >
> > > > Expectation:
> > > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > > received on queue=1 port=0.
> > > >
> > > > Question:
> > > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > > >
> > > >
> > > > [Case 2]
> > > > Packet distribution on multi-queue based on VLAN tag
> > > >
> > > > testpmd startup param:
> > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > pkt-
> > > > filter-mode=perfect
> > > >
> > > > flow command:
> > > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > > group 0 pattern eth / end actions jump group 1 / end
> > > >
> > > > Packet Reception: (VLAN100)
> > > > port 0/queue 1: received 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=56
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > L4_NONFRAG  -
> > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > length=56
> > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > L4_NONFRAG  -
> > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > >
> > > > Result:
> > > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > > packet) discarded.
> > > >
> > > > Expectation:
> > > > Matched packet queued to queue =1, port=0 Non Matched packet
> > queued
> > > > to queue=0, port=0
> > > >
> > > > Question:
> > > > Is above behavior collect?
> > > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > > or discard packet)
> > > >
> > > > BR,
> > > > Hideyuki Yamashita
> > > > NTT TechnoCross
> > > >
> > > >
> > > >
> > > >
> > > >
> > 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Matan and Slava,

Thanks for your quick response.

How about the following?

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hello Matan and Slava,
> 
> Thanks for your quick response.
> 
> 1. What you were saying is correct.
>  When I create flow with dst mac 10:22:33:44:55:66 instead of
> 11:22:33:44:55:66, received packets are queued to specified queue.
> 
> Thanks for your advice!
> 
> Q1. What is the problem with broadcast/multicast address? 
> Q2. What is the bug number on Bugzilla of DPDK?
> Q3. What is the default behavior of unmatched packets?
> Discard packet or queue those to default queue(e.g. queue=0)?
> 
> When I tested packet distribution with vlan id, unmatched packets 
> looked discarded..
> I would like to know what is the default handling.
> 
> Thanks!
> 
> Best Regards,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > Hi
> > 
> > This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2 multicast packet.
> > 
> > When you run Testpmd application the multicast configuration is forwarded to the device by default.
> > 
> > So, you have 2 rules:
> > The default which try to match on the above dst mac bit and to do RSS action for all the queues.
> > Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bit is on) and more and to send it to queue 1.
> > 
> > So, your flow is sub flow of the default flow.
> > 
> > Since the current behavior in our driver is to put all the multicast rules in the same priority - the behavior for the case is unpredictable:
> > 1. you can get the packet twice for the 2 rules.
> > 2. you can get the packet onl for the default RSS action.
> > 3. you can get the packet only on queue 1 as in your rule.
> > 
> > Unfortunately, here, you got option 1 I think (you get the packet twice in your application).
> > 
> > This behavior in our driver to put the 2 rules in same behavior is in discussion by us - maybe it will be changed later.
> > 
> > To workaround the issue:
> > 1. do not configure the default rules (run with --flow-isolate-all in testpmd cmdline).
> > 2. do not configure 2 different multicast rules (even with different priorities).
> > 
> > Enjoy, let me know if you need more help....
> > 
> > Matan
> > 
> > From: Hideyuki Yamashita
> > > Hi Slava,
> > > 
> > > 
> > > Thanks for your response.
> > > 
> > > 1. Is the bug number is the follwoing?
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> > > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> > > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> > > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> > > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> > > 
> > > 2.I've sent packets using scapy with the follwing script and I think it is unicast
> > > ICMP.
> > > How did you thought the packets are broadcast/muticast?
> > > Note that I am not familiar with log of testpmd.
> > > 
> > > ----------------------------------------------------------------------------------------------
> > > from scapy.all import *
> > > 
> > > vlan_vid = 100
> > > vlan_prio = 0
> > > vlan_id = 0
> > > vlan_flg = True
> > > src_mac = "CC:CC:CC:CC:CC:CC"
> > > dst_mac = "11:22:33:44:55:66"
> > > dst_ip = "192.168.200.101"
> > > iface = "p7p1"
> > > pps = 5
> > > loop = 5
> > > 
> > > def icmp_send():
> > >     ls(Dot1Q)
> > >     if vlan_flg:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> > > prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
> > >     else:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
> > >     pkt.show()
> > >     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> > > 
> > > icmp_send()
> > > -----------------------------------------------------------------------------
> > > 
> > > Thanks!
> > > 
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > > 
> > > > Hi, Hideyuki
> > > >
> > > > The frame in your report is broadcast/multicast. Please, try unicast one.
> > > > For broadcast we have the ticket, currently issue is under investigation.
> > > > Anyway, thanks for reporting.
> > > >
> > > > With best regards, Slava
> > > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Thursday, November 14, 2019 7:02
> > > > > To: dev@dpdk.org
> > > > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Hello Slava,
> > > > >
> > > > > As I reported to you, creating flow was successful with Connect-X5.
> > > > > However when I sent packets to the NIC from outer side of the host,
> > > > > I have problem.
> > > > >
> > > > >
> > > > > [Case 1]
> > > > > Packet distribution on multi-queue based on dst MAC address.
> > > > >
> > > > > NIC config:
> > > > > 04:00.0 Mellanox Connect-X5
> > > > > 0.5.00.0 Intel XXV710
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > >
> > > > > Packet reception:(no VLAN tag)
> > > > > port 0/queue 0: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > port 1/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > > > >
> > > > > Expectation:
> > > > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > > > received on queue=1 port=0.
> > > > >
> > > > > Question:
> > > > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > > > >
> > > > >
> > > > > [Case 2]
> > > > > Packet distribution on multi-queue based on VLAN tag
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > > > group 0 pattern eth / end actions jump group 1 / end
> > > > >
> > > > > Packet Reception: (VLAN100)
> > > > > port 0/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > > > packet) discarded.
> > > > >
> > > > > Expectation:
> > > > > Matched packet queued to queue =1, port=0 Non Matched packet
> > > queued
> > > > > to queue=0, port=0
> > > > >
> > > > > Question:
> > > > > Is above behavior collect?
> > > > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > > > or discard packet)
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > 
> > 
> 
> 

Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Hideyuki Yamashita]

Hello Matan and Slava,

Thanks for your quick response.

How about the following?

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hello Matan and Slava,
> 
> Thanks for your quick response.
> 
> 1. What you were saying is correct.
>  When I create flow with dst mac 10:22:33:44:55:66 instead of
> 11:22:33:44:55:66, received packets are queued to specified queue.
> 
> Thanks for your advice!
> 
> Q1. What is the problem with broadcast/multicast address? 
> Q2. What is the bug number on Bugzilla of DPDK?
> Q3. What is the default behavior of unmatched packets?
> Discard packet or queue those to default queue(e.g. queue=0)?
> 
> When I tested packet distribution with vlan id, unmatched packets 
> looked discarded..
> I would like to know what is the default handling.
> 
> Thanks!
> 
> Best Regards,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > Hi
> > 
> > This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2 multicast packet.
> > 
> > When you run Testpmd application the multicast configuration is forwarded to the device by default.
> > 
> > So, you have 2 rules:
> > The default which try to match on the above dst mac bit and to do RSS action for all the queues.
> > Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bit is on) and more and to send it to queue 1.
> > 
> > So, your flow is sub flow of the default flow.
> > 
> > Since the current behavior in our driver is to put all the multicast rules in the same priority - the behavior for the case is unpredictable:
> > 1. you can get the packet twice for the 2 rules.
> > 2. you can get the packet onl for the default RSS action.
> > 3. you can get the packet only on queue 1 as in your rule.
> > 
> > Unfortunately, here, you got option 1 I think (you get the packet twice in your application).
> > 
> > This behavior in our driver to put the 2 rules in same behavior is in discussion by us - maybe it will be changed later.
> > 
> > To workaround the issue:
> > 1. do not configure the default rules (run with --flow-isolate-all in testpmd cmdline).
> > 2. do not configure 2 different multicast rules (even with different priorities).
> > 
> > Enjoy, let me know if you need more help....
> > 
> > Matan
> > 
> > From: Hideyuki Yamashita
> > > Hi Slava,
> > > 
> > > 
> > > Thanks for your response.
> > > 
> > > 1. Is the bug number is the follwoing?
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> > > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> > > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> > > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> > > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> > > 
> > > 2.I've sent packets using scapy with the follwing script and I think it is unicast
> > > ICMP.
> > > How did you thought the packets are broadcast/muticast?
> > > Note that I am not familiar with log of testpmd.
> > > 
> > > ----------------------------------------------------------------------------------------------
> > > from scapy.all import *
> > > 
> > > vlan_vid = 100
> > > vlan_prio = 0
> > > vlan_id = 0
> > > vlan_flg = True
> > > src_mac = "CC:CC:CC:CC:CC:CC"
> > > dst_mac = "11:22:33:44:55:66"
> > > dst_ip = "192.168.200.101"
> > > iface = "p7p1"
> > > pps = 5
> > > loop = 5
> > > 
> > > def icmp_send():
> > >     ls(Dot1Q)
> > >     if vlan_flg:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> > > prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
> > >     else:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
> > >     pkt.show()
> > >     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> > > 
> > > icmp_send()
> > > -----------------------------------------------------------------------------
> > > 
> > > Thanks!
> > > 
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > > 
> > > > Hi, Hideyuki
> > > >
> > > > The frame in your report is broadcast/multicast. Please, try unicast one.
> > > > For broadcast we have the ticket, currently issue is under investigation.
> > > > Anyway, thanks for reporting.
> > > >
> > > > With best regards, Slava
> > > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> > > > > Sent: Thursday, November 14, 2019 7:02
> > > > > To: dev@dpdk.org
> > > > > Cc: Slava Ovsiienko <viacheslavo@mellanox.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Hello Slava,
> > > > >
> > > > > As I reported to you, creating flow was successful with Connect-X5.
> > > > > However when I sent packets to the NIC from outer side of the host,
> > > > > I have problem.
> > > > >
> > > > >
> > > > > [Case 1]
> > > > > Packet distribution on multi-queue based on dst MAC address.
> > > > >
> > > > > NIC config:
> > > > > 04:00.0 Mellanox Connect-X5
> > > > > 0.5.00.0 Intel XXV710
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > >
> > > > > Packet reception:(no VLAN tag)
> > > > > port 0/queue 0: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > port 1/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > > > >
> > > > > Expectation:
> > > > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > > > received on queue=1 port=0.
> > > > >
> > > > > Question:
> > > > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > > > >
> > > > >
> > > > > [Case 2]
> > > > > Packet distribution on multi-queue based on VLAN tag
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > > > group 0 pattern eth / end actions jump group 1 / end
> > > > >
> > > > > Packet Reception: (VLAN100)
> > > > > port 0/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > > > packet) discarded.
> > > > >
> > > > > Expectation:
> > > > > Matched packet queued to queue =1, port=0 Non Matched packet
> > > queued
> > > > > to queue=0, port=0
> > > > >
> > > > > Question:
> > > > > Is above behavior collect?
> > > > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > > > or discard packet)
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > 
> > 
> 
>