DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ivan Malov <ivan.malov@oktetlabs.ru>
To: dev@dpdk.org
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Andy Moreton <amoreton@xilinx.com>, Ray Kinsella <mdr@ashroe.eu>,
	Neil Horman <nhorman@tuxdriver.com>
Subject: [dpdk-dev] [PATCH 06/10] common/sfc_efx/base: support adding action ENCAP to a set
Date: Fri, 12 Mar 2021 12:31:39 +0300	[thread overview]
Message-ID: <20210312093143.28186-6-ivan.malov@oktetlabs.ru> (raw)
In-Reply-To: <20210312093143.28186-1-ivan.malov@oktetlabs.ru>

For convenience, there are two separate APIs provided, one for
adding the action and one for setting the encap. header ID.
This design allows the client driver to first build the action
set specification (which validates the order of the actions)
and, if everything is correct, proceed with allocation of the
resource utilised by the action set (encap. header). This
facilitates clarity of the client code and its efficiency.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
---
 drivers/common/sfc_efx/base/efx.h      |  16 ++++
 drivers/common/sfc_efx/base/efx_impl.h |  12 +++
 drivers/common/sfc_efx/base/efx_mae.c  | 126 ++++++++++++++++++++++++-
 drivers/common/sfc_efx/version.map     |   2 +
 4 files changed, 153 insertions(+), 3 deletions(-)

diff --git a/drivers/common/sfc_efx/base/efx.h b/drivers/common/sfc_efx/base/efx.h
index 4a738e589..052946aa3 100644
--- a/drivers/common/sfc_efx/base/efx.h
+++ b/drivers/common/sfc_efx/base/efx.h
@@ -4252,6 +4252,15 @@ efx_mae_action_set_populate_vlan_push(
 	__in				uint16_t tpid_be,
 	__in				uint16_t tci_be);
 
+/*
+ * Use efx_mae_action_set_fill_in_eh_id() to set ID of the allocated
+ * encap. header in the specification prior to action set allocation.
+ */
+LIBEFX_API
+extern	__checkReturn			efx_rc_t
+efx_mae_action_set_populate_encap(
+	__in				efx_mae_actions_t *spec);
+
 LIBEFX_API
 extern	__checkReturn			efx_rc_t
 efx_mae_action_set_populate_flag(
@@ -4345,6 +4354,13 @@ efx_mae_encap_header_free(
 	__in				efx_nic_t *enp,
 	__in				const efx_mae_eh_id_t *eh_idp);
 
+/* See description before efx_mae_action_set_populate_encap(). */
+LIBEFX_API
+extern	__checkReturn			efx_rc_t
+efx_mae_action_set_fill_in_eh_id(
+	__in				efx_mae_actions_t *spec,
+	__in				const efx_mae_eh_id_t *eh_idp);
+
 /* Action set ID */
 typedef struct efx_mae_aset_id_s {
 	uint32_t id;
diff --git a/drivers/common/sfc_efx/base/efx_impl.h b/drivers/common/sfc_efx/base/efx_impl.h
index 1005dd0aa..0adf43c26 100644
--- a/drivers/common/sfc_efx/base/efx_impl.h
+++ b/drivers/common/sfc_efx/base/efx_impl.h
@@ -1709,6 +1709,7 @@ typedef enum efx_mae_action_e {
 	/* These actions are strictly ordered. */
 	EFX_MAE_ACTION_VLAN_POP,
 	EFX_MAE_ACTION_VLAN_PUSH,
+	EFX_MAE_ACTION_ENCAP,
 
 	/*
 	 * These actions are not strictly ordered and can
@@ -1736,6 +1737,10 @@ typedef struct efx_mae_action_vlan_push_s {
 	uint16_t			emavp_tci_be;
 } efx_mae_action_vlan_push_t;
 
+typedef struct efx_mae_actions_rsrc_s {
+	efx_mae_eh_id_t			emar_eh_id;
+} efx_mae_actions_rsrc_t;
+
 struct efx_mae_actions_s {
 	/* Bitmap of actions in spec, indexed by action type */
 	uint32_t			ema_actions;
@@ -1746,6 +1751,13 @@ struct efx_mae_actions_s {
 	    EFX_MAE_VLAN_PUSH_MAX_NTAGS];
 	uint32_t			ema_mark_value;
 	efx_mport_sel_t			ema_deliver_mport;
+
+	/*
+	 * Always keep this at the end of the struct since
+	 * efx_mae_action_set_specs_equal() relies on that
+	 * to make sure that resource IDs are not compared.
+	 */
+	efx_mae_actions_rsrc_t		ema_rsrc;
 };
 
 #endif /* EFSYS_OPT_MAE */
diff --git a/drivers/common/sfc_efx/base/efx_mae.c b/drivers/common/sfc_efx/base/efx_mae.c
index 798867963..896500de0 100644
--- a/drivers/common/sfc_efx/base/efx_mae.c
+++ b/drivers/common/sfc_efx/base/efx_mae.c
@@ -994,6 +994,8 @@ efx_mae_action_set_spec_init(
 		goto fail1;
 	}
 
+	spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
+
 	*specp = spec;
 
 	return (0);
@@ -1085,6 +1087,50 @@ efx_mae_action_set_add_vlan_push(
 	return (rc);
 }
 
+static	__checkReturn			efx_rc_t
+efx_mae_action_set_add_encap(
+	__in				efx_mae_actions_t *spec,
+	__in				size_t arg_size,
+	__in_bcount(arg_size)		const uint8_t *arg)
+{
+	efx_rc_t rc;
+
+	/*
+	 * Adding this specific action to an action set spec and setting encap.
+	 * header ID in the spec are two individual steps. This design allows
+	 * the client driver to avoid encap. header allocation when it simply
+	 * needs to check the order of actions submitted by user ("validate"),
+	 * without actually allocating an action set and inserting a rule.
+	 *
+	 * For now, mark encap. header ID as invalid; the caller will invoke
+	 * efx_mae_action_set_fill_in_eh_id() to override the field prior
+	 * to action set allocation; otherwise, the allocation will fail.
+	 */
+	spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
+
+	/*
+	 * As explained above, there are no arguments to handle here.
+	 * efx_mae_action_set_fill_in_eh_id() will take care of them.
+	 */
+	if (arg_size != 0) {
+		rc = EINVAL;
+		goto fail1;
+	}
+
+	if (arg != NULL) {
+		rc = EINVAL;
+		goto fail2;
+	}
+
+	return (0);
+
+fail2:
+	EFSYS_PROBE(fail2);
+fail1:
+	EFSYS_PROBE1(fail1, efx_rc_t, rc);
+	return (rc);
+}
+
 static	__checkReturn			efx_rc_t
 efx_mae_action_set_add_flag(
 	__in				efx_mae_actions_t *spec,
@@ -1187,6 +1233,9 @@ static const efx_mae_action_desc_t efx_mae_actions[EFX_MAE_NACTIONS] = {
 	[EFX_MAE_ACTION_VLAN_PUSH] = {
 		.emad_add = efx_mae_action_set_add_vlan_push
 	},
+	[EFX_MAE_ACTION_ENCAP] = {
+		.emad_add = efx_mae_action_set_add_encap
+	},
 	[EFX_MAE_ACTION_FLAG] = {
 		.emad_add = efx_mae_action_set_add_flag
 	},
@@ -1201,6 +1250,7 @@ static const efx_mae_action_desc_t efx_mae_actions[EFX_MAE_NACTIONS] = {
 static const uint32_t efx_mae_action_ordered_map =
 	(1U << EFX_MAE_ACTION_VLAN_POP) |
 	(1U << EFX_MAE_ACTION_VLAN_PUSH) |
+	(1U << EFX_MAE_ACTION_ENCAP) |
 	(1U << EFX_MAE_ACTION_FLAG) |
 	(1U << EFX_MAE_ACTION_MARK) |
 	(1U << EFX_MAE_ACTION_DELIVER);
@@ -1317,6 +1367,20 @@ efx_mae_action_set_populate_vlan_push(
 	    EFX_MAE_ACTION_VLAN_PUSH, sizeof (action), arg));
 }
 
+	__checkReturn			efx_rc_t
+efx_mae_action_set_populate_encap(
+	__in				efx_mae_actions_t *spec)
+{
+	/*
+	 * There is no argument to pass encap. header ID, thus, one does not
+	 * need to allocate an encap. header while parsing application input.
+	 * This is useful since building an action set may be done simply to
+	 * validate a rule, whilst resource allocation usually consumes time.
+	 */
+	return (efx_mae_action_set_spec_populate(spec,
+	    EFX_MAE_ACTION_ENCAP, 0, NULL));
+}
+
 	__checkReturn			efx_rc_t
 efx_mae_action_set_populate_flag(
 	__in				efx_mae_actions_t *spec)
@@ -1389,7 +1453,22 @@ efx_mae_action_set_specs_equal(
 	__in				const efx_mae_actions_t *left,
 	__in				const efx_mae_actions_t *right)
 {
-	return ((memcmp(left, right, sizeof (*left)) == 0) ? B_TRUE : B_FALSE);
+	size_t cmp_size = EFX_FIELD_OFFSET(efx_mae_actions_t, ema_rsrc);
+
+	/*
+	 * An action set specification consists of two parts. The first part
+	 * indicates what actions are included in the action set, as well as
+	 * extra quantitative values (in example, the number of VLAN tags to
+	 * push). The second part comprises resource IDs used by the actions.
+	 *
+	 * A resource, in example, a counter, is allocated from the hardware
+	 * by the client, and it's the client who is responsible for keeping
+	 * track of allocated resources and comparing resource IDs if needed.
+	 *
+	 * In this API, don't compare resource IDs in the two specifications.
+	 */
+
+	return ((memcmp(left, right, cmp_size) == 0) ? B_TRUE : B_FALSE);
 }
 
 	__checkReturn			efx_rc_t
@@ -1846,6 +1925,46 @@ efx_mae_encap_header_free(
 
 	return (0);
 
+fail3:
+	EFSYS_PROBE(fail3);
+fail2:
+	EFSYS_PROBE(fail2);
+fail1:
+	EFSYS_PROBE1(fail1, efx_rc_t, rc);
+	return (rc);
+}
+
+	__checkReturn			efx_rc_t
+efx_mae_action_set_fill_in_eh_id(
+	__in				efx_mae_actions_t *spec,
+	__in				const efx_mae_eh_id_t *eh_idp)
+{
+	efx_rc_t rc;
+
+	if ((spec->ema_actions & (1U << EFX_MAE_ACTION_ENCAP)) == 0) {
+		/*
+		 * The caller has not intended to have action ENCAP originally,
+		 * hence, this attempt to indicate encap. header ID is invalid.
+		 */
+		rc = EINVAL;
+		goto fail1;
+	}
+
+	if (spec->ema_rsrc.emar_eh_id.id != EFX_MAE_RSRC_ID_INVALID) {
+		/* The caller attempts to indicate encap. header ID twice. */
+		rc = EINVAL;
+		goto fail2;
+	}
+
+	if (eh_idp->id == EFX_MAE_RSRC_ID_INVALID) {
+		rc = EINVAL;
+		goto fail3;
+	}
+
+	spec->ema_rsrc.emar_eh_id.id = eh_idp->id;
+
+	return (0);
+
 fail3:
 	EFSYS_PROBE(fail3);
 fail2:
@@ -1889,8 +2008,6 @@ efx_mae_action_set_alloc(
 	    MAE_ACTION_SET_ALLOC_IN_COUNTER_LIST_ID, EFX_MAE_RSRC_ID_INVALID);
 	MCDI_IN_SET_DWORD(req,
 	    MAE_ACTION_SET_ALLOC_IN_COUNTER_ID, EFX_MAE_RSRC_ID_INVALID);
-	MCDI_IN_SET_DWORD(req,
-	    MAE_ACTION_SET_ALLOC_IN_ENCAP_HEADER_ID, EFX_MAE_RSRC_ID_INVALID);
 
 	MCDI_IN_SET_DWORD_FIELD(req, MAE_ACTION_SET_ALLOC_IN_FLAGS,
 	    MAE_ACTION_SET_ALLOC_IN_VLAN_POP, spec->ema_n_vlan_tags_to_pop);
@@ -1920,6 +2037,9 @@ efx_mae_action_set_alloc(
 		    spec->ema_vlan_push_descs[outer_tag_idx].emavp_tci_be);
 	}
 
+	MCDI_IN_SET_DWORD(req, MAE_ACTION_SET_ALLOC_IN_ENCAP_HEADER_ID,
+	    spec->ema_rsrc.emar_eh_id.id);
+
 	if ((spec->ema_actions & (1U << EFX_MAE_ACTION_FLAG)) != 0) {
 		MCDI_IN_SET_DWORD_FIELD(req, MAE_ACTION_SET_ALLOC_IN_FLAGS,
 		    MAE_ACTION_SET_ALLOC_IN_FLAG, 1);
diff --git a/drivers/common/sfc_efx/version.map b/drivers/common/sfc_efx/version.map
index 168899d51..f33a2a08e 100644
--- a/drivers/common/sfc_efx/version.map
+++ b/drivers/common/sfc_efx/version.map
@@ -88,9 +88,11 @@ INTERNAL {
 	efx_mae_action_rule_insert;
 	efx_mae_action_rule_remove;
 	efx_mae_action_set_alloc;
+	efx_mae_action_set_fill_in_eh_id;
 	efx_mae_action_set_free;
 	efx_mae_action_set_populate_deliver;
 	efx_mae_action_set_populate_drop;
+	efx_mae_action_set_populate_encap;
 	efx_mae_action_set_populate_flag;
 	efx_mae_action_set_populate_mark;
 	efx_mae_action_set_populate_vlan_pop;
-- 
2.20.1


  parent reply	other threads:[~2021-03-12  9:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12  9:31 [dpdk-dev] [PATCH 01/10] ethdev: reuse header definition in flow pattern item ETH Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 02/10] ethdev: reuse header definition in flow pattern item VLAN Ivan Malov
2021-03-16 23:05   ` Ori Kam
2021-03-12  9:31 ` [dpdk-dev] [PATCH 03/10] net: clarify endianness of 32-bit fields in VXLAN headers Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 04/10] ethdev: reuse header definition in flow pattern item VXLAN Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 05/10] common/sfc_efx/base: support encap. header provisioning Ivan Malov
2021-03-12  9:31 ` Ivan Malov [this message]
2021-03-12  9:31 ` [dpdk-dev] [PATCH 07/10] net/sfc: change MAE rule actions parse API Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 08/10] net/sfc: support action VXLAN ENCAP in MAE backend Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 09/10] common/sfc_efx/base: support adding action DECAP to a set Ivan Malov
2021-03-12  9:31 ` [dpdk-dev] [PATCH 10/10] net/sfc: support action VXLAN DECAP in transfer rules Ivan Malov
2021-03-12 11:07 ` [dpdk-dev] [PATCH v2 01/10] ethdev: reuse header definition in flow pattern item ETH Ivan Malov
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 02/10] ethdev: reuse header definition in flow pattern item VLAN Ivan Malov
2021-03-16 16:58     ` Ferruh Yigit
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 03/10] net: clarify endianness of 32-bit fields in VXLAN headers Ivan Malov
2021-03-16 17:34     ` Ferruh Yigit
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 04/10] ethdev: reuse header definition in flow pattern item VXLAN Ivan Malov
2021-03-16 17:35     ` Ferruh Yigit
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 05/10] common/sfc_efx/base: support encap. header provisioning Ivan Malov
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 06/10] common/sfc_efx/base: support adding action ENCAP to a set Ivan Malov
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 07/10] net/sfc: change MAE rule actions parse API Ivan Malov
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 08/10] net/sfc: support action VXLAN ENCAP in MAE backend Ivan Malov
2021-03-16 17:10     ` Ivan Malov
2021-03-16 17:15       ` Ferruh Yigit
2021-03-31 23:21     ` Thomas Monjalon
2021-03-31 23:36       ` Ivan Malov
2021-04-01  6:38         ` Andrew Rybchenko
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 09/10] common/sfc_efx/base: support adding action DECAP to a set Ivan Malov
2021-03-12 11:07   ` [dpdk-dev] [PATCH v2 10/10] net/sfc: support action VXLAN DECAP in transfer rules Ivan Malov
2021-03-16 16:58   ` [dpdk-dev] [PATCH v2 01/10] ethdev: reuse header definition in flow pattern item ETH Ferruh Yigit
2021-03-16 17:38   ` Ferruh Yigit
2021-03-17  6:40     ` Andrew Rybchenko
2021-03-22  9:01       ` Ferruh Yigit
2021-03-22 10:10         ` Andrew Rybchenko
2021-03-22 16:49   ` Ferruh Yigit
2021-03-16 23:03 ` [dpdk-dev] [PATCH " Ori Kam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210312093143.28186-6-ivan.malov@oktetlabs.ru \
    --to=ivan.malov@oktetlabs.ru \
    --cc=amoreton@xilinx.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).