[v2,14/62] common/sfc_efx/base: add action set spec init/fini APIs

Message ID 1603185222-14831-15-git-send-email-arybchenko@solarflare.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series net/sfc: support flow API transfer rules |

Checks

Context Check Description
ci/checkpatch warning coding style issues

Commit Message

Andrew Rybchenko Oct. 20, 2020, 9:12 a.m. UTC
  From: Ivan Malov <ivan.malov@oktetlabs.ru>

The engine is only able to carry out chosen actions on matching packets in
a strict order. No MCDI exists to identify supported actions and the order.
Still, the definition of the latter is available from the FW documentation.

The general idea is to define an action specification structure and supply
a client driver with APIs for adding actions individually, order-dependent.
A client driver is supposed to invoke an API on every action passed by the
application, and if an out-of-order action follows, the API will reject it.

Add an action set specification stub and supply initialise / finalise APIs.

Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
---
 drivers/common/sfc_efx/base/efx.h             | 20 ++++++++++
 drivers/common/sfc_efx/base/efx_impl.h        |  3 ++
 drivers/common/sfc_efx/base/efx_mae.c         | 39 +++++++++++++++++++
 .../sfc_efx/rte_common_sfc_efx_version.map    |  3 ++
 4 files changed, 65 insertions(+)
  

Comments

Ali Alnubani Oct. 27, 2020, 9:13 a.m. UTC | #1
Hi,
Sent my report to v1 the first time by mistake.

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
> Sent: Tuesday, October 20, 2020 12:13 PM
> To: dev@dpdk.org
> Cc: Ivan Malov <ivan.malov@oktetlabs.ru>
> Subject: [dpdk-dev] [PATCH v2 14/62] common/sfc_efx/base: add action set
> spec init/fini APIs
> 
> From: Ivan Malov <ivan.malov@oktetlabs.ru>
> 
> The engine is only able to carry out chosen actions on matching packets in a
> strict order. No MCDI exists to identify supported actions and the order.
> Still, the definition of the latter is available from the FW documentation.
> 
> The general idea is to define an action specification structure and supply a
> client driver with APIs for adding actions individually, order-dependent.
> A client driver is supposed to invoke an API on every action passed by the
> application, and if an out-of-order action follows, the API will reject it.
> 
> Add an action set specification stub and supply initialise / finalise APIs.
> 
> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
> ---

This patch is causing the following build failure on CentOS 7 with clang 3.4.2:

"""
In file included from drivers/common/sfc_efx/base/efx_crc32.c:8:
drivers/common/sfc_efx/base/efx_impl.h:1703:3: error: redefinition of typedef 'efx_mae_actions_t' is a C11 feature [-Werror,-Wtypedef-redefinition] } efx_mae_actions_t;
drivers/common/sfc_efx/base/efx.h:4101:34: note: previous definition is here typedef struct efx_mae_actions_s efx_mae_actions_t; 
"""

Regards,
Ali
  
Ferruh Yigit Oct. 27, 2020, 11:39 a.m. UTC | #2
On 10/27/2020 9:13 AM, Ali Alnubani wrote:
> Hi,
> Sent my report to v1 the first time by mistake.
> 
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
>> Sent: Tuesday, October 20, 2020 12:13 PM
>> To: dev@dpdk.org
>> Cc: Ivan Malov <ivan.malov@oktetlabs.ru>
>> Subject: [dpdk-dev] [PATCH v2 14/62] common/sfc_efx/base: add action set
>> spec init/fini APIs
>>
>> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>>
>> The engine is only able to carry out chosen actions on matching packets in a
>> strict order. No MCDI exists to identify supported actions and the order.
>> Still, the definition of the latter is available from the FW documentation.
>>
>> The general idea is to define an action specification structure and supply a
>> client driver with APIs for adding actions individually, order-dependent.
>> A client driver is supposed to invoke an API on every action passed by the
>> application, and if an out-of-order action follows, the API will reject it.
>>
>> Add an action set specification stub and supply initialise / finalise APIs.
>>
>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
>> ---
> 
> This patch is causing the following build failure on CentOS 7 with clang 3.4.2:
> 
> """
> In file included from drivers/common/sfc_efx/base/efx_crc32.c:8:
> drivers/common/sfc_efx/base/efx_impl.h:1703:3: error: redefinition of typedef 'efx_mae_actions_t' is a C11 feature [-Werror,-Wtypedef-redefinition] } efx_mae_actions_t;
> drivers/common/sfc_efx/base/efx.h:4101:34: note: previous definition is here typedef struct efx_mae_actions_s efx_mae_actions_t;
> """
> 

Hi Andrew,

Are you working on this?
  
Andrew Rybchenko Oct. 27, 2020, 12:03 p.m. UTC | #3
On 10/27/20 2:39 PM, Ferruh Yigit wrote:
> On 10/27/2020 9:13 AM, Ali Alnubani wrote:
>> Hi,
>> Sent my report to v1 the first time by mistake.
>>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
>>> Sent: Tuesday, October 20, 2020 12:13 PM
>>> To: dev@dpdk.org
>>> Cc: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> Subject: [dpdk-dev] [PATCH v2 14/62] common/sfc_efx/base: add action
>>> set
>>> spec init/fini APIs
>>>
>>> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>>>
>>> The engine is only able to carry out chosen actions on matching
>>> packets in a
>>> strict order. No MCDI exists to identify supported actions and the
>>> order.
>>> Still, the definition of the latter is available from the FW
>>> documentation.
>>>
>>> The general idea is to define an action specification structure and
>>> supply a
>>> client driver with APIs for adding actions individually,
>>> order-dependent.
>>> A client driver is supposed to invoke an API on every action passed
>>> by the
>>> application, and if an out-of-order action follows, the API will
>>> reject it.
>>>
>>> Add an action set specification stub and supply initialise /
>>> finalise APIs.
>>>
>>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
>>> ---
>>
>> This patch is causing the following build failure on CentOS 7 with
>> clang 3.4.2:
>>
>> """
>> In file included from drivers/common/sfc_efx/base/efx_crc32.c:8:
>> drivers/common/sfc_efx/base/efx_impl.h:1703:3: error: redefinition of
>> typedef 'efx_mae_actions_t' is a C11 feature
>> [-Werror,-Wtypedef-redefinition] } efx_mae_actions_t;
>> drivers/common/sfc_efx/base/efx.h:4101:34: note: previous definition
>> is here typedef struct efx_mae_actions_s efx_mae_actions_t;
>> """
>>
>
> Hi Andrew,
>
> Are you working on this?

Hi Ferruh,

Yes, I have a patch. I will send it shortly.

Andrew.
  

Patch

diff --git a/drivers/common/sfc_efx/base/efx.h b/drivers/common/sfc_efx/base/efx.h
index c91f7948a0..cd0b22d43a 100644
--- a/drivers/common/sfc_efx/base/efx.h
+++ b/drivers/common/sfc_efx/base/efx.h
@@ -4098,6 +4098,26 @@  efx_mae_match_spec_is_valid(
 	__in				efx_nic_t *enp,
 	__in				const efx_mae_match_spec_t *spec);
 
+typedef struct efx_mae_actions_s efx_mae_actions_t;
+
+LIBEFX_API
+extern	__checkReturn			efx_rc_t
+efx_mae_action_set_spec_init(
+	__in				efx_nic_t *enp,
+	__out				efx_mae_actions_t **specp);
+
+LIBEFX_API
+extern					void
+efx_mae_action_set_spec_fini(
+	__in				efx_nic_t *enp,
+	__in				efx_mae_actions_t *spec);
+
+LIBEFX_API
+extern	__checkReturn			boolean_t
+efx_mae_action_set_specs_equal(
+	__in				const efx_mae_actions_t *left,
+	__in				const efx_mae_actions_t *right);
+
 /*
  * Conduct a comparison to check whether two match specifications
  * of equal rule type (action / outer) and priority would map to
diff --git a/drivers/common/sfc_efx/base/efx_impl.h b/drivers/common/sfc_efx/base/efx_impl.h
index 2b872bb62e..86ef8e1b92 100644
--- a/drivers/common/sfc_efx/base/efx_impl.h
+++ b/drivers/common/sfc_efx/base/efx_impl.h
@@ -1699,6 +1699,9 @@  struct efx_mae_match_spec_s {
 	} emms_mask_value_pairs;
 };
 
+typedef struct efx_mae_actions_s {
+} efx_mae_actions_t;
+
 #endif /* EFSYS_OPT_MAE */
 
 #ifdef	__cplusplus
diff --git a/drivers/common/sfc_efx/base/efx_mae.c b/drivers/common/sfc_efx/base/efx_mae.c
index a126cba37f..81c586dfe8 100644
--- a/drivers/common/sfc_efx/base/efx_mae.c
+++ b/drivers/common/sfc_efx/base/efx_mae.c
@@ -434,6 +434,45 @@  efx_mae_match_spec_is_valid(
 	return (is_valid);
 }
 
+	__checkReturn			efx_rc_t
+efx_mae_action_set_spec_init(
+	__in				efx_nic_t *enp,
+	__out				efx_mae_actions_t **specp)
+{
+	efx_mae_actions_t *spec;
+	efx_rc_t rc;
+
+	EFSYS_KMEM_ALLOC(enp->en_esip, sizeof (*spec), spec);
+	if (spec == NULL) {
+		rc = ENOMEM;
+		goto fail1;
+	}
+
+	*specp = spec;
+
+	return (0);
+
+fail1:
+	EFSYS_PROBE1(fail1, efx_rc_t, rc);
+	return (rc);
+}
+
+					void
+efx_mae_action_set_spec_fini(
+	__in				efx_nic_t *enp,
+	__in				efx_mae_actions_t *spec)
+{
+	EFSYS_KMEM_FREE(enp->en_esip, sizeof (*spec), spec);
+}
+
+	__checkReturn			boolean_t
+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);
+}
+
 	__checkReturn			efx_rc_t
 efx_mae_match_specs_class_cmp(
 	__in				efx_nic_t *enp,
diff --git a/drivers/common/sfc_efx/rte_common_sfc_efx_version.map b/drivers/common/sfc_efx/rte_common_sfc_efx_version.map
index aeb6f4d134..8a4d2b2fff 100644
--- a/drivers/common/sfc_efx/rte_common_sfc_efx_version.map
+++ b/drivers/common/sfc_efx/rte_common_sfc_efx_version.map
@@ -85,6 +85,9 @@  INTERNAL {
 	efx_mac_stats_upload;
 	efx_mac_up;
 
+	efx_mae_action_set_spec_fini;
+	efx_mae_action_set_spec_init;
+	efx_mae_action_set_specs_equal;
 	efx_mae_fini;
 	efx_mae_get_limits;
 	efx_mae_init;