Re: [dpdk-dev] [PATCH v1 1/1] power: add support for cppc cpufreq

[Richael Zhuang]

> -Original Message-
> From: Burakov, Anatoly 
> Sent: Friday, April 23, 2021 7:38 PM
> To: Richael Zhuang ; dev@dpdk.org
> Cc: nd ; David Hunt 
> Subject: Re: [dpdk-dev] [PATCH v1 1/1] power: add support for cppc cpufreq
> 
> On 22-Apr-21 11:02 AM, Richael Zhuang wrote:
> >
> >
> >> -Original Message-
> >> From: Burakov, Anatoly 
> >> Sent: Thursday, April 22, 2021 6:00 PM
> >> To: Richael Zhuang ; dev@dpdk.org
> >> Cc: nd ; David Hunt 
> >> Subject: Re: [dpdk-dev] [PATCH v1 1/1] power: add support for cppc
> >> cpufreq
> >>
> >> On 22-Apr-21 10:29 AM, Richael Zhuang wrote:
> >>>
> >>>
>  -Original Message-
>  From: Burakov, Anatoly 
>  Sent: Thursday, April 22, 2021 5:06 PM
>  To: Richael Zhuang ; dev@dpdk.org
>  Cc: nd ; David Hunt 
>  Subject: Re: [dpdk-dev] [PATCH v1 1/1] power: add support for cppc
>  cpufreq
> 
>  On 22-Apr-21 7:15 AM, Richael Zhuang wrote:
> > Currently in DPDK only acpi_cpufreq and pstate_cpufreq drivers are
> > supported, which are both not available on arm64 platforms. Add
> > support for cppc_cpufreq driver which works on most arm64
> platforms.
> >
> > Signed-off-by: Richael Zhuang 
> > ---
> 
>  Just a general note: this looks like a copy-paste of pstate code.
>  Which is perfectly fine, except that we can do better than copying
>  some faults of the pstate code to other drivers. I've submitted a
>  patch [1] attempting to fix some of the pressing issues and code
>  duplication in pstate driver, but i'm sure with a fresh driver, you
>  can do even better :)
> 
>  [1]
>  http://patches.dpdk.org/project/dpdk/patch/20210402092701.258316-
> 1-
>  anatoly.bura...@intel.com/
> 
>  --
>  Thanks,
>  Anatoly
> >>>
> >>> For CPPC is defined in acpi v5.0+ spec,  I reused most code in
> >>> acpi_cpufreq
> >> to get a quick workable version on our platform with only cppc
> >> driver. I have verified  its basic functions. If you find some
> >> problems please help to point out thus I can rework it. Thanks .
> >>>
> >>> Best Regards,
> >>> Richael
> >>>
> >>
> >> Well, pstate code was copied from ACPI so it does share the same flaws:
> >>
> >> - Lots of code duplication (e.g. snprintf for filename, fopen
> >> sequences,
> >> etc.)
> >> - Confusing and bug-prone error handling (e.g. return macros in the
> >> middle of a function)
> >> - Mixing power management logic and gory details of string handling
> >>
> >> Good examples of the above are in your `power_check_turbo()` function
> >> - lots of string handling code interspersed with file opens, and
> >> actual logic of power management.
> >>
> >> Please see the patch i linked earlier [1] to understand what kind of
> >> changes i'm suggesting. Perhaps you could do even better :)
> >>
> >> [1]
> >> http://patches.dpdk.org/project/dpdk/patch/20210402092701.258316-1-
> >> anatoly.bura...@intel.com/
> >>
> >> --
> >> Thanks,
> >> Anatoly
> > Thanks. I'll rework it to make it look better.
> >
> > Best Regards,
> > Richael
> >
> 
> Hi,
> 
> FYI i've updated my refactor patch [1] so that you could base your work off it
> and not have to do most of it yourself. Feel free to take over the patchset if
> you like!
> 
> [1]
> http://patches.dpdk.org/project/dpdk/patch/83b1e89d14834251d4d7e72fcc
> 19d82dfb52686d.1619175790.git.anatoly.bura...@intel.com/
> --
> Thanks,
> Anatoly

Thanks. I will rework it and reduce some duplicated code in patch v2.

Best Regards,
Richael

[dpdk-dev] [PATCH v4 0/8] baseband: add NXP LA12xx driver

[Hemant Agrawal]

This series introduces the BBDEV LA12xx poll mode driver (PMD) to support
an implementation for offloading High Phy processing functions like
LDPC Encode / Decode 5GNR wireless acceleration function, using PCI based
LA12xx Software defined radio.

Please check the documentation patch for more info.

The driver currently implements basic feature to offload only the 5G LDPC
encode/decode.

A new capability has been added to check if the driver can support the
input data in network byte order. Two test vectors are also added as an
example with input data in network byte.

v2: add test case changes
v3: fix 32 bit compilation
v4: capability for network byte order, doc patch merged inline. 

Hemant Agrawal (7):
  bbdev: add network order data capability
  baseband: introduce NXP LA12xx driver
  baseband/la12xx: add devargs for max queues
  baseband/la12xx: add support for multiple modems
  baseband/la12xx: add queue and modem config support
  baseband/la12xx: add enqueue and dequeue support
  app/bbdev: enable la12xx for bbdev

Nipun Gupta (1):
  app/bbdev: add test vectors for transport blocks

 app/test-bbdev/meson.build|3 +
 app/test-bbdev/test_vectors/ldpc_dec_tb.data  |  122 ++
 app/test-bbdev/test_vectors/ldpc_enc_tb.data  |   60 +
 doc/guides/bbdevs/features/default.ini|1 +
 doc/guides/bbdevs/features/la12xx.ini |   14 +
 doc/guides/bbdevs/index.rst   |1 +
 doc/guides/bbdevs/la12xx.rst  |  127 ++
 doc/guides/prog_guide/bbdev.rst   |6 +
 doc/guides/rel_notes/release_21_05.rst|5 +
 drivers/baseband/la12xx/bbdev_la12xx.c| 1099 +
 drivers/baseband/la12xx/bbdev_la12xx.h|   51 +
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h|  244 
 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |   26 +
 drivers/baseband/la12xx/meson.build   |6 +
 drivers/baseband/la12xx/version.map   |3 +
 drivers/baseband/meson.build  |1 +
 lib/bbdev/rte_bbdev_op.h  |8 +-
 17 files changed, 1775 insertions(+), 2 deletions(-)
 create mode 100644 app/test-bbdev/test_vectors/ldpc_dec_tb.data
 create mode 100644 app/test-bbdev/test_vectors/ldpc_enc_tb.data
 create mode 100644 doc/guides/bbdevs/features/la12xx.ini
 create mode 100644 doc/guides/bbdevs/la12xx.rst
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.c
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_ipc.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
 create mode 100644 drivers/baseband/la12xx/meson.build
 create mode 100644 drivers/baseband/la12xx/version.map

-- 
2.17.1

[dpdk-dev] [PATCH v4 1/8] bbdev: add network order data capability

[Hemant Agrawal]

This patch intoduces a new capability of the bbdev device
to process the LDPC data in network byte order.

Signed-off-by: Hemant Agrawal 
---
 doc/guides/bbdevs/features/default.ini | 1 +
 doc/guides/prog_guide/bbdev.rst| 6 ++
 lib/bbdev/rte_bbdev_op.h   | 8 ++--
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/doc/guides/bbdevs/features/default.ini 
b/doc/guides/bbdevs/features/default.ini
index 5fe267a625..e5da644099 100644
--- a/doc/guides/bbdevs/features/default.ini
+++ b/doc/guides/bbdevs/features/default.ini
@@ -14,3 +14,4 @@ LLR/HARQ Compression   =
 External DDR Access=
 HW Accelerated =
 BBDEV API  =
+Network Order Data =
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 6b2bd54e1a..89a86d10fb 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -747,6 +747,9 @@ given below.
 |RTE_BBDEV_LDPC_ENC_CONCATENATION|
 | Set if a device supports concatenation of non byte aligned output  |
 ++
+|RTE_BBDEV_LDPC_ENC_NETWORK_ORDER|
+| Set if a device supports network order data processing |
+++
 
 The structure passed for each LDPC encode operation is given below,
 with the operation flags forming a bitmask in the ``op_flags`` field.
@@ -942,6 +945,9 @@ given below.
 |RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK|
 | Set if a device supports loopback access to HARQ internal memory   |
 ++
+|RTE_BBDEV_LDPC_DEC_NETWORK_ORDER|
+| Set if a device supports network order data processing |
+++
 
 The structure passed for each LDPC decode operation is given below,
 with the operation flags forming a bitmask in the ``op_flags`` field.
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index f946842727..8fab617768 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -186,7 +186,9 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
 *  for HARQ memory. If not set, it is assumed the filler bits are not
 *  in HARQ memory and handled directly by the LDPC decoder.
 */
-   RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 18)
+   RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 18),
+   /** Set if a device supports network order data processing */
+   RTE_BBDEV_LDPC_DEC_NETWORK_ORDER = (1ULL << 19)
 };
 
 /** Flags for LDPC encoder operation and capability structure */
@@ -206,7 +208,9 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks {
/** Set if a device supports scatter-gather functionality. */
RTE_BBDEV_LDPC_ENC_SCATTER_GATHER = (1ULL << 6),
/** Set if a device supports concatenation of non byte aligned output */
-   RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7)
+   RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7),
+   /** Set if a device supports network order data processing */
+   RTE_BBDEV_LDPC_ENC_NETWORK_ORDER = (1ULL << 8)
 };
 
 /** Flags for the Code Block/Transport block mode  */
-- 
2.17.1

[dpdk-dev] [PATCH v4 2/8] baseband: introduce NXP LA12xx driver

[Hemant Agrawal]

This patch introduce the baseband device drivers for NXP's
LA1200 series software defined baseband modem.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 drivers/baseband/la12xx/bbdev_la12xx.c| 109 ++
 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |  26 +
 drivers/baseband/la12xx/meson.build   |   6 +
 drivers/baseband/la12xx/version.map   |   3 +
 drivers/baseband/meson.build  |   1 +
 5 files changed, 145 insertions(+)
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.c
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
 create mode 100644 drivers/baseband/la12xx/meson.build
 create mode 100644 drivers/baseband/la12xx/version.map

diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
new file mode 100644
index 00..7050b17728
--- /dev/null
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -0,0 +1,109 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020-2021 NXP
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME baseband_la12xx
+
+RTE_LOG_REGISTER(bbdev_la12xx_logtype, pmd.bb.la12xx, NOTICE);
+
+/* private data structure */
+struct bbdev_la12xx_private {
+   unsigned int max_nb_queues;  /**< Max number of queues */
+};
+/* Create device */
+static int
+la12xx_bbdev_create(struct rte_vdev_device *vdev)
+{
+   struct rte_bbdev *bbdev;
+   const char *name = rte_vdev_device_name(vdev);
+
+   PMD_INIT_FUNC_TRACE();
+
+   bbdev = rte_bbdev_allocate(name);
+   if (bbdev == NULL)
+   return -ENODEV;
+
+   bbdev->data->dev_private = rte_zmalloc(name,
+   sizeof(struct bbdev_la12xx_private),
+   RTE_CACHE_LINE_SIZE);
+   if (bbdev->data->dev_private == NULL) {
+   rte_bbdev_release(bbdev);
+   return -ENOMEM;
+   }
+
+   bbdev->dev_ops = NULL;
+   bbdev->device = &vdev->device;
+   bbdev->data->socket_id = 0;
+   bbdev->intr_handle = NULL;
+
+   /* register rx/tx burst functions for data path */
+   bbdev->dequeue_enc_ops = NULL;
+   bbdev->dequeue_dec_ops = NULL;
+   bbdev->enqueue_enc_ops = NULL;
+   bbdev->enqueue_dec_ops = NULL;
+
+   return 0;
+}
+
+/* Initialise device */
+static int
+la12xx_bbdev_probe(struct rte_vdev_device *vdev)
+{
+   const char *name;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (vdev == NULL)
+   return -EINVAL;
+
+   name = rte_vdev_device_name(vdev);
+   if (name == NULL)
+   return -EINVAL;
+
+   return la12xx_bbdev_create(vdev);
+}
+
+/* Uninitialise device */
+static int
+la12xx_bbdev_remove(struct rte_vdev_device *vdev)
+{
+   struct rte_bbdev *bbdev;
+   const char *name;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (vdev == NULL)
+   return -EINVAL;
+
+   name = rte_vdev_device_name(vdev);
+   if (name == NULL)
+   return -EINVAL;
+
+   bbdev = rte_bbdev_get_named_dev(name);
+   if (bbdev == NULL)
+   return -EINVAL;
+
+   rte_free(bbdev->data->dev_private);
+
+   return rte_bbdev_release(bbdev);
+}
+
+static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
+   .probe = la12xx_bbdev_probe,
+   .remove = la12xx_bbdev_remove
+};
+
+RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
diff --git a/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h 
b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
new file mode 100644
index 00..9dfa1cc458
--- /dev/null
+++ b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 NXP
+ */
+
+#ifndef _BBDEV_LA12XX_PMD_LOGS_H_
+#define _BBDEV_LA12XX_PMD_LOGS_H_
+
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, bbdev_la12xx_logtype, fmt "\n", \
+   ##__VA_ARGS__)
+
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, "la12xx_pmd: " fmt, \
+   ##__VA_ARGS__)
+#else
+#define rte_bbdev_log_debug(fmt, ...)
+#endif
+
+#define PMD_INIT_FUNC_TRACE() rte_bbdev_log_debug(">>")
+
+/* DP Logs, toggled out at compile time if level lower than current level */
+#define rte_bbdev_dp_log(level, fmt, args...) \
+   RTE_LOG_DP(level, PMD, fmt, ## args)
+
+#endif /* _BBDEV_LA12XX_PMD_LOGS_H_ */
diff --git a/drivers/baseband/la12xx/meson.build 
b/drivers/baseband/la12xx/meson.build
new file mode 100644
index 00..7a017dcffa
--- /dev/null
+++ b/drivers/baseband/la12xx/meson.build
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2020-2021 NXP
+
+deps += ['bbdev', 'bus_vdev', 'ring']
+
+sources = files('bbdev_la12xx.c')
diff --git a/drivers/baseband/la12xx/version.map 
b/drivers/baseband/la12xx/version.map
new file mode 100644
index 00..4a76d1d52d

[dpdk-dev] [PATCH v4 3/8] baseband/la12xx: add devargs for max queues

[Hemant Agrawal]

This patch adds dev args to take  max queues as input

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 drivers/baseband/la12xx/bbdev_la12xx.c | 72 +-
 1 file changed, 70 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 7050b17728..8886b35429 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -19,13 +19,72 @@
 
 RTE_LOG_REGISTER(bbdev_la12xx_logtype, pmd.bb.la12xx, NOTICE);
 
+/*  Initialisation params structure that can be used by LA12xx BBDEV driver */
+struct bbdev_la12xx_params {
+   uint8_t queues_num; /*< LA12xx BBDEV queues number */
+};
+
+#define LA12XX_MAX_NB_QUEUES_ARG   "max_nb_queues"
+
+static const char * const bbdev_la12xx_valid_params[] = {
+   LA12XX_MAX_NB_QUEUES_ARG,
+};
+
 /* private data structure */
 struct bbdev_la12xx_private {
unsigned int max_nb_queues;  /**< Max number of queues */
 };
+static inline int
+parse_u16_arg(const char *key, const char *value, void *extra_args)
+{
+   uint16_t *u16 = extra_args;
+
+   unsigned int long result;
+   if ((value == NULL) || (extra_args == NULL))
+   return -EINVAL;
+   errno = 0;
+   result = strtoul(value, NULL, 0);
+   if ((result >= (1 << 16)) || (errno != 0)) {
+   rte_bbdev_log(ERR, "Invalid value %lu for %s", result, key);
+   return -ERANGE;
+   }
+   *u16 = (uint16_t)result;
+   return 0;
+}
+
+/* Parse parameters used to create device */
+static int
+parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
+   const char *input_args)
+{
+   struct rte_kvargs *kvlist = NULL;
+   int ret = 0;
+
+   if (params == NULL)
+   return -EINVAL;
+   if (input_args) {
+   kvlist = rte_kvargs_parse(input_args,
+   bbdev_la12xx_valid_params);
+   if (kvlist == NULL)
+   return -EFAULT;
+
+   ret = rte_kvargs_process(kvlist, bbdev_la12xx_valid_params[0],
+   &parse_u16_arg, ¶ms->queues_num);
+   if (ret < 0)
+   goto exit;
+
+   }
+
+exit:
+   if (kvlist)
+   rte_kvargs_free(kvlist);
+   return ret;
+}
+
 /* Create device */
 static int
-la12xx_bbdev_create(struct rte_vdev_device *vdev)
+la12xx_bbdev_create(struct rte_vdev_device *vdev,
+   struct bbdev_la12xx_params *init_params __rte_unused)
 {
struct rte_bbdev *bbdev;
const char *name = rte_vdev_device_name(vdev);
@@ -62,7 +121,11 @@ la12xx_bbdev_create(struct rte_vdev_device *vdev)
 static int
 la12xx_bbdev_probe(struct rte_vdev_device *vdev)
 {
+   struct bbdev_la12xx_params init_params = {
+   8
+   };
const char *name;
+   const char *input_args;
 
PMD_INIT_FUNC_TRACE();
 
@@ -73,7 +136,10 @@ la12xx_bbdev_probe(struct rte_vdev_device *vdev)
if (name == NULL)
return -EINVAL;
 
-   return la12xx_bbdev_create(vdev);
+   input_args = rte_vdev_device_args(vdev);
+   parse_bbdev_la12xx_params(&init_params, input_args);
+
+   return la12xx_bbdev_create(vdev, &init_params);
 }
 
 /* Uninitialise device */
@@ -107,3 +173,5 @@ static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
 };
 
 RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
+RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
+   LA12XX_MAX_NB_QUEUES_ARG"=");
-- 
2.17.1

[dpdk-dev] [PATCH v4 4/8] baseband/la12xx: add support for multiple modems

[Hemant Agrawal]

This patch add support for multiple modems by assigning
a modem id as dev args in vdev creation.

Signed-off-by: Hemant Agrawal 
---
 drivers/baseband/la12xx/bbdev_la12xx.c | 64 +++---
 drivers/baseband/la12xx/bbdev_la12xx.h | 56 +++
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h | 20 +++
 3 files changed, 133 insertions(+), 7 deletions(-)
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_ipc.h

diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 8886b35429..f26f3f2a08 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -14,6 +14,8 @@
 #include 
 
 #include 
+#include 
+#include 
 
 #define DRIVER_NAME baseband_la12xx
 
@@ -22,18 +24,18 @@ RTE_LOG_REGISTER(bbdev_la12xx_logtype, pmd.bb.la12xx, 
NOTICE);
 /*  Initialisation params structure that can be used by LA12xx BBDEV driver */
 struct bbdev_la12xx_params {
uint8_t queues_num; /*< LA12xx BBDEV queues number */
+   int8_t modem_id; /*< LA12xx modem instance id */
 };
 
 #define LA12XX_MAX_NB_QUEUES_ARG   "max_nb_queues"
+#define LA12XX_VDEV_MODEM_ID_ARG   "modem"
+#define LA12XX_MAX_MODEM 4
 
 static const char * const bbdev_la12xx_valid_params[] = {
LA12XX_MAX_NB_QUEUES_ARG,
+   LA12XX_VDEV_MODEM_ID_ARG,
 };
 
-/* private data structure */
-struct bbdev_la12xx_private {
-   unsigned int max_nb_queues;  /**< Max number of queues */
-};
 static inline int
 parse_u16_arg(const char *key, const char *value, void *extra_args)
 {
@@ -52,6 +54,28 @@ parse_u16_arg(const char *key, const char *value, void 
*extra_args)
return 0;
 }
 
+/* Parse integer from integer argument */
+static int
+parse_integer_arg(const char *key __rte_unused,
+   const char *value, void *extra_args)
+{
+   int i;
+   char *end;
+
+   errno = 0;
+
+   i = strtol(value, &end, 10);
+   if (*end != 0 || errno != 0 || i < 0 || i > LA12XX_MAX_MODEM) {
+   rte_bbdev_log(ERR, "Supported Port IDS are 0 to %d",
+   LA12XX_MAX_MODEM - 1);
+   return -EINVAL;
+   }
+
+   *((uint32_t *)extra_args) = i;
+
+   return 0;
+}
+
 /* Parse parameters used to create device */
 static int
 parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
@@ -73,6 +97,16 @@ parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
if (ret < 0)
goto exit;
 
+   ret = rte_kvargs_process(kvlist,
+   bbdev_la12xx_valid_params[1],
+   &parse_integer_arg,
+   ¶ms->modem_id);
+
+   if (params->modem_id >= LA12XX_MAX_MODEM) {
+   rte_bbdev_log(ERR, "Invalid modem id, must be < %u",
+   LA12XX_MAX_MODEM);
+   goto exit;
+   }
}
 
 exit:
@@ -84,10 +118,11 @@ parse_bbdev_la12xx_params(struct bbdev_la12xx_params 
*params,
 /* Create device */
 static int
 la12xx_bbdev_create(struct rte_vdev_device *vdev,
-   struct bbdev_la12xx_params *init_params __rte_unused)
+   struct bbdev_la12xx_params *init_params)
 {
struct rte_bbdev *bbdev;
const char *name = rte_vdev_device_name(vdev);
+   struct bbdev_la12xx_private *priv;
 
PMD_INIT_FUNC_TRACE();
 
@@ -103,6 +138,20 @@ la12xx_bbdev_create(struct rte_vdev_device *vdev,
return -ENOMEM;
}
 
+   priv = bbdev->data->dev_private;
+   priv->modem_id = init_params->modem_id;
+   /* if modem id is not configured */
+   if (priv->modem_id == -1)
+   priv->modem_id = bbdev->data->dev_id;
+
+   /* Reset Global variables */
+   priv->num_ldpc_enc_queues = 0;
+   priv->num_ldpc_dec_queues = 0;
+   priv->num_valid_queues = 0;
+   priv->max_nb_queues = init_params->queues_num;
+
+   rte_bbdev_log(INFO, "Setting Up %s: DevId=%d, ModemId=%d",
+   name, bbdev->data->dev_id, priv->modem_id);
bbdev->dev_ops = NULL;
bbdev->device = &vdev->device;
bbdev->data->socket_id = 0;
@@ -122,7 +171,7 @@ static int
 la12xx_bbdev_probe(struct rte_vdev_device *vdev)
 {
struct bbdev_la12xx_params init_params = {
-   8
+   8, -1,
};
const char *name;
const char *input_args;
@@ -174,4 +223,5 @@ static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
 
 RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
 RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
-   LA12XX_MAX_NB_QUEUES_ARG"=");
+   LA12XX_MAX_NB_QUEUES_ARG"="
+   LA12XX_VDEV_MODEM_ID_ARG "= ");
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.h 
b/drivers/baseband/la12xx/bbdev_la12xx.h
new file mode 100644
index 000

[dpdk-dev] [PATCH v4 5/8] baseband/la12xx: add queue and modem config support

[Hemant Agrawal]

This patch add support for connecting with modem
and creating the ipc channel as queues with modem
for the exchange of data.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 doc/guides/bbdevs/index.rst|   1 +
 doc/guides/bbdevs/la12xx.rst   |  81 +++
 doc/guides/rel_notes/release_21_05.rst |   5 +
 drivers/baseband/la12xx/bbdev_la12xx.c | 552 -
 drivers/baseband/la12xx/bbdev_la12xx.h |  11 +-
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h | 189 ++-
 6 files changed, 829 insertions(+), 10 deletions(-)
 create mode 100644 doc/guides/bbdevs/la12xx.rst

diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
index 4445cbd1b0..cedd706fa6 100644
--- a/doc/guides/bbdevs/index.rst
+++ b/doc/guides/bbdevs/index.rst
@@ -14,3 +14,4 @@ Baseband Device Drivers
 fpga_lte_fec
 fpga_5gnr_fec
 acc100
+la12xx
diff --git a/doc/guides/bbdevs/la12xx.rst b/doc/guides/bbdevs/la12xx.rst
new file mode 100644
index 00..3c9ac5c047
--- /dev/null
+++ b/doc/guides/bbdevs/la12xx.rst
@@ -0,0 +1,81 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2021 NXP
+
+NXP LA12xx Poll Mode Driver
+===
+
+The BBDEV LA12xx poll mode driver (PMD) supports an implementation for
+offloading High Phy processing functions like LDPC Encode / Decode 5GNR 
wireless
+acceleration function, using PCI based LA12xx Software defined radio.
+
+More information can be found at `NXP Official Website
+`_.
+
+Features
+
+
+LA12xx PMD supports the following features:
+
+- Maximum of 8 UL queues
+- Maximum of 8 DL queues
+- PCIe Gen-3 x8 Interface
+- MSI-X
+
+Installation
+
+
+Section 3 of the DPDK manual provides instructions on installing and compiling 
DPDK.
+
+DPDK requires hugepages to be configured as detailed in section 2 of the DPDK 
manual.
+
+Initialization
+--
+
+The device can be listed on the host console with:
+
+
+Use the following lspci command to get the multiple LA12xx processor ids. The
+device ID of the LA12xx baseband processor is "1c30".
+
+.. code-block:: console
+
+  sudo lspci -nn
+
+...
+0001:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device [1957:1c30] (
+rev 10)
+...
+0002:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device [1957:1c30] (
+rev 10)
+
+
+Prerequisites
+-
+
+Currently supported by DPDK:
+
+- NXP LA1224 BSP **1.0+**.
+- NXP LA1224 PCIe Modem card connected to ARM host.
+
+- Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
+
+* Use dev arg option ``modem=0`` to identify the modem instance for a given
+  device. This is required only if more than 1 modem cards are attached to 
host.
+  this is optional and the default value is 0.
+  e.g. ``--vdev=baseband_la12xx,modem=0``
+
+* Use dev arg option ``max_nb_queues=x`` to specify the maximum number of 
queues
+  to be used for communication with offload device i.e. modem. default is 16.
+  e.g. ``--vdev=baseband_la12xx,max_nb_queues=4``
+
+Enabling logs
+-
+
+For enabling logs, use the following EAL parameter:
+
+.. code-block:: console
+
+   ./your_bbdev_application  --log-level=la12xx:
+
+Using ``bb.la12xx`` as log matching criteria, all Baseband PMD logs can be
+enabled which are lower than logging ``level``.
diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index b3224dc332..4e0b62debb 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -236,6 +236,11 @@ New Features
   the hash function used in NICs to spread the traffic among the queues.
   It can be used to get predictable mapping of the flows.
 
+* **Added NXP LA12xx baseband PMD.**
+
+  * Added a new baseband PMD driver for NXP LA12xx Software defined radio.
+  * See the :doc:`../bbdevs/la12xx` for more details.
+
 * **Updated testpmd.**
 
   * Added a command line option to configure forced speed for Ethernet port.
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index f26f3f2a08..1fdeca279e 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -3,6 +3,11 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -31,11 +36,549 @@ struct bbdev_la12xx_params {
 #define LA12XX_VDEV_MODEM_ID_ARG   "modem"
 #define LA12XX_MAX_MODEM 4
 
+#define LA12XX_MAX_CORES   4
+#define LA12XX_LDPC_ENC_CORE   0
+#define LA12XX_LDPC_DEC_CORE   1
+
+#define LA12XX_MAX_LDPC_ENC_QUEUES 4
+#define LA12XX_MAX_LDPC_DEC_QUEUES 4
+
 static const char * const bbdev_la12xx_valid_params[] = {
LA12XX_MAX_NB_QUEUES_ARG,
LA12XX_VDEV_MODEM_ID_ARG,
 };
 
+static const s

[dpdk-dev] [PATCH v4 6/8] baseband/la12xx: add enqueue and dequeue support

[Hemant Agrawal]

Add support for enqueue and dequeue the LDPC enc/dec
from the modem device.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 doc/guides/bbdevs/features/la12xx.ini  |  14 +
 doc/guides/bbdevs/la12xx.rst   |  46 +++
 drivers/baseband/la12xx/bbdev_la12xx.c | 334 -
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h |  37 +++
 4 files changed, 425 insertions(+), 6 deletions(-)
 create mode 100644 doc/guides/bbdevs/features/la12xx.ini

diff --git a/doc/guides/bbdevs/features/la12xx.ini 
b/doc/guides/bbdevs/features/la12xx.ini
new file mode 100644
index 00..d184914b10
--- /dev/null
+++ b/doc/guides/bbdevs/features/la12xx.ini
@@ -0,0 +1,14 @@
+;
+; Supported features of the 'la12xx' bbdev driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Turbo Decoder (4G) = N
+Turbo Encoder (4G) = N
+LDPC Decoder (5G)  = Y
+LDPC Encoder (5G)  = Y
+LLR/HARQ Compression   = N
+HW Accelerated = Y
+BBDEV API  = Y
+Network Order Data = Y
\ No newline at end of file
diff --git a/doc/guides/bbdevs/la12xx.rst b/doc/guides/bbdevs/la12xx.rst
index 3c9ac5c047..c39be0e51f 100644
--- a/doc/guides/bbdevs/la12xx.rst
+++ b/doc/guides/bbdevs/la12xx.rst
@@ -16,6 +16,8 @@ Features
 
 LA12xx PMD supports the following features:
 
+- LDPC Encode in the DL
+- LDPC Decode in the UL
 - Maximum of 8 UL queues
 - Maximum of 8 DL queues
 - PCIe Gen-3 x8 Interface
@@ -79,3 +81,47 @@ For enabling logs, use the following EAL parameter:
 
 Using ``bb.la12xx`` as log matching criteria, all Baseband PMD logs can be
 enabled which are lower than logging ``level``.
+
+Test Application
+
+
+BBDEV provides a test application, ``test-bbdev.py`` and range of test data 
for testing
+the functionality of LA12xx for FEC encode and decode, depending on the device
+capabilities. The test application is located under app->test-bbdev folder and 
has the
+following options:
+
+.. code-block:: console
+
+  "-p", "--testapp-path": specifies path to the bbdev test app.
+  "-e", "--eal-params" : EAL arguments which are passed to the test app.
+  "-t", "--timeout": Timeout in seconds (default=300).
+  "-c", "--test-cases" : Defines test cases to run. Run all if not specified.
+  "-v", "--test-vector": Test vector path 
(default=dpdk_path+/app/test-bbdev/test_vectors/bbdev_null.data).
+  "-n", "--num-ops": Number of operations to process on device 
(default=32).
+  "-b", "--burst-size" : Operations enqueue/dequeue burst size (default=32).
+  "-s", "--snr": SNR in dB used when generating LLRs for bler 
tests.
+  "-s", "--iter_max"   : Number of iterations for LDPC decoder.
+  "-l", "--num-lcores" : Number of lcores to run (default=16).
+  "-i", "--init-device" : Initialise PF device with default values.
+
+
+To execute the test application tool using simple decode or encode data,
+type one of the following:
+
+.. code-block:: console
+
+  ./test-bbdev.py -e="--vdev=baseband_la12xx,socket_id=0,max_nb_queues=8" -c 
validation -n 64 -b 1 -v ./ldpc_dec_default.data
+  ./test-bbdev.py -e="--vdev=baseband_la12xx,socket_id=0,max_nb_queues=8" -c 
validation -n 64 -b 1 -v ./ldpc_enc_default.data
+
+The test application ``test-bbdev.py``, supports the ability to configure the 
PF device with
+a default set of values, if the "-i" or "- -init-device" option is included. 
The default values
+are defined in test_bbdev_perf.c.
+
+
+Test Vectors
+
+
+In addition to the simple LDPC decoder and LDPC encoder tests, bbdev also 
provides
+a range of additional tests under the test_vectors folder, which may be 
useful. The results
+of these tests will depend on the LA12xx FEC capabilities which may cause some
+testcases to be skipped, but no failure should be reported.
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 1fdeca279e..50e3284622 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -54,7 +54,8 @@ static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
.cap.ldpc_enc = {
.capability_flags =
RTE_BBDEV_LDPC_CRC_24A_ATTACH |
-   RTE_BBDEV_LDPC_CRC_24B_ATTACH,
+   RTE_BBDEV_LDPC_CRC_24B_ATTACH |
+   RTE_BBDEV_LDPC_ENC_NETWORK_ORDER,
.num_buffers_src =
RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
.num_buffers_dst =
@@ -68,7 +69,8 @@ static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
RTE_BBDEV_LDPC_LLR_COMPRESSION |
RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
-   RTE_

[dpdk-dev] [PATCH v4 7/8] app/bbdev: enable la12xx for bbdev

[Hemant Agrawal]

this patch adds la12xx driver in test bbdev

Signed-off-by: Hemant Agrawal 
---
 app/test-bbdev/meson.build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
index 57335641f0..75fd87ae2d 100644
--- a/app/test-bbdev/meson.build
+++ b/app/test-bbdev/meson.build
@@ -17,3 +17,6 @@ endif
 if dpdk_conf.has('RTE_BASEBAND_ACC100')
 deps += ['baseband_acc100']
 endif
+if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_LA12XX')
+   deps += ['baseband_la12xx']
+endif
-- 
2.17.1

[dpdk-dev] [PATCH v4 8/8] app/bbdev: add test vectors for transport blocks

[Hemant Agrawal]

From: Nipun Gupta 

This patch adds two test vectors for transport block in network byte
order:
- LDPC encode for Transport Block
- LDPC decode for Transport block

Signed-off-by: Nipun Gupta 
---
 app/test-bbdev/test_vectors/ldpc_dec_tb.data | 122 +++
 app/test-bbdev/test_vectors/ldpc_enc_tb.data |  60 +
 2 files changed, 182 insertions(+)
 create mode 100644 app/test-bbdev/test_vectors/ldpc_dec_tb.data
 create mode 100644 app/test-bbdev/test_vectors/ldpc_enc_tb.data

diff --git a/app/test-bbdev/test_vectors/ldpc_dec_tb.data 
b/app/test-bbdev/test_vectors/ldpc_dec_tb.data
new file mode 100644
index 00..4ec5020d04
--- /dev/null
+++ b/app/test-bbdev/test_vectors/ldpc_dec_tb.data
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2020 NXP
+
+op_type =
+RTE_BBDEV_OP_LDPC_DEC
+
+input0 =
+0x817f8181, 0x7f7f8181, 0x817f7f81, 0x81817f81, 0x81817f81, 0x817f7f81, 
0x7f7f7f7f, 0x7f7f7f81,
+0x817f7f81, 0x817f7f81, 0x7f7f817f, 0x7f7f7f81, 0x81817f7f, 0x81818181, 
0x817f8181, 0x7f817f81,
+0x81817f7f, 0x7f7f817f, 0x81817f81, 0x817f8181, 0x7f7f7f81, 0x817f817f, 
0x7f817f7f, 0x7f817f7f,
+0x7f817f7f, 0x81817f7f, 0x7f818181, 0x817f7f7f, 0x8181817f, 0x81817f7f, 
0x7f817f81, 0x7f7f7f7f,
+0x7f817f7f, 0x81817f7f, 0x81818181, 0x817f817f, 0x81817f7f, 0x7f81817f, 
0x7f7f7f7f, 0x7f7f7f7f,
+0x7f818181, 0x7f7f7f81, 0x81817f81, 0x7f817f7f, 0x7f7f7f7f, 0x817f817f, 
0x817f817f, 0x7f7f817f,
+0x81817f81, 0x7f7f7f7f, 0x7f81817f, 0x817f817f, 0x7f7f8181, 0x7f7f7f7f, 
0x817f7f7f, 0x81818181,
+0x817f8181, 0x7f7f817f, 0x7f7f8181, 0x7f7f7f7f, 0x7f818181, 0x817f8181, 
0x817f7f81, 0x817f8181,
+0x817f7f81, 0x81817f7f, 0x7f7f8181, 0x81818181, 0x817f817f, 0x817f7f7f, 
0x81818181, 0x7f817f81,
+0x7f7f7f81, 0x81817f81, 0x7f817f7f, 0x7f818181, 0x7f7f7f81, 0x817f817f, 
0x81818181, 0x81818181,
+0x81817f81, 0x81817f81, 0x7f7f8181, 0x817f7f7f, 0x7f81817f, 0x817f817f, 
0x81817f7f, 0x817f7f81,
+0x81817f7f, 0x7f7f7f81, 0x7f817f81, 0x7f817f81, 0x817f7f7f, 0x7f818181, 
0x81818181, 0x7f7f7f7f,
+0x7f7f7f7f, 0x8181817f, 0x7f7f7f81, 0x7f817f81, 0x81817f81, 0x7f7f817f, 
0x7f81817f, 0x817f8181,
+0x7f81817f, 0x7f81817f, 0x817f7f7f, 0x7f81817f, 0x817f7f81, 0x817f7f81, 
0x7f817f7f, 0x8181817f,
+0x7f81817f, 0x7f7f8181, 0x817f8181, 0x817f7f7f, 0x817f7f81, 0x7f81817f, 
0x7f7f817f, 0x7f817f7f,
+0x7f7f8181, 0x81818181, 0x7f818181, 0x7f7f817f, 0x7f818181, 0x81818181, 
0x7f817f7f, 0x817f817f,
+0x817f817f, 0x817f7f7f, 0x81817f81, 0x81817f7f, 0x81817f81, 0x7f817f81, 
0x7f817f7f, 0x7f817f7f,
+0x817f7f7f, 0x817f7f7f, 0x7f7f7f7f, 0x7f7f7f81, 0x7f7f8181, 0x7f817f81, 
0x7f817f7f, 0x817f7f7f,
+0x7f7f8181, 0x8181817f, 0x7f7f8181, 0x7f7f7f81, 0x817f7f7f, 0x7f7f7f81, 
0x817f8181, 0x7f7f817f,
+0x7f81817f, 0x817f817f, 0x7f817f81, 0x7f7f8181, 0x7f818181, 0x7f817f81, 
0x81818181, 0x81817f7f,
+0x7f81817f, 0x7f81817f, 0x7f7f8181, 0x81818181, 0x817f8181, 0x7f7f817f, 
0x7f817f7f, 0x7f7f8181,
+0x7f81817f, 0x7f7f817f, 0x7f7f7f7f, 0x7f818181, 0x81817f7f, 0x8181817f, 
0x7f81817f, 0x8181817f,
+0x81817f81, 0x7f7f7f7f, 0x81818181, 0x7f7f817f, 0x7f81817f, 0x7f7f7f7f, 
0x81817f81, 0x817f7f81,
+0x817f7f81, 0x817f7f81, 0x81818181, 0x7f7f7f7f, 0x81817f81, 0x817f7f7f, 
0x8181817f, 0x7f7f7f81,
+0x81817f81, 0x817f7f81, 0x81818181, 0x7f7f7f7f, 0x81817f7f, 0x81817f81, 
0x7f7f7f81, 0x7f7f7f7f,
+0x817f817f, 0x7f818181, 0x8181817f, 0x81817f81, 0x7f7f7f81, 0x7f817f7f, 
0x7f7f7f7f, 0x7f817f81,
+0x8181817f, 0x7f7f7f7f, 0x81817f7f, 0x7f7f7f81, 0x7f81817f, 0x7f7f7f7f, 
0x7f7f7f81, 0x817f8181,
+0x7f7f8181, 0x7f7f7f81, 0x7f7f8181, 0x7f817f7f, 0x81818181, 0x7f81817f, 
0x7f818181, 0x7f818181,
+0x7f818181, 0x817f7f81, 0x7f7f8181, 0x81818181, 0x7f7f7f7f, 0x7f7f7f7f, 
0x817f8181, 0x81818181,
+0x7f7f817f, 0x817f8181, 0x81817f7f, 0x817f817f, 0x7f7f817f, 0x7f7f7f7f, 
0x817f8181, 0x817f8181,
+0x817f8181, 0x81818181, 0x7f7f817f, 0x7f817f81, 0x817f7f81, 0x7f7f7f81, 
0x81817f81, 0x7f818181,
+0x81817f7f, 0x7f818181, 0x81818181, 0x817f817f, 0x7f817f7f, 0x81818181, 
0x817f8181, 0x7f7f7f7f,
+0x7f817f81, 0x817f7f7f, 0x7f818181, 0x8181817f, 0x817f817f, 0x7f817f7f, 
0x817f7f81, 0x7f818181,
+0x817f7f7f, 0x817f7f81, 0x7f7f7f81, 0x81817f81, 0x7f81817f, 0x7f818181, 
0x81817f7f, 0x817f7f81,
+0x81817f81, 0x7f7f8181, 0x7f7f8181, 0x7f817f81, 0x7f7f817f, 0x817f7f7f, 
0x7f7f7f7f, 0x817f7f7f,
+0x7f7f8181, 0x817f8181, 0x817f8181, 0x7f817f81, 0x817f8181, 0x8181817f, 
0x81817f7f, 0x7f817f7f,
+0x7f817f7f, 0x7f817f81, 0x817f817f, 0x817f7f7f, 0x8181817f, 0x817f817f, 
0x817f7f81, 0x81817f7f,
+0x7f817f7f, 0x7f7f7f7f, 0x7f817f7f, 0x7f7f817f, 0x7f818181, 0x8181817f, 
0x817f7f7f, 0x7f817f81,
+0x7f7f8181, 0x81817f7f, 0x7f7f817f, 0x7f7f817f, 0x7f817f7f, 0x7f7f817f, 
0x7f818181, 0x7f817f7f,
+0x817f7f7f, 0x7f817f81, 0x81818181, 0x7f818181, 0x817f8181, 0x8181817f, 
0x8181817f, 0x817f7f7f,
+0x81817f81, 0x817f7f7f, 0x7f81817f, 0x817f8181, 0x7f818181, 0x7f817f7f, 
0x81817f7f, 0x7f81817f,
+0x81817f81, 0x7f7f7f81, 0x7f7f7f7f, 0x81818181, 0x817f7f7f, 0x81817f81, 
0x817f7f81, 0x81817f7f,
+0x81818181, 0x7f7f7f7f, 0x817f817f

Re: [dpdk-dev] [PATCH v4 1/8] bbdev: add network order data capability

[Chautru, Nicolas]

+ Thomas, Akhil

In case this is for release 21.05 isn't it a bit late for introducing a new API 
change?


> -Original Message-
> From: Hemant Agrawal 
> Sent: Saturday, April 24, 2021 3:37 AM
> To: dev@dpdk.org; gak...@marvell.com; Chautru, Nicolas
> 
> Cc: david.march...@redhat.com; Hemant Agrawal
> 
> Subject: [PATCH v4 1/8] bbdev: add network order data capability
> 
> This patch intoduces a new capability of the bbdev device to process the
> LDPC data in network byte order.
> 
> Signed-off-by: Hemant Agrawal 
> ---
>  doc/guides/bbdevs/features/default.ini | 1 +
>  doc/guides/prog_guide/bbdev.rst| 6 ++
>  lib/bbdev/rte_bbdev_op.h   | 8 ++--
>  3 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/guides/bbdevs/features/default.ini
> b/doc/guides/bbdevs/features/default.ini
> index 5fe267a625..e5da644099 100644
> --- a/doc/guides/bbdevs/features/default.ini
> +++ b/doc/guides/bbdevs/features/default.ini
> @@ -14,3 +14,4 @@ LLR/HARQ Compression   =
>  External DDR Access=
>  HW Accelerated =
>  BBDEV API  =
> +Network Order Data =
> diff --git a/doc/guides/prog_guide/bbdev.rst
> b/doc/guides/prog_guide/bbdev.rst index 6b2bd54e1a..89a86d10fb 100644
> --- a/doc/guides/prog_guide/bbdev.rst
> +++ b/doc/guides/prog_guide/bbdev.rst
> @@ -747,6 +747,9 @@ given below.
>  |RTE_BBDEV_LDPC_ENC_CONCATENATION|
>  | Set if a device supports concatenation of non byte aligned output  |  
> +--
> --+
> +|RTE_BBDEV_LDPC_ENC_NETWORK_ORDER|
> +| Set if a device supports network order data processing |
> +++

I don't believe this is an extra capability extension per se here, but actually 
a different assumption. Tell me if I misinterpret the intent of your serie. 
>From looking at the PMD I assume that you may mean " Set when a device 
>`requires` network order data processing"
Basically the distinction I am trying to highlight is that it depends whether 
we want to expose this as an incremental dynamic operation flag that you can 
set at run time (enqueue ...), or whether this is more of distinct assumption 
that may be different for each PMD (either one of the other). 
I assume this is the later, please confirm. Ie I assume that your PMD would not 
be able to process the data in case this is presented with other endianness (ie 
you don't check ever that flag in the op_flag in your driver), in that case 
your driver would fail many existing unit test if considered as an additional 
capability on top of default one. You probably see such failures if you have 
tried to run the regression which would confirm the issue. 
In that case we may want discuss whether this is not actually more something to 
be capture under `struct rte_bbdev_driver_info` as a bool endianness. Both 
arguably may work but later arguably closer to the suggested intent and less 
convoluted.  Worth discussing further/
But basically if as this under that structure that would be exposed the same 
way as different LLR numerical assumption and that can be handled gracefulyl in 
the application/bbdev-test. 
+ Tom Rix, Dave Burley 


> 
>  The structure passed for each LDPC encode operation is given below,  with
> the operation flags forming a bitmask in the ``op_flags`` field.
> @@ -942,6 +945,9 @@ given below.
>  |RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK|
>  | Set if a device supports loopback access to HARQ internal memory   |
>  ++
> +|RTE_BBDEV_LDPC_DEC_NETWORK_ORDER|
> +| Set if a device supports network order data processing |
> +++
> 
>  The structure passed for each LDPC decode operation is given below,  with
> the operation flags forming a bitmask in the ``op_flags`` field.
> diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h index
> f946842727..8fab617768 100644
> --- a/lib/bbdev/rte_bbdev_op.h
> +++ b/lib/bbdev/rte_bbdev_op.h
> @@ -186,7 +186,9 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
>*  for HARQ memory. If not set, it is assumed the filler bits are not
>*  in HARQ memory and handled directly by the LDPC decoder.
>*/
> - RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL <<
> 18)
> + RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL <<
> 18),
> + /** Set if a device supports network order data processing */
> + RTE_BBDEV_LDPC_DEC_NETWORK_ORDER = (1ULL << 19)
>  };
> 
>  /** Flags for LDPC encoder operation and capability structure */ @@ -206,7
> +208,9 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks {
>   /** Set if a device supports scatter-gather functionality. */
>   RTE_BBDEV_LDPC

Re: [dpdk-dev] [PATCH v4 8/8] app/bbdev: add test vectors for transport blocks

[Chautru, Nicolas]

> -Original Message-
> From: Hemant Agrawal 
> Sent: Saturday, April 24, 2021 3:37 AM
> 
> From: Nipun Gupta 
> 
> This patch adds two test vectors for transport block in network byte
> order:
> - LDPC encode for Transport Block
> - LDPC decode for Transport block
> 
> Signed-off-by: Nipun Gupta 
> ---

See related comment on patch 1. 
Assuming this is a different PMD assumption (not an incremental one) then this 
should not require new vectors with the op_flag  
RTE_BBDEV_LDPC_ENC_NETWORK_ORDER. 
These would artificially create non-compatible vectors for no reason.
But all existing vectors should be able to run on any PMD, the test framework 
will just change order endianness based on what is supported by the device so 
that all unit test can be run successfully on any PMD. See how it is done for 
LLR numerical assumptions which can differ between PMDs. 
Let me know if unclear

>  app/test-bbdev/test_vectors/ldpc_dec_tb.data | 122
> +++  app/test-bbdev/test_vectors/ldpc_enc_tb.data |
> 60 +
>  2 files changed, 182 insertions(+)
>  create mode 100644 app/test-bbdev/test_vectors/ldpc_dec_tb.data
>  create mode 100644 app/test-bbdev/test_vectors/ldpc_enc_tb.data
> 
> diff --git a/app/test-bbdev/test_vectors/ldpc_dec_tb.data b/app/test-
> bbdev/test_vectors/ldpc_dec_tb.data
> new file mode 100644
> index 00..4ec5020d04
> --- /dev/null
> +++ b/app/test-bbdev/test_vectors/ldpc_dec_tb.data
> @@ -0,0 +1,122 @@
> +# SPDX-License-Identifier: BSD-3-Clause # Copyright 2020 NXP
> +
> +op_type =
> +RTE_BBDEV_OP_LDPC_DEC
> +
> +input0 =
> +0x817f8181, 0x7f7f8181, 0x817f7f81, 0x81817f81, 0x81817f81, 0x817f7f81,
> +0x7f7f7f7f, 0x7f7f7f81, 0x817f7f81, 0x817f7f81, 0x7f7f817f, 0x7f7f7f81,
> +0x81817f7f, 0x81818181, 0x817f8181, 0x7f817f81, 0x81817f7f, 0x7f7f817f,
> +0x81817f81, 0x817f8181, 0x7f7f7f81, 0x817f817f, 0x7f817f7f, 0x7f817f7f,
> +0x7f817f7f, 0x81817f7f, 0x7f818181, 0x817f7f7f, 0x8181817f, 0x81817f7f,
> +0x7f817f81, 0x7f7f7f7f, 0x7f817f7f, 0x81817f7f, 0x81818181, 0x817f817f,
> +0x81817f7f, 0x7f81817f, 0x7f7f7f7f, 0x7f7f7f7f, 0x7f818181, 0x7f7f7f81,
> +0x81817f81, 0x7f817f7f, 0x7f7f7f7f, 0x817f817f, 0x817f817f, 0x7f7f817f,
> +0x81817f81, 0x7f7f7f7f, 0x7f81817f, 0x817f817f, 0x7f7f8181, 0x7f7f7f7f,
> +0x817f7f7f, 0x81818181, 0x817f8181, 0x7f7f817f, 0x7f7f8181, 0x7f7f7f7f,
> +0x7f818181, 0x817f8181, 0x817f7f81, 0x817f8181, 0x817f7f81, 0x81817f7f,
> +0x7f7f8181, 0x81818181, 0x817f817f, 0x817f7f7f, 0x81818181, 0x7f817f81,
> +0x7f7f7f81, 0x81817f81, 0x7f817f7f, 0x7f818181, 0x7f7f7f81, 0x817f817f,
> +0x81818181, 0x81818181, 0x81817f81, 0x81817f81, 0x7f7f8181, 0x817f7f7f,
> +0x7f81817f, 0x817f817f, 0x81817f7f, 0x817f7f81, 0x81817f7f, 0x7f7f7f81,
> +0x7f817f81, 0x7f817f81, 0x817f7f7f, 0x7f818181, 0x81818181, 0x7f7f7f7f,
> +0x7f7f7f7f, 0x8181817f, 0x7f7f7f81, 0x7f817f81, 0x81817f81, 0x7f7f817f,
> +0x7f81817f, 0x817f8181, 0x7f81817f, 0x7f81817f, 0x817f7f7f, 0x7f81817f,
> +0x817f7f81, 0x817f7f81, 0x7f817f7f, 0x8181817f, 0x7f81817f, 0x7f7f8181,
> +0x817f8181, 0x817f7f7f, 0x817f7f81, 0x7f81817f, 0x7f7f817f, 0x7f817f7f,
> +0x7f7f8181, 0x81818181, 0x7f818181, 0x7f7f817f, 0x7f818181, 0x81818181,
> +0x7f817f7f, 0x817f817f, 0x817f817f, 0x817f7f7f, 0x81817f81, 0x81817f7f,
> +0x81817f81, 0x7f817f81, 0x7f817f7f, 0x7f817f7f, 0x817f7f7f, 0x817f7f7f,
> +0x7f7f7f7f, 0x7f7f7f81, 0x7f7f8181, 0x7f817f81, 0x7f817f7f, 0x817f7f7f,
> +0x7f7f8181, 0x8181817f, 0x7f7f8181, 0x7f7f7f81, 0x817f7f7f, 0x7f7f7f81,
> +0x817f8181, 0x7f7f817f, 0x7f81817f, 0x817f817f, 0x7f817f81, 0x7f7f8181,
> +0x7f818181, 0x7f817f81, 0x81818181, 0x81817f7f, 0x7f81817f, 0x7f81817f,
> +0x7f7f8181, 0x81818181, 0x817f8181, 0x7f7f817f, 0x7f817f7f, 0x7f7f8181,
> +0x7f81817f, 0x7f7f817f, 0x7f7f7f7f, 0x7f818181, 0x81817f7f, 0x8181817f,
> +0x7f81817f, 0x8181817f, 0x81817f81, 0x7f7f7f7f, 0x81818181, 0x7f7f817f,
> +0x7f81817f, 0x7f7f7f7f, 0x81817f81, 0x817f7f81, 0x817f7f81, 0x817f7f81,
> +0x81818181, 0x7f7f7f7f, 0x81817f81, 0x817f7f7f, 0x8181817f, 0x7f7f7f81,
> +0x81817f81, 0x817f7f81, 0x81818181, 0x7f7f7f7f, 0x81817f7f, 0x81817f81,
> +0x7f7f7f81, 0x7f7f7f7f, 0x817f817f, 0x7f818181, 0x8181817f, 0x81817f81,
> +0x7f7f7f81, 0x7f817f7f, 0x7f7f7f7f, 0x7f817f81, 0x8181817f, 0x7f7f7f7f,
> +0x81817f7f, 0x7f7f7f81, 0x7f81817f, 0x7f7f7f7f, 0x7f7f7f81, 0x817f8181,
> +0x7f7f8181, 0x7f7f7f81, 0x7f7f8181, 0x7f817f7f, 0x81818181, 0x7f81817f,
> +0x7f818181, 0x7f818181, 0x7f818181, 0x817f7f81, 0x7f7f8181, 0x81818181,
> +0x7f7f7f7f, 0x7f7f7f7f, 0x817f8181, 0x81818181, 0x7f7f817f, 0x817f8181,
> +0x81817f7f, 0x817f817f, 0x7f7f817f, 0x7f7f7f7f, 0x817f8181, 0x817f8181,
> +0x817f8181, 0x81818181, 0x7f7f817f, 0x7f817f81, 0x817f7f81, 0x7f7f7f81,
> +0x81817f81, 0x7f818181, 0x81817f7f, 0x7f818181, 0x81818181, 0x817f817f,
> +0x7f817f7f, 0x81818181, 0x817f8181, 0x7f7f7f7f, 0x7f817f81, 0x817f7f7f,
> +0x7f818181, 0x8181817f, 0x817f817f, 0x7f817f7f, 0x817f7f81, 0x7f818181,
> +0x817f7f7f, 0x817f7f81, 0x7f7f7f81, 0x81817f81, 0x7f81817f, 0x7f818181,
> +0x81817f7f, 0x817f7f81, 0x818

Re: [dpdk-dev] [PATCH v4 5/8] baseband/la12xx: add queue and modem config support

[Chautru, Nicolas]

> -Original Message-
> From: Hemant Agrawal 
> Sent: Saturday, April 24, 2021 3:37 AM
> Subject: [PATCH v4 5/8] baseband/la12xx: add queue and modem config
> support
> 
> This patch add support for connecting with modem and creating the ipc
> channel as queues with modem for the exchange of data.
> 
> Signed-off-by: Nipun Gupta 
> Signed-off-by: Hemant Agrawal 
> ---
>  doc/guides/bbdevs/index.rst|   1 +
>  doc/guides/bbdevs/la12xx.rst   |  81 +++
>  doc/guides/rel_notes/release_21_05.rst |   5 +
>  drivers/baseband/la12xx/bbdev_la12xx.c | 552 -
>  drivers/baseband/la12xx/bbdev_la12xx.h |  11 +-
>  drivers/baseband/la12xx/bbdev_la12xx_ipc.h | 189 ++-
>  6 files changed, 829 insertions(+), 10 deletions(-)  create mode 100644
> doc/guides/bbdevs/la12xx.rst
> 
> diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
> index 4445cbd1b0..cedd706fa6 100644
> --- a/doc/guides/bbdevs/index.rst
> +++ b/doc/guides/bbdevs/index.rst
> @@ -14,3 +14,4 @@ Baseband Device Drivers
>  fpga_lte_fec
>  fpga_5gnr_fec
>  acc100
> +la12xx
> diff --git a/doc/guides/bbdevs/la12xx.rst b/doc/guides/bbdevs/la12xx.rst
> new file mode 100644 index 00..3c9ac5c047
> --- /dev/null
> +++ b/doc/guides/bbdevs/la12xx.rst
> @@ -0,0 +1,81 @@
> +..  SPDX-License-Identifier: BSD-3-Clause
> +Copyright 2021 NXP
> +
> +NXP LA12xx Poll Mode Driver
> +===
> +
> +The BBDEV LA12xx poll mode driver (PMD) supports an implementation for
> +offloading High Phy processing functions like LDPC Encode / Decode 5GNR
> +wireless acceleration function, using PCI based LA12xx Software defined
> radio.
> +
> +More information can be found at `NXP Official Website
> + processors/layerscape-processors/layerscape-access-la1200-programmable-
> baseband-processor:LA1200>`_.
> +
> +Features
> +
> +
> +LA12xx PMD supports the following features:
> +
> +- Maximum of 8 UL queues
> +- Maximum of 8 DL queues
> +- PCIe Gen-3 x8 Interface
> +- MSI-X
> +
> +Installation
> +
> +
> +Section 3 of the DPDK manual provides instructions on installing and
> compiling DPDK.
> +
> +DPDK requires hugepages to be configured as detailed in section 2 of the
> DPDK manual.
> +
> +Initialization
> +--
> +
> +The device can be listed on the host console with:
> +
> +
> +Use the following lspci command to get the multiple LA12xx processor
> +ids. The device ID of the LA12xx baseband processor is "1c30".
> +
> +.. code-block:: console
> +
> +  sudo lspci -nn
> +
> +...
> +0001:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device
> +[1957:1c30] ( rev 10) ...
> +0002:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device
> +[1957:1c30] ( rev 10)
> +
> +
> +Prerequisites
> +-
> +
> +Currently supported by DPDK:
> +
> +- NXP LA1224 BSP **1.0+**.
> +- NXP LA1224 PCIe Modem card connected to ARM host.
> +
> +- Follow the DPDK :ref:`Getting Started Guide for Linux ` to
> setup the basic DPDK environment.
> +
> +* Use dev arg option ``modem=0`` to identify the modem instance for a
> +given
> +  device. This is required only if more than 1 modem cards are attached to
> host.
> +  this is optional and the default value is 0.
> +  e.g. ``--vdev=baseband_la12xx,modem=0``
> +
> +* Use dev arg option ``max_nb_queues=x`` to specify the maximum
> number
> +of queues
> +  to be used for communication with offload device i.e. modem. default is
> 16.
> +  e.g. ``--vdev=baseband_la12xx,max_nb_queues=4``
> +
> +Enabling logs
> +-
> +
> +For enabling logs, use the following EAL parameter:
> +
> +.. code-block:: console
> +
> +   ./your_bbdev_application  --log-level=la12xx:
> +
> +Using ``bb.la12xx`` as log matching criteria, all Baseband PMD logs can
> +be enabled which are lower than logging ``level``.
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index b3224dc332..4e0b62debb 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -236,6 +236,11 @@ New Features
>the hash function used in NICs to spread the traffic among the queues.
>It can be used to get predictable mapping of the flows.
> 
> +* **Added NXP LA12xx baseband PMD.**
> +
> +  * Added a new baseband PMD driver for NXP LA12xx Software defined
> radio.
> +  * See the :doc:`../bbdevs/la12xx` for more details.
> +
>  * **Updated testpmd.**
> 
>* Added a command line option to configure forced speed for Ethernet
> port.
> diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
> b/drivers/baseband/la12xx/bbdev_la12xx.c
> index f26f3f2a08..1fdeca279e 100644
> --- a/drivers/baseband/la12xx/bbdev_la12xx.c
> +++ b/drivers/baseband/la12xx/bbdev_la12xx.c
> @@ -3,6 +3,11 @@
>   */
> 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 
>  #inclu

Re: [dpdk-dev] [PATCH] bnxt: skip getting statistics for queues not started

[Ajit Khaparde]

On Wed, Apr 21, 2021 at 4:09 PM Stephen Hemminger
 wrote:
>
> An application using rte_flow may define a large number of queues
> but only use a small subset of them at any one time.
>
> Since querying the status of each queue requires a request/spin/reply
> with the firmware, optimize by skipping the request for queues not running.
> For those queues the statistics will be 0.
>
> This cuts the cost of single xstats query in half and has even
> bigger gain for simple stats query.
>
> Signed-off-by: Stephen Hemminger 
Changed the commit headline to
"net/bnxt: skip get statistics for stopped queues"
Patch applied to dpdk-next-net-brcm. Thanks

> ---
>  drivers/net/bnxt/bnxt_stats.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/bnxt/bnxt_stats.c b/drivers/net/bnxt/bnxt_stats.c
> index bb4b2eee194e..11767e06d074 100644
> --- a/drivers/net/bnxt/bnxt_stats.c
> +++ b/drivers/net/bnxt/bnxt_stats.c
> @@ -528,6 +528,8 @@ int bnxt_stats_get_op(struct rte_eth_dev *eth_dev,
> struct bnxt_rx_queue *rxq = bp->rx_queues[i];
> struct bnxt_cp_ring_info *cpr = rxq->cp_ring;
>
> +   if (!rxq->rx_started)
> +   continue;
> rc = bnxt_hwrm_ctx_qstats(bp, cpr->hw_stats_ctx_id, i,
>  bnxt_stats, 1);
> if (unlikely(rc))
> @@ -543,6 +545,8 @@ int bnxt_stats_get_op(struct rte_eth_dev *eth_dev,
> struct bnxt_tx_queue *txq = bp->tx_queues[i];
> struct bnxt_cp_ring_info *cpr = txq->cp_ring;
>
> +   if (!txq->tx_started)
> +   continue;
> rc = bnxt_hwrm_ctx_qstats(bp, cpr->hw_stats_ctx_id, i,
>  bnxt_stats, 0);
> if (unlikely(rc))
> --
> 2.30.2
>

Re: [dpdk-dev] [PATCH] net/bnxt: remove unnecessary forward declaration

[Ajit Khaparde]

On Wed, Apr 21, 2021 at 8:50 PM Kalesh A P
 wrote:
>
> From: Kalesh AP 
>
> This patch removes several redundant forward declarations of
> functions and structure.
>
> Fixes: 0b42b92ae429 ("net/bnxt: fix xstats by id")
> Fixes: cf4f055a6578 ("net/bnxt: remove EEM system memory support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kalesh AP 
> Reviewed-by: Ajit Khaparde 
> Reviewed-by: Lance Richardson 
Patch applied to dpdk-next-net-brcm. Thanks

> ---
>  drivers/net/bnxt/bnxt.h   | 8 
>  drivers/net/bnxt/bnxt_hwrm.h  | 1 -
>  drivers/net/bnxt/bnxt_stats.h | 5 -
>  3 files changed, 14 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
> index dfdfa9f..bd2dec4 100644
> --- a/drivers/net/bnxt/bnxt.h
> +++ b/drivers/net/bnxt/bnxt.h
> @@ -597,13 +597,6 @@ struct bnxt_rep_info {
>  DEV_RX_OFFLOAD_SCATTER | \
>  DEV_RX_OFFLOAD_RSS_HASH)
>
> -#define  MAX_TABLE_SUPPORT 4
> -#define  MAX_DIR_SUPPORT   2
> -struct bnxt_dmabuf_info {
> -   uint32_t entry_num;
> -   int  fd[MAX_DIR_SUPPORT][MAX_TABLE_SUPPORT];
> -};
> -
>  #define BNXT_HWRM_SHORT_REQ_LENsizeof(struct 
> hwrm_short_input)
>
>  struct bnxt_flow_stat_info {
> @@ -834,7 +827,6 @@ struct bnxt {
> uint16_tport_svif;
>
> struct tf   tfp;
> -   struct bnxt_dmabuf_info dmabuf;
> struct bnxt_ulp_context *ulp_ctx;
> struct bnxt_flow_stat_info *flow_stat;
> uint16_tmax_num_kflows;
> diff --git a/drivers/net/bnxt/bnxt_hwrm.h b/drivers/net/bnxt/bnxt_hwrm.h
> index 0c2e32c..d9771ea 100644
> --- a/drivers/net/bnxt/bnxt_hwrm.h
> +++ b/drivers/net/bnxt/bnxt_hwrm.h
> @@ -294,7 +294,6 @@ int bnxt_hwrm_get_dflt_vnic_svif(struct bnxt *bp, 
> uint16_t fid,
>  uint16_t *vnic_id, uint16_t *svif);
>  int bnxt_hwrm_parent_pf_qcfg(struct bnxt *bp);
>  int bnxt_hwrm_port_phy_qcaps(struct bnxt *bp);
> -int bnxt_hwrm_oem_cmd(struct bnxt *bp, uint32_t entry_num);
>  int bnxt_clear_one_vnic_filter(struct bnxt *bp,
>struct bnxt_filter_info *filter);
>  void bnxt_free_vf_info(struct bnxt *bp);
> diff --git a/drivers/net/bnxt/bnxt_stats.h b/drivers/net/bnxt/bnxt_stats.h
> index 0ee2269..e9e5636 100644
> --- a/drivers/net/bnxt/bnxt_stats.h
> +++ b/drivers/net/bnxt/bnxt_stats.h
> @@ -18,11 +18,6 @@ int bnxt_dev_xstats_get_names_op(__rte_unused struct 
> rte_eth_dev *eth_dev,
>  int bnxt_dev_xstats_get_op(struct rte_eth_dev *eth_dev,
>struct rte_eth_xstat *xstats, unsigned int n);
>  int bnxt_dev_xstats_reset_op(struct rte_eth_dev *eth_dev);
> -int bnxt_dev_xstats_get_by_id_op(struct rte_eth_dev *dev, const uint64_t 
> *ids,
> -   uint64_t *values, unsigned int limit);
> -int bnxt_dev_xstats_get_names_by_id_op(struct rte_eth_dev *dev,
> -   struct rte_eth_xstat_name *xstats_names,
> -   const uint64_t *ids, unsigned int limit);
>
>  struct bnxt_xstats_name_off {
> char name[RTE_ETH_XSTATS_NAME_SIZE];
> --
> 2.10.1
>

Re: [dpdk-dev] [PATCH] net/bnxt: fix to remove unused function parameters

[Ajit Khaparde]

On Thu, Apr 22, 2021 at 9:57 PM Kalesh A P
 wrote:
>
> From: Kalesh AP 
>
> 1. Clean up unused function parameters.
> 2. Declare no external referenced function as static and remove
>their prototye from the header file.
>
> Fixes: ec77c6298301 ("net/bnxt: add stats context allocation")
> Fixes: 200b64ba0be8 ("net/bnxt: free statistics context")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kalesh AP 
> Reviewed-by: Somnath Kotur 
> Reviewed-by: Ajit Khaparde 
Fixed typo - s/prototye/prototype during merge.

Patch applied to dpdk-next-net-brcm.

> ---
>  drivers/net/bnxt/bnxt_hwrm.c | 10 --
>  drivers/net/bnxt/bnxt_hwrm.h |  4 
>  2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
> index cb2064d..931ecea 100644
> --- a/drivers/net/bnxt/bnxt_hwrm.c
> +++ b/drivers/net/bnxt/bnxt_hwrm.c
> @@ -1899,8 +1899,7 @@ int bnxt_hwrm_stat_clear(struct bnxt *bp, struct 
> bnxt_cp_ring_info *cpr)
> return rc;
>  }
>
> -int bnxt_hwrm_stat_ctx_alloc(struct bnxt *bp, struct bnxt_cp_ring_info *cpr,
> -   unsigned int idx __rte_unused)
> +static int bnxt_hwrm_stat_ctx_alloc(struct bnxt *bp, struct 
> bnxt_cp_ring_info *cpr)
>  {
> int rc;
> struct hwrm_stat_ctx_alloc_input req = {.req_type = 0 };
> @@ -1923,8 +1922,7 @@ int bnxt_hwrm_stat_ctx_alloc(struct bnxt *bp, struct 
> bnxt_cp_ring_info *cpr,
> return rc;
>  }
>
> -int bnxt_hwrm_stat_ctx_free(struct bnxt *bp, struct bnxt_cp_ring_info *cpr,
> -   unsigned int idx __rte_unused)
> +static int bnxt_hwrm_stat_ctx_free(struct bnxt *bp, struct bnxt_cp_ring_info 
> *cpr)
>  {
> int rc;
> struct hwrm_stat_ctx_free_input req = {.req_type = 0 };
> @@ -2594,7 +2592,7 @@ bnxt_free_all_hwrm_stat_ctxs(struct bnxt *bp)
> bp->grp_info[i].fw_stats_ctx = -1;
> }
> if (cpr->hw_stats_ctx_id != HWRM_NA_SIGNATURE) {
> -   rc = bnxt_hwrm_stat_ctx_free(bp, cpr, i);
> +   rc = bnxt_hwrm_stat_ctx_free(bp, cpr);
> cpr->hw_stats_ctx_id = HWRM_NA_SIGNATURE;
> if (rc)
> return rc;
> @@ -2621,7 +2619,7 @@ int bnxt_alloc_all_hwrm_stat_ctxs(struct bnxt *bp)
> cpr = rxq->cp_ring;
> }
>
> -   rc = bnxt_hwrm_stat_ctx_alloc(bp, cpr, i);
> +   rc = bnxt_hwrm_stat_ctx_alloc(bp, cpr);
>
> if (rc)
> return rc;
> diff --git a/drivers/net/bnxt/bnxt_hwrm.h b/drivers/net/bnxt/bnxt_hwrm.h
> index 0c2e32c..61b3050 100644
> --- a/drivers/net/bnxt/bnxt_hwrm.h
> +++ b/drivers/net/bnxt/bnxt_hwrm.h
> @@ -168,10 +168,6 @@ int bnxt_hwrm_ring_grp_alloc(struct bnxt *bp, unsigned 
> int idx);
>  int bnxt_hwrm_ring_grp_free(struct bnxt *bp, unsigned int idx);
>
>  int bnxt_hwrm_stat_clear(struct bnxt *bp, struct bnxt_cp_ring_info *cpr);
> -int bnxt_hwrm_stat_ctx_alloc(struct bnxt *bp,
> -struct bnxt_cp_ring_info *cpr, unsigned int idx);
> -int bnxt_hwrm_stat_ctx_free(struct bnxt *bp,
> -   struct bnxt_cp_ring_info *cpr, unsigned int idx);
>  int bnxt_hwrm_ctx_qstats(struct bnxt *bp, uint32_t cid, int idx,
>  struct rte_eth_stats *stats, uint8_t rx);
>
> --
> 2.10.1
>

Re: [dpdk-dev] [RFC] net/ionic: update MTU calculations

[Andrew Boyer]

> On Apr 23, 2021, at 7:42 AM, Ferruh Yigit  wrote:
> 
> On 12/15/2020 12:26 PM, Ferruh Yigit wrote:
>> On 12/10/2020 2:46 AM, Andrew Boyer wrote:
>>> This RFC is in response to the threads about testpmd mtu settings
>>> and the deprecation of max-rx-pkt-len.
>>> 
>>> It took us a while to figure out what we were supposed to be doing
>>> in this part of the API. It is not clear if max_rx_pkt_len should be
>>> an input to or an output from the PMD.
>> 'max_rx_pkt_len' is input to the PMD, but it needs to be in sync with MTU 
>> value, that is why PMDs update this value when MTU is updated to keep the 
>> sync.
>>> 
>>> The code below represents what we believe should happen today, and also
>>> happens to pass the DTS tests which were failing prior to this change
>>> (checksum and jumbo_frame at least).
>>> 
> 
> Hi Andrew,
> 
> I am updating the status of the patch as "change requested", what is the 
> status of this patch, will there be a new version?
> Is DTS still failing?
> 
> Please see a few comments below if there will be new version.
> 

Thank you for your thorough review!

I am working on a new feature at present so upstreaming has been delayed.

We were blocked from posting the next set of our patches by some arm64 build 
stuff, but thanks to Juraj & co. I think that is cleared up. It’s just a matter 
of when I will get to posting them.

-Andrew

> <...>
> 
>>> diff --git a/drivers/net/ionic/ionic_ethdev.c 
>>> b/drivers/net/ionic/ionic_ethdev.c
>>> index 925da3e29..7000de3f9 100644
>>> --- a/drivers/net/ionic/ionic_ethdev.c
>>> +++ b/drivers/net/ionic/ionic_ethdev.c
>>> @@ -357,25 +357,19 @@ ionic_dev_mtu_set(struct rte_eth_dev *eth_dev, 
>>> uint16_t mtu)
>>>   int err;
>>>   IONIC_PRINT_CALL();
>>> +IONIC_PRINT(INFO, "Setting mtu %u\n", mtu);
>>> -/*
>>> - * Note: mtu check against IONIC_MIN_MTU, IONIC_MAX_MTU
>>> - * is done by the the API.
>>> - */
>>> -
>>> -/*
>>> - * Max frame size is MTU + Ethernet header + VLAN + QinQ
>>> - * (plus ETHER_CRC_LEN if the adapter is able to keep CRC)
>>> - */
>>> -max_frame_size = mtu + RTE_ETHER_HDR_LEN + 4 + 4;
>>> -
>>> -if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len < max_frame_size)
>>> -return -EINVAL;
>> The max frame size calculation depends on what HW support, but if VLAN 
>> header is supported above calculation and check is correct.
> 
> Removing above check seems correct thing to do, instead should check against 
> 'dev_info.max_mtu' which is already done in ethdev layer, so nothing needed 
> here.
> 
>>> -
>>> +/* Note: mtu check against min/max is done by the API */
>>>   err = ionic_lif_change_mtu(lif, mtu);
>>>   if (err)
>>>   return err;
>>> +/* Update max frame size */
>>> +max_frame_size = mtu + RTE_ETHER_HDR_LEN;
>> I guess you are removing the CRC because your HW strips the CRC in the Rx 
>> buffer, but this limit is not for Rx buffer, it is for the frame size HW 
>> accepts, and since recevied frame will have the CRC it should be included 
>> into the calculation.
>>> +eth_dev->data->dev_conf.rxmode.max_rx_pkt_len = max_frame_size;
>>> +
> 
> Although 'rxmode.max_rx_pkt_len' is input to driver, it is related with MTU, 
> which is also input from application in this function, so OK to update 
> 'rxmode.max_rx_pkt_len' here.
> 
>>> +ionic_lif_set_rx_buf_size(lif);
>>> +
> 
> This seems to keep the local copy of 'rxmode.max_rx_pkt_len' and use local 
> copy instead, is this just refactoring or is there any other reason for local 
> copy?

Re: [dpdk-dev] [PATCH] net/bnxt: drop the unused attribute

[Ajit Khaparde]

On Thu, Apr 22, 2021 at 10:00 PM Kalesh A P
 wrote:
>
> From: Kalesh AP 
>
> Remove "__rte_unused" instances that are wrongly marked.
>
> Signed-off-by: Kalesh AP 
> Reviewed-by: Somnath Kotur 
> Reviewed-by: Ajit Khaparde 
Patch applied to dpdk-next-net-brcm.

> ---
>  drivers/net/bnxt/bnxt_reps.c  | 4 ++--
>  drivers/net/bnxt/bnxt_stats.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
> index b224a7d..bdbad53 100644
> --- a/drivers/net/bnxt/bnxt_reps.c
> +++ b/drivers/net/bnxt/bnxt_reps.c
> @@ -104,7 +104,7 @@ bnxt_rep_rx_burst(void *rx_queue,
>  static uint16_t
>  bnxt_rep_tx_burst(void *tx_queue,
>  struct rte_mbuf **tx_pkts,
> -__rte_unused uint16_t nb_pkts)
> +uint16_t nb_pkts)
>  {
> struct bnxt_vf_rep_tx_queue *vfr_txq = tx_queue;
> struct bnxt_tx_queue *ptxq;
> @@ -548,7 +548,7 @@ int bnxt_rep_dev_info_get_op(struct rte_eth_dev *eth_dev,
> return 0;
>  }
>
> -int bnxt_rep_dev_configure_op(__rte_unused struct rte_eth_dev *eth_dev)
> +int bnxt_rep_dev_configure_op(struct rte_eth_dev *eth_dev)
>  {
> struct bnxt_representor *rep_bp = eth_dev->data->dev_private;
>
> diff --git a/drivers/net/bnxt/bnxt_stats.h b/drivers/net/bnxt/bnxt_stats.h
> index 0ee2269..ee6b1be 100644
> --- a/drivers/net/bnxt/bnxt_stats.h
> +++ b/drivers/net/bnxt/bnxt_stats.h
> @@ -12,7 +12,7 @@ void bnxt_free_stats(struct bnxt *bp);
>  int bnxt_stats_get_op(struct rte_eth_dev *eth_dev,
>struct rte_eth_stats *bnxt_stats);
>  int bnxt_stats_reset_op(struct rte_eth_dev *eth_dev);
> -int bnxt_dev_xstats_get_names_op(__rte_unused struct rte_eth_dev *eth_dev,
> +int bnxt_dev_xstats_get_names_op(struct rte_eth_dev *eth_dev,
> struct rte_eth_xstat_name *xstats_names,
> __rte_unused unsigned int limit);
>  int bnxt_dev_xstats_get_op(struct rte_eth_dev *eth_dev,
> --
> 2.10.1
>

Re: [dpdk-dev] [PATCH] net/bnxt: use bnxt_ prefix on global function

[Ajit Khaparde]

On Fri, Apr 23, 2021 at 2:04 PM Stephen Hemminger
 wrote:
>
> When statically linked the function prandom_bytes is exposed
> and might conflict with something in application. All driver
> functions should use same prefix.
>
> Fixes: 9738793f28ec ("net/bnxt: add VNIC functions and structs")
> Signed-off-by: Stephen Hemminger 
Patch applied to dpdk-next-net-brcm. Thanks

> ---
>  drivers/net/bnxt/bnxt_flow.c | 4 ++--
>  drivers/net/bnxt/bnxt_vnic.c | 4 ++--
>  drivers/net/bnxt/bnxt_vnic.h | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
> index e3906b47791b..844bf1520f50 100644
> --- a/drivers/net/bnxt/bnxt_flow.c
> +++ b/drivers/net/bnxt/bnxt_flow.c
> @@ -1404,8 +1404,8 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
> /* If hash key has not been specified,
>  * use random hash key.
>  */
> -   prandom_bytes(vnic->rss_hash_key,
> - HW_HASH_KEY_SIZE);
> +   bnxt_prandom_bytes(vnic->rss_hash_key,
> +  HW_HASH_KEY_SIZE);
> } else {
> if (rss->key_len > HW_HASH_KEY_SIZE)
> memcpy(vnic->rss_hash_key,
> diff --git a/drivers/net/bnxt/bnxt_vnic.c b/drivers/net/bnxt/bnxt_vnic.c
> index 14ad33b4e86c..de5c14566deb 100644
> --- a/drivers/net/bnxt/bnxt_vnic.c
> +++ b/drivers/net/bnxt/bnxt_vnic.c
> @@ -16,7 +16,7 @@
>   * VNIC Functions
>   */
>
> -void prandom_bytes(void *dest_ptr, size_t len)
> +void bnxt_prandom_bytes(void *dest_ptr, size_t len)
>  {
> char *dest = (char *)dest_ptr;
> uint64_t rb;
> @@ -172,7 +172,7 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp)
> HW_HASH_KEY_SIZE);
> vnic->mc_list_dma_addr = vnic->rss_hash_key_dma_addr +
> HW_HASH_KEY_SIZE;
> -   prandom_bytes(vnic->rss_hash_key, HW_HASH_KEY_SIZE);
> +   bnxt_prandom_bytes(vnic->rss_hash_key, HW_HASH_KEY_SIZE);
> }
>
> return 0;
> diff --git a/drivers/net/bnxt/bnxt_vnic.h b/drivers/net/bnxt/bnxt_vnic.h
> index 00a664c8b839..37b452f28170 100644
> --- a/drivers/net/bnxt/bnxt_vnic.h
> +++ b/drivers/net/bnxt/bnxt_vnic.h
> @@ -68,7 +68,7 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp);
>  void bnxt_free_vnic_mem(struct bnxt *bp);
>  int bnxt_alloc_vnic_mem(struct bnxt *bp);
>  int bnxt_vnic_grp_alloc(struct bnxt *bp, struct bnxt_vnic_info *vnic);
> -void prandom_bytes(void *dest_ptr, size_t len);
> +void bnxt_prandom_bytes(void *dest_ptr, size_t len);
>  uint16_t bnxt_rte_to_hwrm_hash_types(uint64_t rte_type);
>  int bnxt_rte_to_hwrm_hash_level(struct bnxt *bp, uint64_t hash_f, uint32_t 
> lvl);
>  uint64_t bnxt_hwrm_to_rte_rss_level(struct bnxt *bp, uint32_t mode);
> --
> 2.30.2
>

Re: [dpdk-dev] [PATCH v2] doc: fix formatting in testpmd user guide

[Li, Xiaoyun]

Hi

> -Original Message-
> From: Yigit, Ferruh 
> Sent: Saturday, April 24, 2021 00:30
> To: Li, Xiaoyun ; Ori Kam ; Bing Zhao
> 
> Cc: Yigit, Ferruh ; dev@dpdk.org; Ajit Khaparde
> 
> Subject: [PATCH v2] doc: fix formatting in testpmd user guide
> 
> From: Ajit Khaparde 
> 
> Fix formatting in testpmd user guide for hairpin operation.
> 
> Fixes: 01817b10d27c ("app/testpmd: change hairpin queues setup")
> Cc:sta...@dpdk.org

Missing a space after "Cc:" as patchwork says.

Except for this typo,
Acked-by: Xiaoyun Li 

Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix integer overflow during get DCB conf

[Li, Xiaoyun]

Hi

> -Original Message-
> From: Min Hu (Connor) 
> Sent: Thursday, April 22, 2021 15:04
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Li, Xiaoyun 
> Subject: [PATCH 1/2] app/testpmd: fix integer overflow during get DCB conf
> 
> From: Chengchang Tang 
> 
> In C, constant is treated as integer. Therefore, if nb_queque_pools is
> ETH_32_POOLS, the shift here may cause integer overflow.
> 
> Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic
> class")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Chengchang Tang 
> Signed-off-by: Min Hu (Connor) 
> ---
>  app/test-pmd/testpmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> afa2a6b..6784160 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -3640,7 +3640,7 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
> *eth_conf,
>   for (i = 0; i < vmdq_rx_conf->nb_pool_maps; i++) {
>   vmdq_rx_conf->pool_map[i].vlan_id = vlan_tags[i];
>   vmdq_rx_conf->pool_map[i].pools =
> - 1 << (i % vmdq_rx_conf->nb_queue_pools);
> + 1ULL << (i % vmdq_rx_conf->nb_queue_pools);

In get_eth_dcb_conf(),
vmdq_rx_conf->nb_queue_pools =
(num_tcs ==  ETH_4_TCS ? ETH_32_POOLS : ETH_16_POOLS);

It will only be 16 or 32.
So I don't think this patch is necessary unless you're going to use the value 
ETH_64_POOLS.

>   }
>   for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
>   vmdq_rx_conf->dcb_tc[i] = i % num_tcs;
> --
> 2.7.4

Re: [dpdk-dev] [PATCH v1] raw/ifpga: fix ifpga device name format

[Zhang, Qi Z]

> -Original Message-
> From: Xu, Rosen 
> Sent: Thursday, April 22, 2021 7:13 PM
> To: Huang, Wei ; dev@dpdk.org; Zhang, Qi Z
> 
> Cc: sta...@dpdk.org; Zhang, Tianfei ; Yigit, Ferruh
> 
> Subject: RE: [PATCH v1] raw/ifpga: fix ifpga device name format
> 
> Hi,
> 
> > -Original Message-
> > From: Huang, Wei 
> > Sent: Thursday, April 22, 2021 16:27
> > To: dev@dpdk.org; Xu, Rosen ; Zhang, Qi Z
> > 
> > Cc: sta...@dpdk.org; Zhang, Tianfei ; Yigit,
> > Ferruh ; Huang, Wei 
> > Subject: [PATCH v1] raw/ifpga: fix ifpga device name format
> >
> > The device name format used in ifpga_rawdev_create() was changed to
> > "IFPGA:%02x:%02x.%x", but the format used in ifpga_rawdev_destroy()
> > was left as "IFPGA:%x:%02x.%x", it should be changed synchronously.
> >
> > Fixes: 9c006c45d0c5 ("raw/ifpga: scan PCIe BDF device tree")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Huang 
> > ---
> >  drivers/raw/ifpga/ifpga_rawdev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> > b/drivers/raw/ifpga/ifpga_rawdev.c
> > index d9a46ef915..f591a87b49 100644
> > --- a/drivers/raw/ifpga/ifpga_rawdev.c
> > +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> > @@ -1551,7 +1551,7 @@ ifpga_rawdev_destroy(struct rte_pci_device
> > *pci_dev)
> >  }
> >
> >  memset(name, 0, sizeof(name));
> > -snprintf(name, RTE_RAWDEV_NAME_MAX_LEN, "IFPGA:%x:%02x.%x",
> > +snprintf(name, RTE_RAWDEV_NAME_MAX_LEN,
> > "IFPGA:%02x:%02x.%x",
> >  pci_dev->addr.bus, pci_dev->addr.devid, pci_dev-
> > >addr.function);
> >
> >  IFPGA_RAWDEV_PMD_INFO("Closing %s on NUMA node %d",
> > --
> > 2.29.2
> 
> Acked-by: Rosen Xu 

Applied to dpdk-next-net-intel

Thanks
Qi

Re: [dpdk-dev] [PATCH 2/2] app/testpmd: fix max queue number when configure Tx offloads

[Li, Xiaoyun]

> -Original Message-
> From: Min Hu (Connor) 
> Sent: Thursday, April 22, 2021 15:04
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Li, Xiaoyun 
> Subject: [PATCH 2/2] app/testpmd: fix max queue number when configure Tx
> offloads
> 
> From: Chengchang Tang 
> 
> When txq offload is configured, max rxq is used as the max queue. This patch
> fixes it.
> 
> Fixes: 74453ac9ef67 ("app/testpmd: fix queue offload configuration")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Chengchang Tang 
> Signed-off-by: Min Hu (Connor) 
> ---
>  app/test-pmd/cmdline.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> f0fa6e8..1cb1027 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -4666,7 +4666,7 @@ cmd_config_queue_tx_offloads(struct rte_port *port)
>   int k;
> 
>   /* Apply queue tx offloads configuration */
> - for (k = 0; k < port->dev_info.max_rx_queues; k++)
> + for (k = 0; k < port->dev_info.max_tx_queues; k++)
>   port->tx_conf[k].offloads =
>   port->dev_conf.txmode.offloads;
>  }
> --
> 2.7.4

Acked-by: Xiaoyun Li 

Re: [dpdk-dev] [PATCH v5] net/iavf: fix hash configuration on i40e VF

[Xing, Beilei]

> -Original Message-
> From: Zhang, AlvinX 
> Sent: Thursday, April 22, 2021 1:08 PM
> To: Wu, Jingjing ; Xing, Beilei 
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [PATCH v5] net/iavf: fix hash configuration on i40e VF
> 
> In i40evf PMD, the VF directly accesses the hash enable registers to enable or
> disable hashing on ingress packets. When binding i40e VF to iavf, because the
> PF doesn't support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.
> Therefore, the VF hashing cannot be enabled.

Better to descript what's the issue first and then give the root cause.

> 
> This patch adds support of hash configuration for i40e VF by sending
> VIRTCHNL_OP_SET_RSS_HENA message to the PF after checking that the PF
> does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.
> 
> Fixes: c678299594a8 ("net/iavf: fix default RSS configuration")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Alvin Zhang 
> ---
> 
> v2: Update commit log.
> v3: Increase compatibility with old drivers.
> v4: Fix compile issues.
> v5: Rebase to 1b593b9c832e9b284cc59665fe662242a3fc1daf.
> ---
>  drivers/net/iavf/iavf.h|   1 +
>  drivers/net/iavf/iavf_ethdev.c | 111
> -
>  drivers/net/iavf/iavf_vchnl.c  |  45 ++---
>  3 files changed, 150 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h index
> d1ae5a3..1e73f01 100644
> --- a/drivers/net/iavf/iavf.h
> +++ b/drivers/net/iavf/iavf.h
> @@ -336,6 +336,7 @@ int iavf_fdir_check(struct iavf_adapter *adapter,
>   struct iavf_fdir_conf *filter);
>  int iavf_add_del_rss_cfg(struct iavf_adapter *adapter,
>struct virtchnl_rss_cfg *rss_cfg, bool add);
> +int iavf_get_hena_caps(struct iavf_adapter *adapter, uint64_t *caps);
>  int iavf_set_hena(struct iavf_adapter *adapter, uint64_t hena);  int
> iavf_rss_hash_set(struct iavf_adapter *ad, uint64_t rss_hf, bool add);  int
> iavf_add_del_mc_addr_list(struct iavf_adapter *adapter, diff --git
> a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c index
> d523a06..97a2dc7 100644
> --- a/drivers/net/iavf/iavf_ethdev.c
> +++ b/drivers/net/iavf/iavf_ethdev.c
> @@ -246,6 +246,107 @@ struct rte_iavf_xstats_name_off {  }
> 
>  static int
> +iavf_config_rss_hf(struct iavf_adapter *adapter, uint64_t rss_hf) {
> + static const uint64_t map_hena_rss[] = {
> + /* IPv4 */
> + [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
> + ETH_RSS_NONFRAG_IPV4_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP] =
> + ETH_RSS_NONFRAG_IPV4_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV4_UDP] =
> + ETH_RSS_NONFRAG_IPV4_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
> + ETH_RSS_NONFRAG_IPV4_TCP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP] =
> + ETH_RSS_NONFRAG_IPV4_TCP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV4_SCTP] =
> + ETH_RSS_NONFRAG_IPV4_SCTP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV4_OTHER] =
> + ETH_RSS_NONFRAG_IPV4_OTHER,
> + [IAVF_FILTER_PCTYPE_FRAG_IPV4] = ETH_RSS_FRAG_IPV4,
> +
> + /* IPv6 */
> + [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
> + ETH_RSS_NONFRAG_IPV6_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP] =
> + ETH_RSS_NONFRAG_IPV6_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV6_UDP] =
> + ETH_RSS_NONFRAG_IPV6_UDP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
> + ETH_RSS_NONFRAG_IPV6_TCP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP] =
> + ETH_RSS_NONFRAG_IPV6_TCP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV6_SCTP] =
> + ETH_RSS_NONFRAG_IPV6_SCTP,
> + [IAVF_FILTER_PCTYPE_NONF_IPV6_OTHER] =
> + ETH_RSS_NONFRAG_IPV6_OTHER,
> + [IAVF_FILTER_PCTYPE_FRAG_IPV6] = ETH_RSS_FRAG_IPV6,
> +
> + /* L2 Payload */
> + [IAVF_FILTER_PCTYPE_L2_PAYLOAD] = ETH_RSS_L2_PAYLOAD
> + };
> +
> + const uint64_t ipv4_rss = ETH_RSS_NONFRAG_IPV4_UDP |
> +   ETH_RSS_NONFRAG_IPV4_TCP |
> +   ETH_RSS_NONFRAG_IPV4_SCTP |
> +   ETH_RSS_NONFRAG_IPV4_OTHER |
> +   ETH_RSS_FRAG_IPV4;
> +
> + const uint64_t ipv6_rss = ETH_RSS_NONFRAG_IPV6_UDP |
> +   ETH_RSS_NONFRAG_IPV6_TCP |
> +   ETH_RSS_NONFRAG_IPV6_SCTP |
> +   ETH_RSS_NONFRAG_IPV6_OTHER |
> +   ETH_RSS_FRAG_IPV6;
> +
> + struct iavf_info *vf =  I

[dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time

[Wenjun Wu]

When resetting VF, VF will issue reset command to PF, wait a
fixed amount of time, and assume VF reset is done. However,
due to the change of dpdk related library content, the original
delay is not enough. When we use DPDK PF instead of kernel PF,
it may cause VF start error.

This patch extend VF reset waiting time from 200ms to 500ms so that
VF can start normally when using DPDK PF and DPDK VF in most cases.

Signed-off-by: Wenjun Wu 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 3c258ba7cf..aeb6816b9f 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1236,7 +1236,7 @@ i40evf_reset_vf(struct rte_eth_dev *dev)
  * it to ACTIVE. In this duration, vf may not catch the moment that
  * COMPLETE is set. So, for vf, we'll try to wait a long time.
  */
-   rte_delay_ms(200);
+   rte_delay_ms(500);
 
ret = i40evf_check_vf_reset_done(dev);
if (ret) {
-- 
2.25.1

Re: [dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time

[Zhang, Qi Z]

> -Original Message-
> From: dev  On Behalf Of Wenjun Wu
> Sent: Sunday, April 25, 2021 10:03 AM
> To: dev@dpdk.org; Xing, Beilei 
> Cc: Wu, Wenjun1 
> Subject: [dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time
> 
> When resetting VF, VF will issue reset command to PF, wait a fixed amount of
> time, and assume VF reset is done. However, due to the change of dpdk
> related library content, the original delay is not enough. When we use DPDK
> PF instead of kernel PF, it may cause VF start error.
> 
> This patch extend VF reset waiting time from 200ms to 500ms so that VF can
> start normally when using DPDK PF and DPDK VF in most cases.
> 
> Signed-off-by: Wenjun Wu 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix integer overflow during get DCB conf

[Min Hu (Connor)]

在 2021/4/25 10:05, Li, Xiaoyun 写道:

Hi


-Original Message-
From: Min Hu (Connor) 
Sent: Thursday, April 22, 2021 15:04
To: dev@dpdk.org
Cc: Yigit, Ferruh ; Li, Xiaoyun 
Subject: [PATCH 1/2] app/testpmd: fix integer overflow during get DCB conf

From: Chengchang Tang 

In C, constant is treated as integer. Therefore, if nb_queque_pools is
ETH_32_POOLS, the shift here may cause integer overflow.

Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic
class")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Min Hu (Connor) 
---
  app/test-pmd/testpmd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
afa2a6b..6784160 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3640,7 +3640,7 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
for (i = 0; i < vmdq_rx_conf->nb_pool_maps; i++) {
vmdq_rx_conf->pool_map[i].vlan_id = vlan_tags[i];
vmdq_rx_conf->pool_map[i].pools =
-   1 << (i % vmdq_rx_conf->nb_queue_pools);
+   1ULL << (i % vmdq_rx_conf->nb_queue_pools);


In get_eth_dcb_conf(),
vmdq_rx_conf->nb_queue_pools =
(num_tcs ==  ETH_4_TCS ? ETH_32_POOLS : ETH_16_POOLS);

It will only be 16 or 32.
So I don't think this patch is necessary unless you're going to use the value 
ETH_64_POOLS.


Agreed, this patch can be abandoned, thanks.

}
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
vmdq_rx_conf->dcb_tc[i] = i % num_tcs;
--
2.7.4


.

[dpdk-dev] [Bug 687] [dpdk-21.05] unit_tests_power/power_cpufreq: unit test failed

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=687

Bug ID: 687
   Summary: [dpdk-21.05] unit_tests_power/power_cpufreq: unit test
failed
   Product: DPDK
   Version: unspecified
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: other
  Assignee: dev@dpdk.org
  Reporter: zhiminx.hu...@intel.com
  Target Milestone: ---

ENV:
DPDK version: 
dpdk-21.05-rc1: 1b593b9c832e9b284cc59665fe662242a3fc1daf
OS: CentOS Stream release 8/4.18.0-277.el8.x86_64
Compiler: gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC)
Hardware platform: Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz
NIC hardware: Intel Corporation Ethernet Controller E810-C for QSFP [8086:1592]
CVL100Gx2
NIC firmware: 
ice: 1.6.0_rc26_4_g2fb2c79e_dirty
firmware-version: 3.00 0x800071ff 1.2928.0
ICE OS Default Package version 1.3.26.0

Reproduced step:
1.
echo 2 > /sys/bus/pci/devices/\:81\:00.0/sriov_numvfs
2.
ip link set ens801f0 vf 0 trust on
3.
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1,2,3,4 -n 4 -a
:81:01.0,cap=dcf -a :81:01.1  --file-prefix=dpdk_11923_20210423100520  
-- -i
4.
flow validate 0 ingress pattern eth / ipv6 / udp / gtpu / ipv6 src is 2001::1 /
tcp dst is 23 / end actions vf id 1 / end

output:
RTE>>power_cpufreq_autotest
POWER: Env isn't set yet!
POWER: Attempting to initialise ACPI cpufreq power management...
POWER: Initialized successfully for lcore 2 power management
POWER: Power management governor of lcore 2 has been set back to  successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Lcore id 128 can not exceeds 127
POWER: Initialized successfully for lcore 2 power management
POWER: Power management of lcore 2 is in use
POWER: Invalid lcore ID
POWER: NULL buffer supplied
POWER: Buffer size is not enough
POWER: Invalid lcore ID
POWER: Power management governor of lcore 2 has been set back to  successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
Test Failed

expected output:
RTE>>power_cpufreq_autotest
POWER: Env isn't set yet!
POWER: Attempting to initialise ACPI cpufreq power management...
POWER: Initialized successfully for lcore 2 power management
POWER: Power management governor of lcore 2 has been set back to  successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Lcore id 128 can not exceeds 127
POWER: Initialized successfully for lcore 2 power management
POWER: Power management of lcore 2 is in use
POWER: Invalid lcore ID
POWER: NULL buffer supplied
POWER: Buffer size is not enough
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid frequency index 64, which should be less than 15
POWER: Invalid frequency index 15, which should be less than 15
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Power management governor of lcore 2 has been set back to  successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Power management of lcore 2 is not used
POWER: Lcore id 128 can not exceeds 127
Test OK

bad commit id:  606a234c6d3607c93a0426bdccdbf9aaa2b8e5f6

commit 606a234c6d3607c93a0426bdccdbf9aaa2b8e5f6 (refs/bisect/bad)
Author: Richael Zhuang 
Date: Thu Apr 15 13:59:30 2021 +0800

test/power: round CPU frequency to check

The value in "/sys/.../cpuinfo_cur_freq" may not be exactly the
same as what was set. For example, if "240" is written to
"/sys/.../cpufreq/scaling_setspeed" to set the frequency, then the
value in "/sys/.../cpuinfo_cur_freq" may be "2401222". So need to
round the value.

Fixes: ed7c51a6a680 ("app/test: vm power management")
Cc: sta...@dpdk.org

Signed-off-by: Richael Zhuang 
Reviewed-by: David Hunt 

diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index d47b3e0a1a..f753d24ac5 100644
— a/app/test/test_power_cpufreq.c
+++ b/app/test/test_power_cpufreq.c

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH] net/iavf: fix PF returning error

[Alvin Zhang]

When the command sent by VF to PF fails, iavf may need to run
different code paths according to the specific reason of the
failure (not supported or other reasons).

This patch adds support of identifying PF return error type.

Fixes: 22b123a36d07 ("net/avf: initialize PMD")
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 
---
 drivers/net/iavf/iavf_vchnl.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 45096cb..6586fc3 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -228,13 +228,19 @@
rte_delay_ms(ASQ_DELAY_MS);
/* If don't read msg or read sys event, continue */
} while (i++ < MAX_TRY_TIMES);
-   /* If there's no response is received, clear command */
-   if (i >= MAX_TRY_TIMES  ||
-   vf->cmd_retval != VIRTCHNL_STATUS_SUCCESS) {
-   err = -1;
-   PMD_DRV_LOG(ERR, "No response or return failure (%d)"
-   " for cmd %d", vf->cmd_retval, args->ops);
+
+   if (i >= MAX_TRY_TIMES) {
+   PMD_DRV_LOG(ERR, "No response for cmd %d", args->ops);
_clear_cmd(vf);
+   err = -EIO;
+   } else if (vf->cmd_retval ==
+  (uint32_t)VIRTCHNL_STATUS_ERR_NOT_SUPPORTED) {
+   PMD_DRV_LOG(ERR, "Cmd %d not supported", args->ops);
+   err = -ENOTSUP;
+   } else if (vf->cmd_retval != VIRTCHNL_STATUS_SUCCESS) {
+   PMD_DRV_LOG(ERR, "Return failure %d for cmd %d",
+   vf->cmd_retval, args->ops);
+   err = -EINVAL;
}
break;
}
-- 
1.8.3.1

[dpdk-dev] [PATCH v6] net/iavf: fix RSS configuration on i40e VF

[Alvin Zhang]

The iavf does not support configuring RSS type on i40e VF,
because the i40e kernel driver does not support
VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.

This patch adds support of RSS type configuration for i40e VF by
sending VIRTCHNL_OP_SET_RSS_HENA message to the PF after checking
that the PF does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF
capability.

Fixes: c678299594a8 ("net/iavf: fix default RSS configuration")
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 
---

v2: Update commit log.
v3: Increase compatibility with old drivers.
v4: Fix compile issues.
v5: Rebase to 1b593b9c832e9b284cc59665fe662242a3fc1daf.
v6: Divide the patch into 2.
---
 drivers/net/iavf/iavf.h|   1 +
 drivers/net/iavf/iavf_ethdev.c | 111 -
 drivers/net/iavf/iavf_vchnl.c  |  24 +
 3 files changed, 135 insertions(+), 1 deletion(-)

diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index d1ae5a3..1e73f01 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -336,6 +336,7 @@ int iavf_fdir_check(struct iavf_adapter *adapter,
struct iavf_fdir_conf *filter);
 int iavf_add_del_rss_cfg(struct iavf_adapter *adapter,
 struct virtchnl_rss_cfg *rss_cfg, bool add);
+int iavf_get_hena_caps(struct iavf_adapter *adapter, uint64_t *caps);
 int iavf_set_hena(struct iavf_adapter *adapter, uint64_t hena);
 int iavf_rss_hash_set(struct iavf_adapter *ad, uint64_t rss_hf, bool add);
 int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index d523a06..97a2dc7 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -246,6 +246,107 @@ struct rte_iavf_xstats_name_off {
 }
 
 static int
+iavf_config_rss_hf(struct iavf_adapter *adapter, uint64_t rss_hf)
+{
+   static const uint64_t map_hena_rss[] = {
+   /* IPv4 */
+   [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
+   ETH_RSS_NONFRAG_IPV4_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP] =
+   ETH_RSS_NONFRAG_IPV4_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV4_UDP] =
+   ETH_RSS_NONFRAG_IPV4_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
+   ETH_RSS_NONFRAG_IPV4_TCP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP] =
+   ETH_RSS_NONFRAG_IPV4_TCP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+   ETH_RSS_NONFRAG_IPV4_SCTP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+   ETH_RSS_NONFRAG_IPV4_OTHER,
+   [IAVF_FILTER_PCTYPE_FRAG_IPV4] = ETH_RSS_FRAG_IPV4,
+
+   /* IPv6 */
+   [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
+   ETH_RSS_NONFRAG_IPV6_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP] =
+   ETH_RSS_NONFRAG_IPV6_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV6_UDP] =
+   ETH_RSS_NONFRAG_IPV6_UDP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
+   ETH_RSS_NONFRAG_IPV6_TCP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP] =
+   ETH_RSS_NONFRAG_IPV6_TCP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+   ETH_RSS_NONFRAG_IPV6_SCTP,
+   [IAVF_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+   ETH_RSS_NONFRAG_IPV6_OTHER,
+   [IAVF_FILTER_PCTYPE_FRAG_IPV6] = ETH_RSS_FRAG_IPV6,
+
+   /* L2 Payload */
+   [IAVF_FILTER_PCTYPE_L2_PAYLOAD] = ETH_RSS_L2_PAYLOAD
+   };
+
+   const uint64_t ipv4_rss = ETH_RSS_NONFRAG_IPV4_UDP |
+ ETH_RSS_NONFRAG_IPV4_TCP |
+ ETH_RSS_NONFRAG_IPV4_SCTP |
+ ETH_RSS_NONFRAG_IPV4_OTHER |
+ ETH_RSS_FRAG_IPV4;
+
+   const uint64_t ipv6_rss = ETH_RSS_NONFRAG_IPV6_UDP |
+ ETH_RSS_NONFRAG_IPV6_TCP |
+ ETH_RSS_NONFRAG_IPV6_SCTP |
+ ETH_RSS_NONFRAG_IPV6_OTHER |
+ ETH_RSS_FRAG_IPV6;
+
+   struct iavf_info *vf =  IAVF_DEV_PRIVATE_TO_VF(adapter);
+   uint64_t caps = 0, hena = 0, valid_rss_hf = 0;
+   uint32_t i;
+   int ret;
+
+   ret = iavf_get_hena_caps(adapter, &caps);
+   if (ret)
+   return ret;
+   /**
+* ETH_RSS_IPV4 and ETH_RSS_IPV6 can be considered as 2
+* generalizations of all other IPv4 and IPv6 RSS types.
+*/
+   if (rss_hf & ETH_RSS_IPV4)
+   rss_hf |= ipv4_rss;
+
+   if (rss_hf & ETH_RSS_IPV6)
+   rss_hf |= ipv6

[dpdk-dev] [PATCH] net/ice: fix mbuf fast freeing

[Alvin Zhang]

As i40e support per queue MBUF_FAST_FREE, ice should have the
same implemenation.

Fixes: 6eac0b7fde95 ("net/ice: support advance Rx/Tx")
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 
---
 drivers/net/ice/ice_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index f0dc543..d4f0c3f 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -3530,7 +3530,7 @@ static int ice_init_rss(struct ice_pf *pf)
}
 
dev_info->rx_queue_offload_capa = 0;
-   dev_info->tx_queue_offload_capa = 0;
+   dev_info->tx_queue_offload_capa = DEV_TX_OFFLOAD_MBUF_FAST_FREE;
 
dev_info->reta_size = pf->hash_lut_size;
dev_info->hash_key_size = (VSIQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v6] net/iavf: fix RSS configuration on i40e VF

[Xing, Beilei]

> -Original Message-
> From: Zhang, AlvinX 
> Sent: Sunday, April 25, 2021 1:09 PM
> To: Wu, Jingjing ; Xing, Beilei 
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [PATCH v6] net/iavf: fix RSS configuration on i40e VF
> 
> The iavf does not support configuring RSS type on i40e VF, because the i40e
> kernel driver does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF
> capability.
> 
> This patch adds support of RSS type configuration for i40e VF by sending
> VIRTCHNL_OP_SET_RSS_HENA message to the PF after checking that the PF
> does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.
> 
> Fixes: c678299594a8 ("net/iavf: fix default RSS configuration")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Alvin Zhang 
> ---

Acked-by: Beilei Xing 

[dpdk-dev] [PATCH v2] net/ice: fix mbuf fast freeing

[Alvin Zhang]

As i40e support per queue MBUF_FAST_FREE, ice should have the
same implementation.

Fixes: 6eac0b7fde95 ("net/ice: support advance Rx/Tx")
Cc: sta...@dpdk.org

Signed-off-by: Alvin Zhang 
---
 drivers/net/ice/ice_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index f0dc543..d4f0c3f 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -3530,7 +3530,7 @@ static int ice_init_rss(struct ice_pf *pf)
}
 
dev_info->rx_queue_offload_capa = 0;
-   dev_info->tx_queue_offload_capa = 0;
+   dev_info->tx_queue_offload_capa = DEV_TX_OFFLOAD_MBUF_FAST_FREE;
 
dev_info->reta_size = pf->hash_lut_size;
dev_info->hash_key_size = (VSIQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v6] net/iavf: fix RSS configuration on i40e VF

[Zhang, Qi Z]

> -Original Message-
> From: dev  On Behalf Of Xing, Beilei
> Sent: Sunday, April 25, 2021 1:17 PM
> To: Zhang, AlvinX ; Wu, Jingjing
> 
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6] net/iavf: fix RSS configuration on i40e VF
> 
> 
> 
> > -Original Message-
> > From: Zhang, AlvinX 
> > Sent: Sunday, April 25, 2021 1:09 PM
> > To: Wu, Jingjing ; Xing, Beilei
> > 
> > Cc: dev@dpdk.org; Zhang, AlvinX ;
> > sta...@dpdk.org
> > Subject: [PATCH v6] net/iavf: fix RSS configuration on i40e VF
> >
> > The iavf does not support configuring RSS type on i40e VF, because the
> > i40e kernel driver does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF
> > capability.
> >
> > This patch adds support of RSS type configuration for i40e VF by
> > sending VIRTCHNL_OP_SET_RSS_HENA message to the PF after checking that
> > the PF does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.
> >
> > Fixes: c678299594a8 ("net/iavf: fix default RSS configuration")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Alvin Zhang 
> > ---
> 
> Acked-by: Beilei Xing 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH v2] net/ice: fix mbuf fast freeing

[Zhang, Qi Z]

> -Original Message-
> From: Zhang, AlvinX 
> Sent: Sunday, April 25, 2021 1:19 PM
> To: Zhang, Qi Z 
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [PATCH v2] net/ice: fix mbuf fast freeing
> 
> As i40e support per queue MBUF_FAST_FREE, ice should have the same
> implementation.

The change should not related with i40e, changed to:

MBUF_FAST_FREE should be supported as per queue offload for ice.

> 
> Fixes: 6eac0b7fde95 ("net/ice: support advance Rx/Tx")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Alvin Zhang 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

[dpdk-dev] [PATCH v3 1/2] spinlock: use wfe to reduce contention on aarch64

[Ruifeng Wang]

From: Gavin Hu 

In acquiring a spinlock, cores repeatedly poll the lock variable.
This is replaced by rte_wait_until_equal API.

Running the micro benchmarking and the testpmd and l3fwd traffic tests
on ThunderX2, Ampere eMAG80 and Arm N1SDP, everything went well and no
notable performance gain nor degradation was measured.

Signed-off-by: Gavin Hu 
Reviewed-by: Ruifeng Wang 
Reviewed-by: Phil Yang 
Reviewed-by: Steve Capper 
Reviewed-by: Ola Liljedahl 
Reviewed-by: Honnappa Nagarahalli 
Tested-by: Pavan Nikhilesh 
Acked-by: Konstantin Ananyev 
Acked-by: Jerin Jacob 
---
 lib/eal/include/generic/rte_spinlock.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/eal/include/generic/rte_spinlock.h 
b/lib/eal/include/generic/rte_spinlock.h
index 87ae7a4f18..40fe49d5ad 100644
--- a/lib/eal/include/generic/rte_spinlock.h
+++ b/lib/eal/include/generic/rte_spinlock.h
@@ -65,8 +65,8 @@ rte_spinlock_lock(rte_spinlock_t *sl)
 
while (!__atomic_compare_exchange_n(&sl->locked, &exp, 1, 0,
__ATOMIC_ACQUIRE, __ATOMIC_RELAXED)) {
-   while (__atomic_load_n(&sl->locked, __ATOMIC_RELAXED))
-   rte_pause();
+   rte_wait_until_equal_32((volatile uint32_t *)&sl->locked,
+  0, __ATOMIC_RELAXED);
exp = 0;
}
 }
-- 
2.25.1

[dpdk-dev] Use WFE for spinlock and ring

[Ruifeng Wang]

The rte_wait_until_equal_xxx APIs abstract the functionality of 'polling
for a memory location to become equal to a given value'[1].

Use the API for the rte spinlock and ring implementations.
With the wait until equal APIs being stable, changes will not impact ABI.

[1] http://patches.dpdk.org/cover/62703/

v3:
Series rebased. (David)

Gavin Hu (1):
  spinlock: use wfe to reduce contention on aarch64

Ruifeng Wang (1):
  ring: use wfe to wait for ring tail update on aarch64

 lib/eal/include/generic/rte_spinlock.h | 4 ++--
 lib/ring/rte_ring_c11_pvt.h| 4 ++--
 lib/ring/rte_ring_generic_pvt.h| 3 +--
 3 files changed, 5 insertions(+), 6 deletions(-)

-- 
2.25.1

[dpdk-dev] [PATCH v3 2/2] ring: use wfe to wait for ring tail update on aarch64

[Ruifeng Wang]

Instead of polling for tail to be updated, use wfe instruction.

Signed-off-by: Gavin Hu 
Signed-off-by: Ruifeng Wang 
Reviewed-by: Steve Capper 
Reviewed-by: Ola Liljedahl 
Reviewed-by: Honnappa Nagarahalli 
Acked-by: Konstantin Ananyev 
---
 lib/ring/rte_ring_c11_pvt.h | 4 ++--
 lib/ring/rte_ring_generic_pvt.h | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/lib/ring/rte_ring_c11_pvt.h b/lib/ring/rte_ring_c11_pvt.h
index 759192f4c4..37e0b2afd6 100644
--- a/lib/ring/rte_ring_c11_pvt.h
+++ b/lib/ring/rte_ring_c11_pvt.h
@@ -2,6 +2,7 @@
  *
  * Copyright (c) 2017,2018 HXT-semitech Corporation.
  * Copyright (c) 2007-2009 Kip Macy km...@freebsd.org
+ * Copyright (c) 2021 Arm Limited
  * All rights reserved.
  * Derived from FreeBSD's bufring.h
  * Used as BSD-3 Licensed with permission from Kip Macy.
@@ -21,8 +22,7 @@ __rte_ring_update_tail(struct rte_ring_headtail *ht, uint32_t 
old_val,
 * we need to wait for them to complete
 */
if (!single)
-   while (unlikely(ht->tail != old_val))
-   rte_pause();
+   rte_wait_until_equal_32(&ht->tail, old_val, __ATOMIC_RELAXED);
 
__atomic_store_n(&ht->tail, new_val, __ATOMIC_RELEASE);
 }
diff --git a/lib/ring/rte_ring_generic_pvt.h b/lib/ring/rte_ring_generic_pvt.h
index 532deb5e7a..c95ad7e12c 100644
--- a/lib/ring/rte_ring_generic_pvt.h
+++ b/lib/ring/rte_ring_generic_pvt.h
@@ -23,8 +23,7 @@ __rte_ring_update_tail(struct rte_ring_headtail *ht, uint32_t 
old_val,
 * we need to wait for them to complete
 */
if (!single)
-   while (unlikely(ht->tail != old_val))
-   rte_pause();
+   rte_wait_until_equal_32(&ht->tail, old_val, __ATOMIC_RELAXED);
 
ht->tail = new_val;
 }
-- 
2.25.1

Re: [dpdk-dev] [PATCH] net/iavf: fix PF returning error

[Xing, Beilei]

> -Original Message-
> From: Zhang, AlvinX 
> Sent: Sunday, April 25, 2021 1:05 PM
> To: Wu, Jingjing ; Xing, Beilei 
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [PATCH] net/iavf: fix PF returning error
> 
> When the command sent by VF to PF fails, iavf may need to run different code
> paths according to the specific reason of the failure (not supported or other
> reasons).
> 
> This patch adds support of identifying PF return error type.
> 
> Fixes: 22b123a36d07 ("net/avf: initialize PMD")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Alvin Zhang 
> ---
>  drivers/net/iavf/iavf_vchnl.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c 
> index
> 45096cb..6586fc3 100644
> --- a/drivers/net/iavf/iavf_vchnl.c
> +++ b/drivers/net/iavf/iavf_vchnl.c
> @@ -228,13 +228,19 @@
>   rte_delay_ms(ASQ_DELAY_MS);
>   /* If don't read msg or read sys event, continue */
>   } while (i++ < MAX_TRY_TIMES);
> - /* If there's no response is received, clear command */
> - if (i >= MAX_TRY_TIMES  ||
> - vf->cmd_retval != VIRTCHNL_STATUS_SUCCESS) {
> - err = -1;
> - PMD_DRV_LOG(ERR, "No response or return failure
> (%d)"
> - " for cmd %d", vf->cmd_retval, args->ops);
> +
> + if (i >= MAX_TRY_TIMES) {
> + PMD_DRV_LOG(ERR, "No response for cmd %d", args-
> >ops);
>   _clear_cmd(vf);
> + err = -EIO;
> + } else if (vf->cmd_retval ==
> +(uint32_t)VIRTCHNL_STATUS_ERR_NOT_SUPPORTED)

Can we change 'uint32_t cmd_retval' to 'enum virtchnl_status_code cmd_retval' 
in iavf_info structure? Then we needn't cast here.

> {
> + PMD_DRV_LOG(ERR, "Cmd %d not supported", args-
> >ops);
> + err = -ENOTSUP;
> + } else if (vf->cmd_retval != VIRTCHNL_STATUS_SUCCESS) {
> + PMD_DRV_LOG(ERR, "Return failure %d for cmd %d",
> + vf->cmd_retval, args->ops);
> + err = -EINVAL;
>   }
>   break;
>   }
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH v2 0/2] Use WFE for spinlock and ring

[Ruifeng Wang]

> -Original Message-
> From: David Marchand 
> Sent: Thursday, March 25, 2021 10:58 PM
> To: Honnappa Nagarahalli 
> Cc: dev ; nd ; tho...@monjalon.net;
> jer...@marvell.com; Ruifeng Wang ; Phil Yang
> ; Joyce Kong ; Ananyev,
> Konstantin 
> Subject: Re: [dpdk-dev] [PATCH v2 0/2] Use WFE for spinlock and ring
> 
> Hello,
> 
> On Fri, Sep 25, 2020 at 4:30 PM David Marchand
>  wrote:
> >
> > Hello Honnappa,
> >
> > On Sun, May 3, 2020 at 11:32 PM Honnappa Nagarahalli
> >  wrote:
> > >
> > > 
> > >
> > > > Subject: Re: [PATCH v2 0/2] Use WFE for spinlock and ring
> > > >
> > > > On Sun, Apr 26, 2020 at 10:39 AM Gavin Hu  wrote:
> > > > >
> > > > > The rte_wait_until_equal_xxx APIs abstract the functionality of
> > > > > 'polling for a memory location to become equal to a given value'[1].
> > > > >
> > > > > Use the API for the rte spinlock and ring implementations.
> > > > >
> > > > > [1] http://patches.dpdk.org/cover/62703/
> > > > >
> > > > > Gavin Hu (2):
> > > > >   spinlock: use wfe to reduce contention on aarch64
> > > > >   ring: use wfe to wait for ring tail update on aarch64
> > > >
> > > > This would result in rte_ring and rte_spinlock APIs becoming
> > > > experimental and this breaks compilation for external applications
> > > > using stable ring and spinlock APIs.
> > > > IIRC, it was the reason why these patches were dropped with the
> > > > introduction of the rte_wait_until_equal_* API.
> > > Agreed, the rte_ring new sync modes are resulting in different use cases
> for these APIs. We need to take a relook at the APIs.
> >
> > Will we reconsider this series now that the wait until equal is going 
> > stable?
> 
> Any update?
> I suppose this would need some rebasing after the ring library changes.

Sorry for the late response.
This series has been rebased and v3 posted.
I have problem to mark v2 as superseded.

Thank you.
> 
> Thanks.
> 
> 
> --
> David Marchand

Re: [dpdk-dev] [PATCH v2] doc: fix formatting in testpmd user guide

[Bing Zhao]

Hi,

> -Original Message-
> From: Ferruh Yigit 
> Sent: Saturday, April 24, 2021 12:30 AM
> To: Xiaoyun Li ; Ori Kam ;
> Bing Zhao 
> Cc: Ferruh Yigit ; dev@dpdk.org; Ajit
> Khaparde 
> Subject: [PATCH v2] doc: fix formatting in testpmd user guide
> 
> External email: Use caution opening links or attachments
> 
> 
> From: Ajit Khaparde 
> 
> Fix formatting in testpmd user guide for hairpin operation.
> 
> Fixes: 01817b10d27c ("app/testpmd: change hairpin queues setup")
> Cc:sta...@dpdk.org
> 
> Signed-off-by: Ajit Khaparde 
> ---
> Cc: Bing Zhao 
> Cc: Ori Kam 
> 
> v2:
> * Fix only list formatting
> ---
>  doc/guides/testpmd_app_ug/run_app.rst | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
> b/doc/guides/testpmd_app_ug/run_app.rst
> index d0621658ae64..eb4831835322 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -538,8 +538,10 @@ The command line options are:
> 
>  *   ``--hairpin-mode=0xXX``
> 
> -Set the hairpin port mode with bitmask, only valid when hairpin
> queues number is set.
> -bit 4 - explicit Tx flow rule
> -bit 1 - two hairpin ports paired
> -bit 0 - two hairpin ports loop
> +Set the hairpin port mode with bitmask, only valid when hairpin
> queues number is set::
> +
> +   bit 4 - explicit Tx flow rule
> +   bit 1 - two hairpin ports paired
> +   bit 0 - two hairpin ports loop
> +
>  The default value is 0. Hairpin will use single port mode and
> implicit Tx flow mode.
> --
> 2.30.2

Reviewed-by: Bing Zhao 

[dpdk-dev] [PATCH v2] common/iavf: fix wrong order of protocol header types

[Ting Xu]

The new virtchnl protocol header types for IPv4 and IPv6 fragment are
not added in order, which will break ABI. Move them to the end of the
list.

Signed-off-by: Ting Xu 
Fixes: e6a42fd9158b ("common/iavf: add protocol header for IP fragment")
Cc: sta...@dpdk.org
---
 drivers/common/iavf/virtchnl.h | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/common/iavf/virtchnl.h b/drivers/common/iavf/virtchnl.h
index 139569787f..42ea91a6b0 100644
--- a/drivers/common/iavf/virtchnl.h
+++ b/drivers/common/iavf/virtchnl.h
@@ -1415,9 +1415,7 @@ enum virtchnl_proto_hdr_type {
VIRTCHNL_PROTO_HDR_S_VLAN,
VIRTCHNL_PROTO_HDR_C_VLAN,
VIRTCHNL_PROTO_HDR_IPV4,
-   VIRTCHNL_PROTO_HDR_IPV4_FRAG,
VIRTCHNL_PROTO_HDR_IPV6,
-   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG,
VIRTCHNL_PROTO_HDR_TCP,
VIRTCHNL_PROTO_HDR_UDP,
VIRTCHNL_PROTO_HDR_SCTP,
@@ -1434,6 +1432,12 @@ enum virtchnl_proto_hdr_type {
VIRTCHNL_PROTO_HDR_ECPRI,
VIRTCHNL_PROTO_HDR_L2TPV2,
VIRTCHNL_PROTO_HDR_PPP,
+   /* IPv4 and IPv6 Fragment header types are only associated to
+* VIRTCHNL_PROTO_HDR_IPV4 and VIRTCHNL_PROTO_HDR_IPV6 respectively,
+* cannot be used independently.
+*/
+   VIRTCHNL_PROTO_HDR_IPV4_FRAG,
+   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG,
 };
 
 /* Protocol header field within a protocol header. */
@@ -1456,8 +1460,6 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_IPV4_DSCP,
VIRTCHNL_PROTO_HDR_IPV4_TTL,
VIRTCHNL_PROTO_HDR_IPV4_PROT,
-   VIRTCHNL_PROTO_HDR_IPV4_FRAG_PKID =
-   PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV4_FRAG),
/* IPV6 */
VIRTCHNL_PROTO_HDR_IPV6_SRC =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV6),
@@ -1478,9 +1480,6 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST,
VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_SRC,
VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_DST,
-   /* IPv6 Extension Header Fragment */
-   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID =
-   PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG),
/* TCP */
VIRTCHNL_PROTO_HDR_TCP_SRC_PORT =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_TCP),
@@ -1523,6 +1522,12 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_ECPRI_MSG_TYPE =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_ECPRI),
VIRTCHNL_PROTO_HDR_ECPRI_PC_RTC_ID,
+   /* IPv4 Dummy Fragment */
+   VIRTCHNL_PROTO_HDR_IPV4_FRAG_PKID =
+   PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV4_FRAG),
+   /* IPv6 Extension Fragment */
+   VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG_PKID =
+   PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_IPV6_EH_FRAG),
 };
 
 struct virtchnl_proto_hdr {
-- 
2.17.1