[PATCH v3] mempool: test performance with larger bursts

[Morten Brørup]

Bursts of up to 64 or 128 packets are not uncommon, so increase the
maximum tested get and put burst sizes from 32 to 128.
For convenience, also test get and put burst sizes of
RTE_MEMPOOL_CACHE_MAX_SIZE.

Some applications keep more than 512 objects, so increase the maximum
number of kept objects from 512 to 32768, still in jumps of factor four.
This exceeds the typical mempool cache size of 512 objects, so the test
also exercises the mempool driver.

Signed-off-by: Morten Brørup 
---

v3:
* Increased max number of kept objects to 32768.
* Added get and put burst sizes of RTE_MEMPOOL_CACHE_MAX_SIZE objects.
* Print error if unable to allocate mempool.
* Initialize use_external_cache with each test.
  A previous version of this patch had a bug, where all test runs
  following the first would use external cache. (Chengwen Feng)
v2: Addressed feedback by Chengwen Feng
* Added get and put burst sizes of 64 objects, which is probably also not
  uncommon packet burst size.
* Fixed list of number of kept objects so list remains in jumps of factor
  four.
* Added three derivative test cases, for faster testing.
---
 app/test/test_mempool_perf.c | 42 ++--
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index a5a7d43608..481263186a 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -54,9 +54,9 @@
  *
  *- Bulk size (*n_get_bulk*, *n_put_bulk*)
  *
- *  - Bulk get from 1 to 128
- *  - Bulk put from 1 to 128
- *  - Bulk get and put from 1 to 128, compile time constant
+ *  - Bulk get from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk get and put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE, 
compile time constant
  *
  *- Number of kept objects (*n_keep*)
  *
@@ -65,12 +65,13 @@
  *  - 512
  *  - 2048
  *  - 8192
+ *  - 32768
  */
 
-#define N 65536
+#define N 262144
 #define TIME_S 5
 #define MEMPOOL_ELT_SIZE 2048
-#define MAX_KEEP 8192
+#define MAX_KEEP 32768
 #define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE*2))-1)
 
 /* Number of pointers fitting into one cache line. */
@@ -210,6 +211,9 @@ per_lcore_mempool_test(void *arg)
ret = test_loop(mp, cache, n_keep, 64, 64);
else if (n_get_bulk == 128)
ret = test_loop(mp, cache, n_keep, 128, 128);
+   else if (n_get_bulk == RTE_MEMPOOL_CACHE_MAX_SIZE)
+   ret = test_loop(mp, cache, n_keep,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 
RTE_MEMPOOL_CACHE_MAX_SIZE);
else
ret = -1;
 
@@ -293,11 +297,13 @@ launch_cores(struct rte_mempool *mp, unsigned int cores)
 
 /* for a given number of core, launch all test cases */
 static int
-do_one_mempool_test(struct rte_mempool *mp, unsigned int cores)
+do_one_mempool_test(struct rte_mempool *mp, unsigned int cores, int 
external_cache)
 {
-   unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128, 0 
};
-   unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128, 0 
};
-   unsigned int keep_tab[] = { 32, 128, 512, 2048, 8192, 0 };
+   unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 0 };
+   unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 0 };
+   unsigned int keep_tab[] = { 32, 128, 512, 2048, 8192, 32768, 0 };
unsigned *get_bulk_ptr;
unsigned *put_bulk_ptr;
unsigned *keep_ptr;
@@ -310,6 +316,7 @@ do_one_mempool_test(struct rte_mempool *mp, unsigned int 
cores)
if (*keep_ptr < *get_bulk_ptr || *keep_ptr < 
*put_bulk_ptr)
continue;
 
+   use_external_cache = external_cache;
use_constant_values = 0;
n_get_bulk = *get_bulk_ptr;
n_put_bulk = *put_bulk_ptr;
@@ -346,8 +353,10 @@ do_all_mempool_perf_tests(unsigned int cores)
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
-   if (mp_nocache == NULL)
+   if (mp_nocache == NULL) {
+   printf("cannot allocate mempool (without cache)\n");
goto err;
+   }
 
/* create a mempool (with cache) */
mp_cache = rte_mempool_create("perf_test_cache", MEMPOOL_SIZE,
@@ -356,8 +365,10 @@ do_all_mempool_perf_tests(unsigned int cores)
  NULL, NULL,
  my_obj_init, NULL,
  SOCKET_ID_ANY, 

[PATCH v4] mempool: test performance with larger bursts

[Morten Brørup]

Bursts of up to 64 or 128 packets are not uncommon, so increase the
maximum tested get and put burst sizes from 32 to 128.
For convenience, also test get and put burst sizes of
RTE_MEMPOOL_CACHE_MAX_SIZE.

Some applications keep more than 512 objects, so increase the maximum
number of kept objects from 512 to 32768, still in jumps of factor four.
This exceeds the typical mempool cache size of 512 objects, so the test
also exercises the mempool driver.

Signed-off-by: Morten Brørup 
Acked-by: Chengwen Feng 
---

v4:
* v3 failed to apply; I had messed up something with git.
* Added ACK from Chengwen Feng.
v3:
* Increased max number of kept objects to 32768.
* Added get and put burst sizes of RTE_MEMPOOL_CACHE_MAX_SIZE objects.
* Print error if unable to allocate mempool.
* Initialize use_external_cache with each test.
  A previous version of this patch had a bug, where all test runs
  following the first would use external cache. (Chengwen Feng)
v2: Addressed feedback by Chengwen Feng
* Added get and put burst sizes of 64 objects, which is probably also not
  uncommon packet burst size.
* Fixed list of number of kept objects so list remains in jumps of factor
  four.
* Added three derivative test cases, for faster testing.
---
 app/test/test_mempool_perf.c | 125 +--
 1 file changed, 76 insertions(+), 49 deletions(-)

diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index 96de347f04..481263186a 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2010-2014 Intel Corporation
- * Copyright(c) 2022 SmartShare Systems
+ * Copyright(c) 2022-2024 SmartShare Systems
  */
 
 #include 
@@ -54,22 +54,25 @@
  *
  *- Bulk size (*n_get_bulk*, *n_put_bulk*)
  *
- *  - Bulk get from 1 to 32
- *  - Bulk put from 1 to 32
- *  - Bulk get and put from 1 to 32, compile time constant
+ *  - Bulk get from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk get and put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE, 
compile time constant
  *
  *- Number of kept objects (*n_keep*)
  *
  *  - 32
  *  - 128
  *  - 512
+ *  - 2048
+ *  - 8192
+ *  - 32768
  */
 
-#define N 65536
+#define N 262144
 #define TIME_S 5
 #define MEMPOOL_ELT_SIZE 2048
-#define MAX_KEEP 512
-#define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE))-1)
+#define MAX_KEEP 32768
+#define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE*2))-1)
 
 /* Number of pointers fitting into one cache line. */
 #define CACHE_LINE_BURST (RTE_CACHE_LINE_SIZE / sizeof(uintptr_t))
@@ -204,6 +207,13 @@ per_lcore_mempool_test(void *arg)
CACHE_LINE_BURST, CACHE_LINE_BURST);
else if (n_get_bulk == 32)
ret = test_loop(mp, cache, n_keep, 32, 32);
+   else if (n_get_bulk == 64)
+   ret = test_loop(mp, cache, n_keep, 64, 64);
+   else if (n_get_bulk == 128)
+   ret = test_loop(mp, cache, n_keep, 128, 128);
+   else if (n_get_bulk == RTE_MEMPOOL_CACHE_MAX_SIZE)
+   ret = test_loop(mp, cache, n_keep,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 
RTE_MEMPOOL_CACHE_MAX_SIZE);
else
ret = -1;
 
@@ -287,11 +297,13 @@ launch_cores(struct rte_mempool *mp, unsigned int cores)
 
 /* for a given number of core, launch all test cases */
 static int
-do_one_mempool_test(struct rte_mempool *mp, unsigned int cores)
+do_one_mempool_test(struct rte_mempool *mp, unsigned int cores, int 
external_cache)
 {
-   unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 0 };
-   unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 0 };
-   unsigned int keep_tab[] = { 32, 128, 512, 0 };
+   unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 0 };
+   unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 64, 128,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 0 };
+   unsigned int keep_tab[] = { 32, 128, 512, 2048, 8192, 32768, 0 };
unsigned *get_bulk_ptr;
unsigned *put_bulk_ptr;
unsigned *keep_ptr;
@@ -301,6 +313,10 @@ do_one_mempool_test(struct rte_mempool *mp, unsigned int 
cores)
for (put_bulk_ptr = bulk_tab_put; *put_bulk_ptr; 
put_bulk_ptr++) {
for (keep_ptr = keep_tab; *keep_ptr; keep_ptr++) {
 
+   if (*keep_ptr < *get_bulk_ptr || *keep_ptr < 
*put_bulk_ptr)
+   continue;
+
+   use_external_cache = external_cache;
use_constant_values = 0;
   

DPDK 22.11.4 released

[Xueming Li]

Hi all,

Here is a new stable release:
https://fast.dpdk.org/rel/dpdk-22.11.4.tar.xz

The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=22.11

Many thanks to the people who backport patches and fix issues, also the test 
team!

Xueming Li 

---
 .github/workflows/build.yml|5 +-
 .mailmap   |   18 +-
 VERSION|2 +-
 app/dumpcap/main.c |   28 +-
 app/proc-info/main.c   |   42 +-
 app/test-bbdev/meson.build |2 +-
 app/test-bbdev/test-bbdev.py   |   29 +-
 app/test-bbdev/test_bbdev.c|3 +-
 app/test-pipeline/main.c   |   14 +
 app/test-pipeline/main.h   |2 +
 app/test-pipeline/pipeline_acl.c   |6 +-
 app/test-pipeline/pipeline_hash.c  |  110 +-
 app/test-pipeline/pipeline_lpm.c   |6 +-
 app/test-pipeline/pipeline_lpm_ipv6.c  |6 +-
 app/test-pipeline/pipeline_stub.c  |6 +-
 app/test-pipeline/runtime.c|  132 +-
 app/test-pmd/cmdline.c |  112 +-
 app/test-pmd/testpmd.c |   50 +-
 app/test/meson.build   |6 +-
 app/test/test.h|2 +-
 app/test/test_cryptodev.c  |   91 +-
 app/test/test_cryptodev_asym.c |4 +-
 app/test/test_cryptodev_mixed_test_vectors.h   |8 +-
 app/test/test_event_crypto_adapter.c   |7 +-
 app/test/test_hash_readwrite.c |2 +-
 app/test/test_link_bonding.c   |5 +-
 app/test/test_link_bonding_mode4.c |3 +-
 app/test/test_link_bonding_rssconf.c   |2 +-
 app/test/test_security_inline_proto.c  |   78 +-
 app/test/test_security_inline_proto_vectors.h  |4 +-
 config/arm/meson.build |   40 +-
 config/meson.build |7 +-
 doc/guides/cryptodevs/qat.rst  |4 +-
 doc/guides/nics/hns3.rst   |   55 +-
 doc/guides/nics/i40e.rst   |   17 +-
 doc/guides/nics/ice.rst|   11 +-
 doc/guides/nics/ixgbe.rst  |2 -
 doc/guides/nics/mlx5.rst   |8 +-
 doc/guides/nics/virtio.rst |   12 +
 doc/guides/platform/cnxk.rst   |3 +
 .../generic_segmentation_offload_lib.rst   |2 +-
 doc/guides/prog_guide/rte_security.rst |   65 +-
 doc/guides/rel_notes/release_22_11.rst |  372 +++
 doc/guides/sample_app_ug/vdpa.rst  |3 +-
 doc/guides/tools/pmdinfo.rst   |2 +-
 drivers/baseband/acc/rte_acc100_pmd.c  |2 +-
 drivers/baseband/acc/rte_acc200_pmd.c  |3 +-
 drivers/bus/dpaa/base/qbman/qman.c |5 +-
 drivers/bus/ifpga/bus_ifpga_driver.h   |1 +
 drivers/bus/pci/pci_common.c   |   12 +-
 drivers/bus/pci/rte_bus_pci.h  |   14 +
 drivers/bus/pci/version.map|1 +
 drivers/common/cnxk/cnxk_security_ar.h |2 +-
 drivers/common/cnxk/hw/nix.h   |1 +
 drivers/common/cnxk/meson.build|1 -
 drivers/common/cnxk/roc_dpi.c  |6 +-
 drivers/common/cnxk/roc_mbox.h |2 +-
 drivers/common/cnxk/roc_nix_inl_dev.c  |3 +-
 drivers/common/cnxk/roc_npa.c  |8 +-
 drivers/common/cnxk/roc_npc.c  |   55 +-
 drivers/common/cnxk/roc_npc.h  |2 +
 drivers/common/cnxk/roc_npc_mcam_dump.c|4 +
 drivers/common/cnxk/roc_ree.c  |4 +-
 drivers/common/cnxk/roc_ree.h  |2 +-
 drivers/common/cnxk/version.map|1 +
 drivers/common/mlx5/linux/mlx5_common_os.c |7 +-
 drivers/common/mlx5/mlx5_devx_cmds.c   |3 +-
 drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c  |8 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c|4 +-
 drivers/crypto/dpaa_sec/dpaa_sec.c |6 +-
 drivers/crypto/ipsec_mb/meson.build|5 +
 drivers/crypto/nitrox/nitrox_sym_reqmgr.c  |   21 +-
 drivers/crypto/openssl/openssl_pmd_private.h   |6 +
 drivers/crypto/openssl/rte_openssl_pmd.c   |1 +
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   |   96 +-
 drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c   |   19 +-
 drivers/crypto/qat/dev/qat_sym_

[PATCH 0/4] enhance NFP service framework

[Chaoyong He]

Make multiple devices can use single core to run services for
flower firmware.
Also add synchronize module and service module to support it. 

Long Wu (4):
  net/nfp: add synchronize module
  net/nfp: create new service code related files
  net/nfp: flower driver uses one service core
  net/nfp: fix stop cpp service problem

 drivers/net/nfp/flower/nfp_flower.c   |  56 +--
 drivers/net/nfp/flower/nfp_flower_ctrl.c  |  20 +-
 drivers/net/nfp/flower/nfp_flower_ctrl.h  |   2 +-
 .../net/nfp/flower/nfp_flower_representor.c   |   7 +
 drivers/net/nfp/flower/nfp_flower_service.c   | 196 +
 drivers/net/nfp/flower/nfp_flower_service.h   |  17 +
 drivers/net/nfp/meson.build   |   3 +
 drivers/net/nfp/nfp_cpp_bridge.c  |  91 +
 drivers/net/nfp/nfp_cpp_bridge.h  |   1 -
 drivers/net/nfp/nfp_ethdev.c  |  31 +-
 drivers/net/nfp/nfp_net_common.h  |  15 +-
 drivers/net/nfp/nfp_service.c | 117 ++
 drivers/net/nfp/nfp_service.h |  20 +
 drivers/net/nfp/nfpcore/nfp_sync.c| 382 ++
 drivers/net/nfp/nfpcore/nfp_sync.h|  31 ++
 15 files changed, 854 insertions(+), 135 deletions(-)
 create mode 100644 drivers/net/nfp/flower/nfp_flower_service.c
 create mode 100644 drivers/net/nfp/flower/nfp_flower_service.h
 create mode 100644 drivers/net/nfp/nfp_service.c
 create mode 100644 drivers/net/nfp/nfp_service.h
 create mode 100644 drivers/net/nfp/nfpcore/nfp_sync.c
 create mode 100644 drivers/net/nfp/nfpcore/nfp_sync.h

-- 
2.39.1

[PATCH 1/4] net/nfp: add synchronize module

[Chaoyong He]

From: Long Wu 

PMD has some information that needs synchronized:
1. Between devices in one process.
2. Between multiple processes for one device, before creating
"rte_eth_device".
3. Between multiple processes for one device, after creating
"rte_eth_device".

The final one is already support by framework
(eth_dev->data->dev_private), and this patch aims to support
the first two cases by adding a synchronize module.

Signed-off-by: Long Wu 
Reviewed-by: Chaoyong He 
Reviewed-by: Peng Zhang 
---
 drivers/net/nfp/meson.build|   1 +
 drivers/net/nfp/nfp_ethdev.c   |  31 ++-
 drivers/net/nfp/nfp_net_common.h   |   4 +
 drivers/net/nfp/nfpcore/nfp_sync.c | 382 +
 drivers/net/nfp/nfpcore/nfp_sync.h |  29 +++
 5 files changed, 444 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/nfp/nfpcore/nfp_sync.c
 create mode 100644 drivers/net/nfp/nfpcore/nfp_sync.h

diff --git a/drivers/net/nfp/meson.build b/drivers/net/nfp/meson.build
index 46be6f60cd..c625355d7a 100644
--- a/drivers/net/nfp/meson.build
+++ b/drivers/net/nfp/meson.build
@@ -26,6 +26,7 @@ sources = files(
 'nfpcore/nfp_nsp_eth.c',
 'nfpcore/nfp_resource.c',
 'nfpcore/nfp_rtsym.c',
+'nfpcore/nfp_sync.c',
 'nfpcore/nfp_target.c',
 'nfpcore/nfp6000_pcie.c',
 'nfp_cpp_bridge.c',
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 07cd32881c..3ece806487 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -19,6 +19,7 @@
 #include "nfpcore/nfp_nsp.h"
 #include "nfpcore/nfp6000_pcie.h"
 #include "nfpcore/nfp_resource.h"
+#include "nfpcore/nfp_sync.h"
 
 #include "nfp_cpp_bridge.h"
 #include "nfp_ipsec.h"
@@ -551,6 +552,7 @@ nfp_pf_uninit(struct nfp_pf_dev *pf_dev)
free(pf_dev->nfp_eth_table);
free(pf_dev->hwinfo);
nfp_cpp_free(pf_dev->cpp);
+   nfp_sync_free(pf_dev->sync);
rte_free(pf_dev);
 }
 
@@ -559,6 +561,7 @@ nfp_pf_secondary_uninit(struct nfp_pf_dev *pf_dev)
 {
free(pf_dev->sym_tbl);
nfp_cpp_free(pf_dev->cpp);
+   nfp_sync_free(pf_dev->sync);
rte_free(pf_dev);
 
return 0;
@@ -1612,6 +1615,7 @@ nfp_net_speed_capa_get(struct nfp_pf_dev *pf_dev,
 static int
 nfp_pf_init(struct rte_pci_device *pci_dev)
 {
+   void *sync;
uint32_t i;
uint32_t id;
int ret = 0;
@@ -1652,6 +1656,13 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
return -ENOMEM;
}
 
+   sync = nfp_sync_alloc();
+   if (sync == NULL) {
+   PMD_INIT_LOG(ERR, "Failed to alloc sync zone.");
+   ret = -ENOMEM;
+   goto pf_cleanup;
+   }
+
/*
 * When device bound to UIO, the device could be used, by mistake,
 * by two DPDK apps, and the UIO driver does not avoid it. This
@@ -1667,7 +1678,7 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
if (cpp == NULL) {
PMD_INIT_LOG(ERR, "A CPP handle can not be obtained");
ret = -EIO;
-   goto pf_cleanup;
+   goto sync_free;
}
 
hwinfo = nfp_hwinfo_read(cpp);
@@ -1734,6 +1745,7 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
pf_dev->sym_tbl = sym_tbl;
pf_dev->pci_dev = pci_dev;
pf_dev->nfp_eth_table = nfp_eth_table;
+   pf_dev->sync = sync;
 
/* Get the speed capability */
for (i = 0; i < nfp_eth_table->count; i++) {
@@ -1815,6 +1827,8 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
free(hwinfo);
 cpp_cleanup:
nfp_cpp_free(cpp);
+sync_free:
+   nfp_sync_free(sync);
 pf_cleanup:
rte_free(pf_dev);
 
@@ -1878,6 +1892,7 @@ nfp_secondary_init_app_fw_nic(struct nfp_pf_dev *pf_dev)
 static int
 nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
 {
+   void *sync;
int ret = 0;
struct nfp_cpp *cpp;
uint8_t function_id;
@@ -1910,6 +1925,13 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
return -ENOMEM;
}
 
+   sync = nfp_sync_alloc();
+   if (sync == NULL) {
+   PMD_INIT_LOG(ERR, "Failed to alloc sync zone.");
+   ret = -ENOMEM;
+   goto pf_cleanup;
+   }
+
/*
 * When device bound to UIO, the device could be used, by mistake,
 * by two DPDK apps, and the UIO driver does not avoid it. This
@@ -1925,7 +1947,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
if (cpp == NULL) {
PMD_INIT_LOG(ERR, "A CPP handle can not be obtained");
ret = -EIO;
-   goto pf_cleanup;
+   goto sync_free;
}
 
/*
@@ -1936,7 +1958,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
if (sym_tbl == NULL) {
PMD_INIT_LOG(ERR, "Something is wrong with the firmware symbol 
table");
ret = -EIO;
-   goto pf_cleanup;
+   goto s

[PATCH 2/4] net/nfp: create new service code related files

[Chaoyong He]

From: Long Wu 

For clearer service code structure and more convenient future
addition of service code, NFP creates new service code related
files and move service related code into new files.

This commit also adds service disable interface and lets CPP
service run normally if app uses several flower cards.

Signed-off-by: Long Wu 
Reviewed-by: Chaoyong He 
Reviewed-by: Peng Zhang 
---
 drivers/net/nfp/flower/nfp_flower.c |  19 ++---
 drivers/net/nfp/meson.build |   1 +
 drivers/net/nfp/nfp_cpp_bridge.c|  91 +-
 drivers/net/nfp/nfp_cpp_bridge.h|   1 -
 drivers/net/nfp/nfp_net_common.h|   5 +-
 drivers/net/nfp/nfp_service.c   | 117 
 drivers/net/nfp/nfp_service.h   |  20 +
 7 files changed, 164 insertions(+), 90 deletions(-)
 create mode 100644 drivers/net/nfp/nfp_service.c
 create mode 100644 drivers/net/nfp/nfp_service.h

diff --git a/drivers/net/nfp/flower/nfp_flower.c 
b/drivers/net/nfp/flower/nfp_flower.c
index 88a1b061e1..a29edf8ca2 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -598,29 +598,20 @@ static int
 nfp_flower_enable_services(struct nfp_app_fw_flower *app_fw_flower)
 {
int ret;
-   uint32_t service_id;
+   struct nfp_service_info info;
const struct rte_service_spec flower_service = {
.name  = "flower_ctrl_vnic_service",
.callback  = nfp_flower_ctrl_vnic_service,
.callback_userdata = (void *)app_fw_flower,
};
 
-   /* Register the flower services */
-   ret = rte_service_component_register(&flower_service, &service_id);
+   ret = nfp_service_enable(&flower_service, &info);
if (ret != 0) {
-   PMD_INIT_LOG(ERR, "Could not register %s", flower_service.name);
-   return -EINVAL;
+   PMD_INIT_LOG(ERR, "Could not enable service %s", 
flower_service.name);
+   return ret;
}
 
-   app_fw_flower->ctrl_vnic_id = service_id;
-   PMD_INIT_LOG(INFO, "%s registered", flower_service.name);
-
-   /* Map them to available service cores */
-   ret = nfp_map_service(service_id);
-   if (ret != 0) {
-   PMD_INIT_LOG(ERR, "Could not map %s", flower_service.name);
-   return -EINVAL;
-   }
+   app_fw_flower->ctrl_vnic_id = info.id;
 
return 0;
 }
diff --git a/drivers/net/nfp/meson.build b/drivers/net/nfp/meson.build
index c625355d7a..0f4beccbdf 100644
--- a/drivers/net/nfp/meson.build
+++ b/drivers/net/nfp/meson.build
@@ -40,6 +40,7 @@ sources = files(
 'nfp_net_ctrl.c',
 'nfp_net_flow.c',
 'nfp_rxtx.c',
+'nfp_service.c',
 )
 
 deps += ['hash', 'security', 'common_nfp']
diff --git a/drivers/net/nfp/nfp_cpp_bridge.c b/drivers/net/nfp/nfp_cpp_bridge.c
index 36dcdca9de..441c0d2843 100644
--- a/drivers/net/nfp/nfp_cpp_bridge.c
+++ b/drivers/net/nfp/nfp_cpp_bridge.c
@@ -8,10 +8,9 @@
 #include 
 #include 
 
-#include 
-
 #include "nfpcore/nfp_cpp.h"
 #include "nfp_logs.h"
+#include "nfp_service.h"
 
 #define NFP_CPP_MEMIO_BOUNDARY(1 << 20)
 #define NFP_BRIDGE_OP_READ20
@@ -24,82 +23,23 @@
 /* Prototypes */
 static int nfp_cpp_bridge_service_func(void *args);
 
-int
-nfp_map_service(uint32_t service_id)
-{
-   int32_t ret;
-   uint32_t slcore = 0;
-   int32_t slcore_count;
-   uint8_t service_count;
-   const char *service_name;
-   uint32_t slcore_array[RTE_MAX_LCORE];
-   uint8_t min_service_count = UINT8_MAX;
-
-   slcore_count = rte_service_lcore_list(slcore_array, RTE_MAX_LCORE);
-   if (slcore_count <= 0) {
-   PMD_INIT_LOG(DEBUG, "No service cores found");
-   return -ENOENT;
-   }
-
-   /*
-* Find a service core with the least number of services already
-* registered to it.
-*/
-   while (slcore_count--) {
-   service_count = 
rte_service_lcore_count_services(slcore_array[slcore_count]);
-   if (service_count < min_service_count) {
-   slcore = slcore_array[slcore_count];
-   min_service_count = service_count;
-   }
-   }
-
-   service_name = rte_service_get_name(service_id);
-   PMD_INIT_LOG(INFO, "Mapping service %s to core %u", service_name, 
slcore);
-
-   ret = rte_service_map_lcore_set(service_id, slcore, 1);
-   if (ret != 0) {
-   PMD_INIT_LOG(DEBUG, "Could not map flower service");
-   return -ENOENT;
-   }
-
-   rte_service_runstate_set(service_id, 1);
-   rte_service_component_runstate_set(service_id, 1);
-   rte_service_lcore_start(slcore);
-   if (rte_service_may_be_active(slcore) != 0)
-   PMD_INIT_LOG(INFO, "The service %s is running", service_name);
-   else
-   PMD_INIT_LOG(ERR, "The service %s is not running", 
service_name);
-
-  

[PATCH 3/4] net/nfp: flower driver uses one service core

[Chaoyong He]

From: Long Wu 

Now app must provide a service core for each NFP pci device that uses
flower driver to run flower service, which will cause huge resource waste.
This patch is to solve this problem and app can only use one core to
run NFP flower service though it uses several NFP NICs.

Signed-off-by: Long Wu 
Reviewed-by: Chaoyong He 
Reviewed-by: Peng Zhang 
---
 drivers/net/nfp/flower/nfp_flower.c   |  47 ++---
 drivers/net/nfp/flower/nfp_flower_ctrl.c  |  20 +-
 drivers/net/nfp/flower/nfp_flower_ctrl.h  |   2 +-
 .../net/nfp/flower/nfp_flower_representor.c   |   4 +
 drivers/net/nfp/flower/nfp_flower_service.c   | 196 ++
 drivers/net/nfp/flower/nfp_flower_service.h   |  17 ++
 drivers/net/nfp/meson.build   |   1 +
 drivers/net/nfp/nfp_net_common.h  |   6 +
 drivers/net/nfp/nfpcore/nfp_sync.h|   2 +
 9 files changed, 248 insertions(+), 47 deletions(-)
 create mode 100644 drivers/net/nfp/flower/nfp_flower_service.c
 create mode 100644 drivers/net/nfp/flower/nfp_flower_service.h

diff --git a/drivers/net/nfp/flower/nfp_flower.c 
b/drivers/net/nfp/flower/nfp_flower.c
index a29edf8ca2..e84e6ebbff 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -18,6 +18,7 @@
 #include "../nfp_mtr.h"
 #include "nfp_flower_ctrl.h"
 #include "nfp_flower_representor.h"
+#include "nfp_flower_service.h"
 
 #define CTRL_VNIC_NB_DESC 512
 
@@ -461,6 +462,13 @@ nfp_flower_init_ctrl_vnic(struct nfp_net_hw *hw)
nn_cfg_writeb(&hw->super, NFP_NET_CFG_TXR_SZ(i), 
rte_log2_u32(CTRL_VNIC_NB_DESC));
}
 
+   /* Alloc sync memory zone */
+   ret = nfp_flower_service_sync_alloc(app_fw_flower);
+   if (ret != 0) {
+   PMD_INIT_LOG(ERR, "Alloc sync memory zone failed");
+   goto tx_queue_setup_cleanup;
+   }
+
return 0;
 
 tx_queue_setup_cleanup:
@@ -531,6 +539,7 @@ nfp_flower_cleanup_ctrl_vnic(struct nfp_net_hw *hw)
}
}
 
+   nfp_flower_service_sync_free(app_fw_flower);
rte_free(eth_dev->data->tx_queues);
rte_free(eth_dev->data->rx_queues);
rte_mempool_free(app_fw_flower->ctrl_pktmbuf_pool);
@@ -584,38 +593,6 @@ nfp_flower_start_ctrl_vnic(struct nfp_net_hw *net_hw)
return 0;
 }
 
-static int
-nfp_flower_ctrl_vnic_service(void *arg)
-{
-   struct nfp_app_fw_flower *app_fw_flower = arg;
-
-   nfp_flower_ctrl_vnic_poll(app_fw_flower);
-
-   return 0;
-}
-
-static int
-nfp_flower_enable_services(struct nfp_app_fw_flower *app_fw_flower)
-{
-   int ret;
-   struct nfp_service_info info;
-   const struct rte_service_spec flower_service = {
-   .name  = "flower_ctrl_vnic_service",
-   .callback  = nfp_flower_ctrl_vnic_service,
-   .callback_userdata = (void *)app_fw_flower,
-   };
-
-   ret = nfp_service_enable(&flower_service, &info);
-   if (ret != 0) {
-   PMD_INIT_LOG(ERR, "Could not enable service %s", 
flower_service.name);
-   return ret;
-   }
-
-   app_fw_flower->ctrl_vnic_id = info.id;
-
-   return 0;
-}
-
 static void
 nfp_flower_pkt_add_metadata_register(struct nfp_app_fw_flower *app_fw_flower)
 {
@@ -760,7 +737,7 @@ nfp_init_app_fw_flower(struct nfp_pf_dev *pf_dev,
}
 
/* Start up flower services */
-   ret = nfp_flower_enable_services(app_fw_flower);
+   ret = nfp_flower_service_start(app_fw_flower);
if (ret != 0) {
PMD_INIT_LOG(ERR, "Could not enable flower services");
ret = -ESRCH;
@@ -770,11 +747,13 @@ nfp_init_app_fw_flower(struct nfp_pf_dev *pf_dev,
ret = nfp_flower_repr_create(app_fw_flower);
if (ret != 0) {
PMD_INIT_LOG(ERR, "Could not create representor ports");
-   goto ctrl_vnic_cleanup;
+   goto ctrl_vnic_service_stop;
}
 
return 0;
 
+ctrl_vnic_service_stop:
+   nfp_flower_service_stop(app_fw_flower);
 ctrl_vnic_cleanup:
nfp_flower_cleanup_ctrl_vnic(app_fw_flower->ctrl_hw);
 ctrl_cpp_area_cleanup:
diff --git a/drivers/net/nfp/flower/nfp_flower_ctrl.c 
b/drivers/net/nfp/flower/nfp_flower_ctrl.c
index c25487c277..bcb325d475 100644
--- a/drivers/net/nfp/flower/nfp_flower_ctrl.c
+++ b/drivers/net/nfp/flower/nfp_flower_ctrl.c
@@ -12,6 +12,7 @@
 #include "../nfp_logs.h"
 #include "nfp_flower_representor.h"
 #include "nfp_mtr.h"
+#include "nfp_flower_service.h"
 
 #define MAX_PKT_BURST 32
 
@@ -502,26 +503,21 @@ nfp_flower_cmsg_rx(struct nfp_app_fw_flower 
*app_fw_flower,
 }
 
 void
-nfp_flower_ctrl_vnic_poll(struct nfp_app_fw_flower *app_fw_flower)
+nfp_flower_ctrl_vnic_process(struct nfp_app_fw_flower *app_fw_flower)
 {
uint16_t count;
struct nfp_net_rxq *rxq;
-   struct nfp_net_hw *ctrl_hw;
struct rte_eth_dev *ctrl_eth_dev;
struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
 
-   ctr

[PATCH 4/4] net/nfp: fix stop cpp service problem

[Chaoyong He]

From: Long Wu 

Stop cpp service if all representors are closed and cpp service is running.

Fixes: bab0e6f48b6d ("net/nfp: fix infinite loop")
Cc: chaoyong...@corigine.com
Cc: sta...@dpdk.org

Signed-off-by: Long Wu 
Reviewed-by: Chaoyong He 
Reviewed-by: Peng Zhang 
---
 drivers/net/nfp/flower/nfp_flower_representor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/nfp/flower/nfp_flower_representor.c 
b/drivers/net/nfp/flower/nfp_flower_representor.c
index bf67dc3ba2..2e8eb13e4e 100644
--- a/drivers/net/nfp/flower/nfp_flower_representor.c
+++ b/drivers/net/nfp/flower/nfp_flower_representor.c
@@ -400,6 +400,9 @@ nfp_flower_repr_dev_close(struct rte_eth_dev *dev)
/* Stop flower service first */
nfp_flower_service_stop(app_fw_flower);
 
+   /* Disable cpp service if need */
+   nfp_service_disable(&pf_dev->cpp_service_info);
+
/* Now it is safe to free all PF resources */
nfp_uninit_app_fw_flower(pf_dev);
nfp_pf_uninit(pf_dev);
-- 
2.39.1

[DPDK Bug 1338] [dpdk-22.11.4] vhost_virtio_user_interrupt_with_power_monitor/perf_wake_up_split_ring_vhost_user_core_with_l3fwd_power_sample：virtio-user can't receive packet

[bugzilla]

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

linglix.c...@intel.com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from linglix.c...@intel.com ---
fix commit dc9c799c7d vhost: fix missing spinlock unlock
Two regressions were introduced when backporting below
patch:
b4c4e5675c85 ("vhost: fix missing lock protection in power monitor API")

First, rte_vhost_get_monitor_addr did not release the lock
in the success case. Then, rte_rwlock_read_lock() was
converted to rte_spinlock_trylock() instead of
rte_spinlock_lock().

This patch addresses both of these issues.

Fixes: a07736eb68da ("vhost: fix missing lock protection in power monitor API")
Cc: sta...@dpdk.org

Signed-off-by: Maxime Coquelin 

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

RE: [V1 0/5] support VXLAN-GPE header fields(flags, rsvd0 and rsvd1) matching

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Gavin Li 
> Sent: Friday, January 12, 2024 10:02 AM
> To: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Ori Kam ;
> aman.deep.si...@intel.com; yuying.zh...@intel.com; Dariusz Sosnowski
> ; Slava Ovsiienko ;
> Suanming Mou ; Matan Azrad
> 
> Cc: Jiawei(Jonny) Wang ; Raslan Darawsheh
> 
> Subject: [V1 0/5] support VXLAN-GPE header fields(flags, rsvd0 and rsvd1)
> matching
> 
> Previously, VXLAN-GPE in DPDK only supports VNI and next protocol header
> fields. This patch series add support for flags and reserved field 0 and 1.
> 
> Below is the VXLAN-GPE header defined in the lasted draft.
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|R|R|Ver|I|P|B|O|   Reserved|Next Protocol  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|VXLAN Network Identifier (VNI) |   Reserved|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Gavin Li (5):
>   net/mlx5: support VXLAN-GPE flags matching
>   app/testpmd: support VXLAN-GPE flags
>   net/mlx5: support VXLAN-GPE reserved fields matching
>   app/testpmd: support VXLAN-GPE reserved fields
>   net/mlx5/hws: support VXLAN-GPE matching
> 
>  app/test-pmd/cmdline_flow.c |  30 +
>  doc/guides/nics/mlx5.rst|   5 +
>  doc/guides/rel_notes/release_24_03.rst  |   6 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |   3 +
>  drivers/net/mlx5/hws/mlx5dr_definer.c   | 117 
>  drivers/net/mlx5/hws/mlx5dr_definer.h   |  13 +++
>  drivers/net/mlx5/mlx5_flow.c|   6 +
>  drivers/net/mlx5/mlx5_flow_dv.c |  32 +-
>  drivers/net/mlx5/mlx5_flow_hw.c |   1 +
>  9 files changed, 207 insertions(+), 6 deletions(-)
> 
> --
> 2.39.1

Series applied to next-net-mlx,

Kindest regards
Raslan Darawsheh

[PATCH] bus/pci: fix secondary process PCI uio resource map problem

[Chaoyong He]

From: Zerun Fu 

For the primary process, the logic loops all BARs and will skip
the map of BAR with an invalid physical address (0), also will
assign 'uio_res->nb_maps' with the real mapped BARs number. But
for the secondary process, instead of loops all BARs, the logic
using the 'uio_res->nb_map' as index. If the device uses continuous
BARs there will be no problem, whereas if it uses discrete BARs,
it will lead to mapping errors.

Fix this problem by also loops all BARs and skip the map of BAR
with an invalid physical address in secondary process.

Fixes: 9b957f378abf ("pci: merge uio functions for linux and bsd")
Cc: muk...@igel.co.jp
Cc: sta...@dpdk.org

Signed-off-by: Zerun Fu 
Reviewed-by: Chaoyong He 
Reviewed-by: Long Wu 
Reviewed-by: Peng Zhang 
---
 drivers/bus/pci/pci_common_uio.c | 94 
 1 file changed, 60 insertions(+), 34 deletions(-)

diff --git a/drivers/bus/pci/pci_common_uio.c b/drivers/bus/pci/pci_common_uio.c
index 76c661f054..fcd8a49daf 100644
--- a/drivers/bus/pci/pci_common_uio.c
+++ b/drivers/bus/pci/pci_common_uio.c
@@ -23,10 +23,57 @@ static struct rte_tailq_elem rte_uio_tailq = {
 };
 EAL_REGISTER_TAILQ(rte_uio_tailq)
 
+static int
+pci_uio_map_secondary_resource_by_index(struct rte_pci_device *dev,
+   int res_idx, struct mapped_pci_resource *uio_res, int map_idx)
+{
+   int fd, i;
+
+   if (map_idx >= uio_res->nb_maps)
+   return -1;
+
+   /*
+* open devname, to mmap it
+*/
+   fd = open(uio_res->maps[map_idx].path, O_RDWR);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
+   uio_res->maps[map_idx].path, strerror(errno));
+   return -1;
+   }
+
+   void *mapaddr = pci_map_resource(uio_res->maps[map_idx].addr,
+   fd, (off_t)uio_res->maps[map_idx].offset,
+   (size_t)uio_res->maps[map_idx].size, 0);
+
+   /* fd is not needed in secondary process, close it */
+   close(fd);
+   if (mapaddr != uio_res->maps[map_idx].addr) {
+   RTE_LOG(ERR, EAL,
+   "Cannot mmap device resource file %s to address: %p\n",
+   uio_res->maps[map_idx].path,
+   uio_res->maps[map_idx].addr);
+   if (mapaddr != NULL) {
+   /* unmap addrs correctly mapped */
+   for (i = 0; i < map_idx; i++)
+   pci_unmap_resource(
+   uio_res->maps[i].addr,
+   (size_t)uio_res->maps[i].size);
+   /* unmap addr wrongly mapped */
+   pci_unmap_resource(mapaddr,
+   (size_t)uio_res->maps[map_idx].size);
+   }
+   return -1;
+   }
+   dev->mem_resource[res_idx].addr = mapaddr;
+
+   return 0;
+}
+
 static int
 pci_uio_map_secondary(struct rte_pci_device *dev)
 {
-   int fd, i, j;
+   int map_idx = 0, res_idx, ret;
struct mapped_pci_resource *uio_res;
struct mapped_pci_res_list *uio_res_list =
RTE_TAILQ_CAST(rte_uio_tailq.head, mapped_pci_res_list);
@@ -37,41 +84,20 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
if (rte_pci_addr_cmp(&uio_res->pci_addr, &dev->addr))
continue;
 
-   for (i = 0; i != uio_res->nb_maps; i++) {
-   /*
-* open devname, to mmap it
-*/
-   fd = open(uio_res->maps[i].path, O_RDWR);
-   if (fd < 0) {
-   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
-   uio_res->maps[i].path, strerror(errno));
-   return -1;
+   /* Map all BARs */
+   for (res_idx = 0; res_idx != PCI_MAX_RESOURCE; res_idx++) {
+/* skip empty BAR */
+   if (dev->mem_resource[res_idx].phys_addr == 0)
+   continue;
+
+   ret = pci_uio_map_secondary_resource_by_index(dev, 
res_idx,
+   uio_res, map_idx);
+   if (ret < 0) {
+   RTE_LOG(ERR, EAL, "Failed to map resources\n");
+   return ret;
}
 
-   void *mapaddr = pci_map_resource(uio_res->maps[i].addr,
-   fd, (off_t)uio_res->maps[i].offset,
-   (size_t)uio_res->maps[i].size, 0);
-
-   /* fd is not needed in secondary process, close it */
-   close(fd);
-   if (mapaddr != uio_res->maps[i].addr) {
-   RTE_LOG(ERR, EAL,
- 

Re: [PATCH v2 10/11] eventdev: RFC clarify comments on scheduling types

[Bruce Richardson]

On Tue, Jan 23, 2024 at 05:19:18PM +0100, Mattias Rönnblom wrote:
> On 2024-01-19 18:43, Bruce Richardson wrote:
> > The description of ordered and atomic scheduling given in the eventdev
> > doxygen documentation was not always clear. Try and simplify this so
> > that it is clearer for the end-user of the application
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> > 
> > NOTE TO REVIEWERS:
> > I've updated this based on my understanding of what these scheduling
> > types are meant to do. It matches my understanding of the support
> > offered by our Intel DLB2 driver, as well as the SW eventdev, and I
> > believe the DSW eventdev too. If it does not match the behaviour of
> > other eventdevs, let's have a discussion to see if we can reach a good
> > definition of the behaviour that is common.
> > ---
> >   lib/eventdev/rte_eventdev.h | 47 -
> >   1 file changed, 25 insertions(+), 22 deletions(-)
> > 
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index 2c6576e921..cb13602ffb 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1313,26 +1313,24 @@ struct rte_event_vector {
> >   #define RTE_SCHED_TYPE_ORDERED  0
> >   /**< Ordered scheduling
> >*
> > - * Events from an ordered flow of an event queue can be scheduled to 
> > multiple
> > + * Events from an ordered event queue can be scheduled to multiple
> 
> What is the rationale for this change?
> 
> An implementation that impose a total order on all events on a particular
> ordered queue will still adhere to the current, more relaxed, per-flow
> ordering semantics.
> 
> An application wanting a total order would just set the flow id to 0 on all
> events destined that queue, and it would work on all event devices.
> 
> Why don't you just put a note in the DLB driver saying "btw it's total
> order", so any application where per-flow ordering is crucial for
> performance (i.e., where the potentially needless head-of-line blocking is
> an issue) can use multiple queues when running with the DLB.
> 
> In the API as-written, the app is free to express more relaxed ordering
> requirements (i.e., to have multiple flows) and it's up to the event device
> to figure out if it's in a position where it can translate this to lower
> latency.
> 

Yes, you are right. I'll roll-back or rework this change in V3. Keep it
documented that flow-ordering is guaranteed, but note that some
implementations may use total ordering to achieve that.

> >* ports for concurrent processing while maintaining the original event 
> > order.
> 
> Maybe it's worth mentioning what is the original event order. "(i.e., the
> order in which the events were enqueued to the queue)". Especially since one
> like to specify what ordering guarantees one have of events enqueued to the
> same queue on different ports and by different lcores).
> 
> I don't know where that information should go though, since it's relevant
> for both atomic and ordered-type queues.
> 

It's probably more relevant for ordered, but I'll try and see where it's
best to go.

> >* This scheme enables the user to achieve high single flow throughput by
> > - * avoiding SW synchronization for ordering between ports which bound to 
> > cores.
> > - *
> > - * The source flow ordering from an event queue is maintained when events 
> > are
> > - * enqueued to their destination queue within the same ordered flow 
> > context.
> > - * An event port holds the context until application call
> > - * rte_event_dequeue_burst() from the same port, which implicitly releases
> > - * the context.
> > - * User may allow the scheduler to release the context earlier than that
> > - * by invoking rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE 
> > operation.
> > - *
> > - * Events from the source queue appear in their original order when 
> > dequeued
> > - * from a destination queue.
> > - * Event ordering is based on the received event(s), but also other
> > - * (newly allocated or stored) events are ordered when enqueued within the 
> > same
> > - * ordered context. Events not enqueued (e.g. released or stored) within 
> > the
> > - * context are  considered missing from reordering and are skipped at this 
> > time
> > - * (but can be ordered again within another context).
> > + * avoiding SW synchronization for ordering between ports which are polled 
> > by
> > + * different cores.
> > + *
> > + * As events are scheduled to ports/cores, the original event order from 
> > the
> > + * source event queue is recorded internally in the scheduler. As events 
> > are
> > + * returned (via FORWARD type enqueue) to the scheduler, the original event
> > + * order is restored before the events are enqueued into their new 
> > destination
> > + * queue.
> 
> Delete the first sentence on implementation.
> 
> "As events are re-enqueued to the next queue (with the op field set to
> RTE_EVENT_OP_FORWARD), the event device restore

[PATCH v5] mempool: test performance with larger bursts

[Morten Brørup]

Bursts of up to 64 or 128 packets are not uncommon, so increase the
maximum tested get and put burst sizes from 32 to 128.
For convenience, also test get and put burst sizes of
RTE_MEMPOOL_CACHE_MAX_SIZE.

Some applications keep more than 512 objects, so increase the maximum
number of kept objects from 512 to 32768, still in jumps of factor four.
This exceeds the typical mempool cache size of 512 objects, so the test
also exercises the mempool driver.

Increased the precision of rate_persec calculation by timing the actual
duration of the test, instead of assuming it took exactly 5 seconds.

Added cache guard to per-lcore stats structure.

Signed-off-by: Morten Brørup 
Acked-by: Chengwen Feng 
---

v5:
* Increased N, to reduce measurement overhead with large numbers of kept
  objects.
* Increased precision of rate_persec calculation.
* Added missing cache guard to per-lcore stats structure.
v4:
* v3 failed to apply; I had messed up something with git.
* Added ACK from Chengwen Feng.
v3:
* Increased max number of kept objects to 32768.
* Added get and put burst sizes of RTE_MEMPOOL_CACHE_MAX_SIZE objects.
* Print error if unable to allocate mempool.
* Initialize use_external_cache with each test.
  A previous version of this patch had a bug, where all test runs
  following the first would use external cache. (Chengwen Feng)
v2: Addressed feedback by Chengwen Feng
* Added get and put burst sizes of 64 objects, which is probably also not
  uncommon packet burst size.
* Fixed list of number of kept objects so list remains in jumps of factor
  four.
* Added three derivative test cases, for faster testing.
---
 app/test/test_mempool_perf.c | 137 ++-
 1 file changed, 86 insertions(+), 51 deletions(-)

diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index 96de347f04..dcdfb52020 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2010-2014 Intel Corporation
- * Copyright(c) 2022 SmartShare Systems
+ * Copyright(c) 2022-2024 SmartShare Systems
  */
 
 #include 
@@ -54,22 +54,25 @@
  *
  *- Bulk size (*n_get_bulk*, *n_put_bulk*)
  *
- *  - Bulk get from 1 to 32
- *  - Bulk put from 1 to 32
- *  - Bulk get and put from 1 to 32, compile time constant
+ *  - Bulk get from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE
+ *  - Bulk get and put from 1 to 128, and RTE_MEMPOOL_CACHE_MAX_SIZE, 
compile time constant
  *
  *- Number of kept objects (*n_keep*)
  *
  *  - 32
  *  - 128
  *  - 512
+ *  - 2048
+ *  - 8192
+ *  - 32768
  */
 
-#define N 65536
 #define TIME_S 5
 #define MEMPOOL_ELT_SIZE 2048
-#define MAX_KEEP 512
-#define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE))-1)
+#define MAX_KEEP 32768
+#define N (128 * MAX_KEEP)
+#define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE*2))-1)
 
 /* Number of pointers fitting into one cache line. */
 #define CACHE_LINE_BURST (RTE_CACHE_LINE_SIZE / sizeof(uintptr_t))
@@ -100,9 +103,11 @@ static unsigned n_keep;
 /* true if we want to test with constant n_get_bulk and n_put_bulk */
 static int use_constant_values;
 
-/* number of enqueues / dequeues */
+/* number of enqueues / dequeues, and time used */
 struct mempool_test_stats {
uint64_t enq_count;
+   uint64_t duration_cycles;
+   RTE_CACHE_GUARD;
 } __rte_cache_aligned;
 
 static struct mempool_test_stats stats[RTE_MAX_LCORE];
@@ -185,6 +190,7 @@ per_lcore_mempool_test(void *arg)
GOTO_ERR(ret, out);
 
stats[lcore_id].enq_count = 0;
+   stats[lcore_id].duration_cycles = 0;
 
/* wait synchro for workers */
if (lcore_id != rte_get_main_lcore())
@@ -204,6 +210,13 @@ per_lcore_mempool_test(void *arg)
CACHE_LINE_BURST, CACHE_LINE_BURST);
else if (n_get_bulk == 32)
ret = test_loop(mp, cache, n_keep, 32, 32);
+   else if (n_get_bulk == 64)
+   ret = test_loop(mp, cache, n_keep, 64, 64);
+   else if (n_get_bulk == 128)
+   ret = test_loop(mp, cache, n_keep, 128, 128);
+   else if (n_get_bulk == RTE_MEMPOOL_CACHE_MAX_SIZE)
+   ret = test_loop(mp, cache, n_keep,
+   RTE_MEMPOOL_CACHE_MAX_SIZE, 
RTE_MEMPOOL_CACHE_MAX_SIZE);
else
ret = -1;
 
@@ -215,6 +228,8 @@ per_lcore_mempool_test(void *arg)
stats[lcore_id].enq_count += N;
}
 
+   stats[lcore_id].duration_cycles = time_diff;
+
 out:
if (use_external_cache) {
rte_mempool_cache_flush(cache, mp);
@@ -232,6 +247,7 @@ launch_cores(struct rte_mempool *mp, unsigned int cores)
uint64_t rate;
int ret;

Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields

[Mattias Rönnblom]

On 2024-01-19 18:43, Bruce Richardson wrote:

Clarify the meaning of the NEW, FORWARD and RELEASE event types.
For the fields in "rte_event" struct, enhance the comments on each to
clarify the field's use, and whether it is preserved between enqueue and
dequeue, and it's role, if any, in scheduling.

Signed-off-by: Bruce Richardson 
---

As with the previous patch, please review this patch to ensure that the
expected semantics of the various event types and event fields have not
changed in an unexpected way.
---
  lib/eventdev/rte_eventdev.h | 105 ++--
  1 file changed, 77 insertions(+), 28 deletions(-)

diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index cb13602ffb..4eff1c4958 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1416,21 +1416,25 @@ struct rte_event_vector {

  /* Event enqueue operations */
  #define RTE_EVENT_OP_NEW0
-/**< The event producers use this operation to inject a new event to the
+/**< The @ref rte_event.op field should be set to this type to inject a new 
event to the
   * event device.
   */


"type" -> "value"

"to" -> "into"?

You could also say "to mark the event as new".

What is new? Maybe "new (as opposed to a forwarded) event." or "new 
(i.e., not previously dequeued).".


"The application sets the @ref rte_event.op field of an enqueued event 
to this value to mark the event as new (i.e., not previously dequeued)."



  #define RTE_EVENT_OP_FORWARD1
-/**< The CPU use this operation to forward the event to different event queue 
or
- * change to new application specific flow or schedule type to enable
- * pipelining.
+/**< SW should set the @ref rte_event.op filed to this type to return a
+ * previously dequeued event to the event device for further processing.


"filed" -> "field"

"SW" -> "The application"

"to be scheduled for further processing (or transmission)"

The wording should otherwise be the same as NEW, whatever you choose there.


   *
- * This operation must only be enqueued to the same port that the
+ * This event *must* be enqueued to the same port that the
   * event to be forwarded was dequeued from.


OK, so you "should" mark a new event RTE_EVENT_OP_FORWARD but you 
"*must*" enqueue it to the same port.


I think you "must" do both.


+ *
+ * The event's fields, including (but not limited to) flow_id, scheduling type,
+ * destination queue, and event payload e.g. mbuf pointer, may all be updated 
as
+ * desired by software, but the @ref rte_event.impl_opaque field must


"software" -> "application"


+ * be kept to the same value as was present when the event was dequeued.
   */
  #define RTE_EVENT_OP_RELEASE2
  /**< Release the flow context associated with the schedule type.
   *
- * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
+ * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
   * then this function hints the scheduler that the user has completed critical
   * section processing in the current atomic context.
   * The scheduler is now allowed to schedule events from the same flow from
@@ -1442,21 +1446,19 @@ struct rte_event_vector {
   * performance, but the user needs to design carefully the split into critical
   * vs non-critical sections.
   *
- * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
- * then this function hints the scheduler that the user has done all that need
- * to maintain event order in the current ordered context.
- * The scheduler is allowed to release the ordered context of this port and
- * avoid reordering any following enqueues.
- *
- * Early ordered context release may increase parallelism and thus system
- * performance.
+ * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ORDERED


Isn't a missing "or @ref RTE_SCHED_TYPE_ATOMIC" just an oversight (in 
the original API wording)?



+ * then this function informs the scheduler that the current event has
+ * completed processing and will not be returned to the scheduler, i.e.
+ * it has been dropped, and so the reordering context for that event
+ * should be considered filled.
   *
- * If current flow's scheduler type method is *RTE_SCHED_TYPE_PARALLEL*
+ * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_PARALLEL
   * or no scheduling context is held then this function may be an NOOP,
   * depending on the implementation.


Maybe you can also fix this "function" -> "operation". I suggest you 
delete that sentence, because it makes no sense.


What is says in a somewhat vague manner is that you tread into the realm 
of undefined behavior if you release PARALLEL events.



   *
   * This operation must only be enqueued to the same port that the
- * event to be released was dequeued from.
+ * event to be released was dequeued from. The @ref rte_event.impl_opaque
+ * field in the release event must match that in the original dequeued event.


I would say "sam

Re: [PATCH v2 01/11] eventdev: improve doxygen introduction text

[Mattias Rönnblom]

On 2024-01-23 10:06, Bruce Richardson wrote:

On Tue, Jan 23, 2024 at 09:57:58AM +0100, Mattias Rönnblom wrote:

On 2024-01-19 18:43, Bruce Richardson wrote:

Make some textual improvements to the introduction to eventdev and event
devices in the eventdev header file. This text appears in the doxygen
output for the header file, and introduces the key concepts, for
example: events, event devices, queues, ports and scheduling.



Great stuff, Bruce.


Thanks, good feedback here. I'll take that into account and do a v3 later
when all feedback on this v2 is in.

/Bruce


Sorry for such a piecemeal review. I didn't have time to do it all in 
one go.

Re: [PATCH v2 04/11] eventdev: cleanup doxygen comments on info structure

[Mattias Rönnblom]

On 2024-01-23 10:43, Bruce Richardson wrote:

On Tue, Jan 23, 2024 at 10:35:02AM +0100, Mattias Rönnblom wrote:

On 2024-01-19 18:43, Bruce Richardson wrote:

Some small rewording changes to the doxygen comments on struct
rte_event_dev_info.

Signed-off-by: Bruce Richardson 
---
   lib/eventdev/rte_eventdev.h | 46 -
   1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 57a2791946..872f241df2 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -482,54 +482,58 @@ struct rte_event_dev_info {
const char *driver_name;/**< Event driver name */
struct rte_device *dev; /**< Device information */
uint32_t min_dequeue_timeout_ns;
-   /**< Minimum supported global dequeue timeout(ns) by this device */
+   /**< Minimum global dequeue timeout(ns) supported by this device */


Are we missing a bunch of "." here and in the other fields?


uint32_t max_dequeue_timeout_ns;
-   /**< Maximum supported global dequeue timeout(ns) by this device */
+   /**< Maximum global dequeue timeout(ns) supported by this device */
uint32_t dequeue_timeout_ns;
/**< Configured global dequeue timeout(ns) for this device */
uint8_t max_event_queues;
-   /**< Maximum event_queues supported by this device */
+   /**< Maximum event queues supported by this device */
uint32_t max_event_queue_flows;
-   /**< Maximum supported flows in an event queue by this device*/
+   /**< Maximum number of flows within an event queue supported by this 
device*/
uint8_t max_event_queue_priority_levels;
/**< Maximum number of event queue priority levels by this device.
-* Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability
+* Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability.
+* The priority levels are evenly distributed between
+* @ref RTE_EVENT_DEV_PRIORITY_HIGHEST and @ref 
RTE_EVENT_DEV_PRIORITY_LOWEST.


This is a change of the API, in the sense it's defining something previously
left undefined?



Well, undefined is pretty useless for app writers, no?
However, agreed that the range between HIGHEST and LOWEST is an assumption
on my part, chosen because it matches what happens to the event priorities
which are documented in event struct as "The implementation shall normalize
  the requested priority to supported priority value" - which, while better
than nothing, does technically leave the details of how normalization
occurs up to the implementation.


If you need 6 different priority levels in an app, how do you go about
making sure you find the correct (distinct) Eventdev levels on any event
device supporting >= 6 levels?

#define NUM_MY_LEVELS 6

#define MY_LEVEL_TO_EVENTDEV_LEVEL(my_level) (((my_level) *
(RTE_EVENT_DEV_PRIORITY_HIGHEST-RTE_EVENT_DEV_PRIORTY_LOWEST) /
NUM_MY_LEVELS)

This way? One would worry a bit exactly what "evenly" means, in terms of
rounding errors. If you have an event device with 255 priority levels of
(say) 256 levels available in the API, which two levels are the same
priority?


Yes, round etc. will be an issue in cases of non-powers-of 2.
However, I think we do need to clarify this behaviour, so I'm open to
alternative suggestions as to how update this.



In retrospect, maybe it would have been better to just express the 
number of priority levels an event device supported, only allow [0, 
max_levels - 1] in the prio field, and leave it to the app to do the 
conversion/normalization.


Maybe a new  helper macro would at least suggest to the 
PMD driver implementer and the application designer how this 
normalization should work. Something like the above, but where 
NUM_MY_LEVELS is an input parameter. Would result in an integer division 
though, so shouldn't be used in the fast path.

Re: [24.03 RFC 3/3] args: add functions to check parameter validity

[Thomas Monjalon]

02/11/2023 18:28, Bruce Richardson:
> Add in functions which can be used to check for valid arguments for EAL
> or for the application. This can be used to separate out mixed arguments.
> 
> Signed-off-by: Bruce Richardson 
> ---
>  lib/args/args.c  | 122 +++
>  lib/args/rte_args.h  |  56 

This is helping with args taken by EAL.
So I think it should be hosted in EAL itself.

Re: [24.03 RFC 1/3] args: new library to allow easier manipulation of cmdline args

[Thomas Monjalon]

02/11/2023 18:28, Bruce Richardson:
> Add a new small library to make it easier for apps to work with cmdline
> arguments and build up args to use when initializing EAL.
> 
> This library is optional, and can be disabled at build time using
> the disable libraries meson option.

This is an optional helper, so why not.

Another help for applications would be to allow initializing DPDK
without the need of passing or building argc/argv arguments.
I think we could add new functions rte_eal_init_*().
Example:
rte_eal_init_prepare()
rte_eal_init_memory(memory parameters)
rte_eal_init_devices(devargs)
rte_eal_init_threads()

It should be possible to rebuild rte_eal_init()
using above smaller functions to keep the big old
rte_eal_init with argc/argv for compatibility.

[PATCH] lib: remove duplicate prefix in logs

[David Marchand]

RTE_LOG() macros prefixe the log messages based on the logtype.
This results in logs like:

TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
TMTY: TELEMETRY: Socket creation and binding ok
TMTY: TELEMETRY: Telemetry initialized ok

Remove redundancy in some libraries following their conversion to
RTE_LOG/RTE_LOG_LINE.

Fixes: 97433132c2ed ("lib: use per line logging in helpers")
Fixes: 0e21c7c07d62 ("lib: replace logging helpers")

Reported-by: Thomas Monjalon 
Signed-off-by: David Marchand 
---
 lib/dmadev/rte_dmadev.c   | 3 +--
 lib/gpudev/gpudev.c   | 3 +--
 lib/graph/graph_private.h | 2 +-
 lib/node/node_private.h   | 2 +-
 lib/telemetry/telemetry.c | 4 ++--
 lib/vhost/vhost.h | 6 +++---
 6 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 5953a77bd6..dbaa14f262 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -35,8 +35,7 @@ RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
 #define RTE_LOGTYPE_DMA rte_dma_logtype
 
 #define RTE_DMA_LOG(level, ...) \
-   RTE_LOG_LINE(level, DMA, RTE_FMT("dma: " RTE_FMT_HEAD(__VA_ARGS__ ,), \
-   RTE_FMT_TAIL(__VA_ARGS__ ,)))
+   RTE_LOG_LINE(level, DMA, "" __VA_ARGS__)
 
 int
 rte_dma_dev_max(size_t dev_max)
diff --git a/lib/gpudev/gpudev.c b/lib/gpudev/gpudev.c
index de8291151f..1c2011b856 100644
--- a/lib/gpudev/gpudev.c
+++ b/lib/gpudev/gpudev.c
@@ -20,8 +20,7 @@ RTE_LOG_REGISTER_DEFAULT(gpu_logtype, NOTICE);
 #define RTE_LOGTYPE_GPUDEV gpu_logtype
 
 #define GPU_LOG(level, ...) \
-   RTE_LOG_LINE(level, GPUDEV, RTE_FMT("gpu: " RTE_FMT_HEAD(__VA_ARGS__ 
,), \
-   RTE_FMT_TAIL(__VA_ARGS__ ,)))
+   RTE_LOG_LINE(level, GPUDEV, "" __VA_ARGS__)
 
 /* Set any driver error as EPERM */
 #define GPU_DRV_RET(function) \
diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
index f9274ce96c..fb88d4bc84 100644
--- a/lib/graph/graph_private.h
+++ b/lib/graph/graph_private.h
@@ -22,7 +22,7 @@ extern int rte_graph_logtype;
 
 #define GRAPH_LOG(level, ...)  
\
RTE_LOG_LINE(level, GRAPH, \
-   RTE_FMT("GRAPH: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,), \
+   RTE_FMT("%s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),\
__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__ ,)))
 
 #define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
diff --git a/lib/node/node_private.h b/lib/node/node_private.h
index 845fdaa12e..73563e4cd2 100644
--- a/lib/node/node_private.h
+++ b/lib/node/node_private.h
@@ -15,7 +15,7 @@ extern int rte_node_logtype;
 
 #define NODE_LOG(level, node_name, ...)
\
RTE_LOG_LINE(level, NODE,  \
-   RTE_FMT("NODE %s: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),   \
+   RTE_FMT("%s: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),\
node_name, __func__, __LINE__, \
RTE_FMT_TAIL(__VA_ARGS__ ,)))
 
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 31e2391867..47846ef868 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -56,8 +56,8 @@ static const char *socket_dir;/* runtime directory */
 static rte_cpuset_t *thread_cpuset;
 
 RTE_LOG_REGISTER_DEFAULT(logtype, WARNING);
-#define RTE_LOGTYPE_TMTY logtype
-#define TMTY_LOG_LINE(l, ...) RTE_LOG_LINE(l, TMTY, "TELEMETRY: " __VA_ARGS__)
+#define RTE_LOGTYPE_TELEMETRY logtype
+#define TMTY_LOG_LINE(l, ...) RTE_LOG_LINE(l, TELEMETRY, "" __VA_ARGS__)
 
 /* list of command callbacks, with one command registered by default */
 static struct cmd_callback *callbacks;
diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
index 470dadbba6..0b13374980 100644
--- a/lib/vhost/vhost.h
+++ b/lib/vhost/vhost.h
@@ -678,10 +678,10 @@ extern int vhost_data_log_level;
 #define RTE_LOGTYPE_VHOST_DATA vhost_data_log_level
 
 #define VHOST_CONFIG_LOG(prefix, level, fmt, args...)  \
-   RTE_LOG_LINE(level, VHOST_CONFIG, "VHOST_CONFIG: (%s) " fmt, prefix, 
##args)
+   RTE_LOG_LINE(level, VHOST_CONFIG, "(%s) " fmt, prefix, ##args)
 
 #define VHOST_DATA_LOG(prefix, level, fmt, args...)\
-   RTE_LOG_DP_LINE(level, VHOST_DATA, "VHOST_DATA: (%s) " fmt, prefix, 
##args)
+   RTE_LOG_DP_LINE(level, VHOST_DATA, "(%s) " fmt, prefix, ##args)
 
 #ifdef RTE_LIBRTE_VHOST_DEBUG
 #define VHOST_MAX_PRINT_BUFF 6072
@@ -700,7 +700,7 @@ extern int vhost_data_log_level;
} \
snprintf(packet + strnlen(packet, VHOST_MAX_PRINT_BUFF), 
VHOST_MAX_PRINT_BUFF - strnlen(packet, VHOST_MAX_PRINT_BUFF), "\n"); \
\
-   RTE_LOG_DP(DEBUG, VHOST_DATA, "VHOST_DATA: (%s) %s", dev->ifname, 
packet); \
+   RTE_LOG_DP(DEBUG, VHOST_DATA, "(%s) %s", dev->ifname, packet); \
 } while (0)
 #els

RE: [PATCH] lib: remove duplicate prefix in logs

[Morten Brørup]

> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Wednesday, 24 January 2024 13.05
> 
> RTE_LOG() macros prefixe the log messages based on the logtype.
> This results in logs like:
> 
> TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> TMTY: TELEMETRY: Socket creation and binding ok
> TMTY: TELEMETRY: Telemetry initialized ok
> 
> Remove redundancy in some libraries following their conversion to
> RTE_LOG/RTE_LOG_LINE.
> 
> Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
> 
> Reported-by: Thomas Monjalon 
> Signed-off-by: David Marchand 
> ---
>  lib/dmadev/rte_dmadev.c   | 3 +--
>  lib/gpudev/gpudev.c   | 3 +--
>  lib/graph/graph_private.h | 2 +-
>  lib/node/node_private.h   | 2 +-
>  lib/telemetry/telemetry.c | 4 ++--
>  lib/vhost/vhost.h | 6 +++---
>  6 files changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 5953a77bd6..dbaa14f262 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -35,8 +35,7 @@ RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
>  #define RTE_LOGTYPE_DMA rte_dma_logtype
> 
>  #define RTE_DMA_LOG(level, ...) \
> - RTE_LOG_LINE(level, DMA, RTE_FMT("dma: " RTE_FMT_HEAD(__VA_ARGS__
> ,), \
> - RTE_FMT_TAIL(__VA_ARGS__ ,)))
> + RTE_LOG_LINE(level, DMA, "" __VA_ARGS__)
> 
>  int
>  rte_dma_dev_max(size_t dev_max)
> diff --git a/lib/gpudev/gpudev.c b/lib/gpudev/gpudev.c
> index de8291151f..1c2011b856 100644
> --- a/lib/gpudev/gpudev.c
> +++ b/lib/gpudev/gpudev.c
> @@ -20,8 +20,7 @@ RTE_LOG_REGISTER_DEFAULT(gpu_logtype, NOTICE);
>  #define RTE_LOGTYPE_GPUDEV gpu_logtype
> 
>  #define GPU_LOG(level, ...) \
> - RTE_LOG_LINE(level, GPUDEV, RTE_FMT("gpu: "
> RTE_FMT_HEAD(__VA_ARGS__ ,), \
> - RTE_FMT_TAIL(__VA_ARGS__ ,)))
> + RTE_LOG_LINE(level, GPUDEV, "" __VA_ARGS__)

Suggestion:
GPUDEV -> GPU, like DMA, not DMADEV.

> 
>  /* Set any driver error as EPERM */
>  #define GPU_DRV_RET(function) \
> diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
> index f9274ce96c..fb88d4bc84 100644
> --- a/lib/graph/graph_private.h
> +++ b/lib/graph/graph_private.h
> @@ -22,7 +22,7 @@ extern int rte_graph_logtype;
> 
>  #define GRAPH_LOG(level, ...)
> \
>   RTE_LOG_LINE(level, GRAPH,
> \
> - RTE_FMT("GRAPH: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),
> \
> + RTE_FMT("%s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),
> \
>   __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__ ,)))
> 
>  #define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
> diff --git a/lib/node/node_private.h b/lib/node/node_private.h
> index 845fdaa12e..73563e4cd2 100644
> --- a/lib/node/node_private.h
> +++ b/lib/node/node_private.h
> @@ -15,7 +15,7 @@ extern int rte_node_logtype;
> 
>  #define NODE_LOG(level, node_name, ...)
> \
>   RTE_LOG_LINE(level, NODE,
> \
> - RTE_FMT("NODE %s: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),
> \
> + RTE_FMT("%s: %s():%u " RTE_FMT_HEAD(__VA_ARGS__ ,),
> \
>   node_name, __func__, __LINE__,
> \
>   RTE_FMT_TAIL(__VA_ARGS__ ,)))
> 
> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
> index 31e2391867..47846ef868 100644
> --- a/lib/telemetry/telemetry.c
> +++ b/lib/telemetry/telemetry.c
> @@ -56,8 +56,8 @@ static const char *socket_dir;/* runtime
> directory */
>  static rte_cpuset_t *thread_cpuset;
> 
>  RTE_LOG_REGISTER_DEFAULT(logtype, WARNING);
> -#define RTE_LOGTYPE_TMTY logtype
> -#define TMTY_LOG_LINE(l, ...) RTE_LOG_LINE(l, TMTY, "TELEMETRY: "
> __VA_ARGS__)
> +#define RTE_LOGTYPE_TELEMETRY logtype
> +#define TMTY_LOG_LINE(l, ...) RTE_LOG_LINE(l, TELEMETRY, ""

+1 for TELEMETRY instead of TMTY.

> __VA_ARGS__)
> 
>  /* list of command callbacks, with one command registered by default
> */
>  static struct cmd_callback *callbacks;
> diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
> index 470dadbba6..0b13374980 100644
> --- a/lib/vhost/vhost.h
> +++ b/lib/vhost/vhost.h
> @@ -678,10 +678,10 @@ extern int vhost_data_log_level;
>  #define RTE_LOGTYPE_VHOST_DATA vhost_data_log_level
> 
>  #define VHOST_CONFIG_LOG(prefix, level, fmt, args...)\
> - RTE_LOG_LINE(level, VHOST_CONFIG, "VHOST_CONFIG: (%s) " fmt,
> prefix, ##args)
> + RTE_LOG_LINE(level, VHOST_CONFIG, "(%s) " fmt, prefix, ##args)
> 
>  #define VHOST_DATA_LOG(prefix, level, fmt, args...)  \
> - RTE_LOG_DP_LINE(level, VHOST_DATA, "VHOST_DATA: (%s) " fmt,
> prefix, ##args)
> + RTE_LOG_DP_LINE(level, VHOST_DATA, "(%s) " fmt, prefix, ##args)
> 
>  #ifdef RTE_LIBRTE_VHOST_DEBUG
>  #define VHOST_MAX_PRINT_BUFF 6072
> @@ -700,7 +700,7 @@ extern int vhost_data_log_level;
>   } \
>   snprintf(packet + strnlen(packet, VHOST_MAX_PRINT_BUFF),
> VHOST_MAX_PRINT_BUFF - strnlen(packet, VHOST_MAX_PRINT_BUFF), "\n"); \
>   \
> - RTE_LOG_DP(DEBUG

[PATCH] app/testpmd: add command to get Tx queue used count

[skoteshwar]

From: Satha Rao 

Fastpath API to get txq used count.

   testpmd> show port 0 txq 0 desc count

Signed-off-by: Satha Rao 
---
 app/test-pmd/cmdline.c | 78 ++
 1 file changed, 78 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f704319..1d09633 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -12638,6 +12638,83 @@ struct cmd_show_port_supported_ptypes_result {
},
 };
 
+/* *** display tx queue desc used count *** */
+struct cmd_show_tx_queue_desc_count_result {
+   cmdline_fixed_string_t cmd_show;
+   cmdline_fixed_string_t cmd_port;
+   cmdline_fixed_string_t cmd_txq;
+   cmdline_fixed_string_t cmd_desc;
+   cmdline_fixed_string_t cmd_count;
+   portid_t cmd_pid;
+   portid_t cmd_qid;
+};
+
+static void
+cmd_show_tx_queue_desc_count_parsed(void *parsed_result,
+   __rte_unused struct cmdline *cl,
+   __rte_unused void *data)
+{
+   struct cmd_show_tx_queue_desc_count_result *res = parsed_result;
+   int rc;
+
+   if (rte_eth_tx_queue_is_valid(res->cmd_pid, res->cmd_qid) != 0) {
+   fprintf(stderr, "Invalid input: port id = %d, queue id = %d\n", 
res->cmd_pid,
+   res->cmd_qid);
+   return;
+   }
+
+   rc = rte_eth_tx_queue_count(res->cmd_pid, res->cmd_qid);
+   if (rc < 0) {
+   fprintf(stderr, "Tx queue count get failed rc=%d 
queue_id=%d\n", rc, res->cmd_qid);
+   return;
+   }
+   printf("TxQ %d used desc count = %d\n", res->cmd_qid, rc);
+}
+
+static cmdline_parse_token_string_t cmd_show_tx_queue_desc_count_show =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_show, "show");
+static cmdline_parse_token_string_t cmd_show_tx_queue_desc_count_port =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_port, "port");
+static cmdline_parse_token_num_t cmd_show_tx_queue_desc_count_pid =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_pid, RTE_UINT16);
+static cmdline_parse_token_string_t cmd_show_tx_queue_desc_count_txq =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_txq, "txq");
+static cmdline_parse_token_num_t cmd_show_tx_queue_desc_count_qid =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_qid, RTE_UINT16);
+static cmdline_parse_token_string_t cmd_show_tx_queue_desc_count_desc =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_desc, "desc");
+static cmdline_parse_token_string_t cmd_show_tx_queue_desc_count_count =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_show_tx_queue_desc_count_result,
+cmd_count, "count");
+static cmdline_parse_inst_t cmd_show_tx_queue_desc_count = {
+   .f = cmd_show_tx_queue_desc_count_parsed,
+   .data = NULL,
+   .help_str = "show port  txq  desc count",
+   .tokens = {
+   (void *)&cmd_show_tx_queue_desc_count_show,
+   (void *)&cmd_show_tx_queue_desc_count_port,
+   (void *)&cmd_show_tx_queue_desc_count_pid,
+   (void *)&cmd_show_tx_queue_desc_count_txq,
+   (void *)&cmd_show_tx_queue_desc_count_qid,
+   (void *)&cmd_show_tx_queue_desc_count_desc,
+   (void *)&cmd_show_tx_queue_desc_count_count,
+   NULL,
+   },
+};
+
 /* *** display rx/tx descriptor status *** */
 struct cmd_show_rx_tx_desc_status_result {
cmdline_fixed_string_t cmd_show;
@@ -13346,6 +13423,7 @@ struct cmd_config_tx_affinity_map {
(cmdline_parse_inst_t *)&cmd_show_tx_metadata,
(cmdline_parse_inst_t *)&cmd_show_rx_tx_desc_status,
(cmdline_parse_inst_t *)&cmd_show_rx_queue_desc_used_count,
+   (cmdline_parse_inst_t *)&cmd_show_tx_queue_desc_count,
(cmdline_parse_inst_t *)&cmd_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw_all,
-- 
1.8.3.1

[PATCH] test/event: skip test if no driver is present

[David Marchand]

Align eventdev with what other device abstraction libraries do: if no
driver is present, skip the tests.

Fixes: f8f9d233ea0e ("test/eventdev: add unit tests")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 app/test/test_eventdev.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index 71de947ce4..e4e234dc98 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -33,9 +33,15 @@ testsuite_setup(void)
uint8_t count;
count = rte_event_dev_count();
if (!count) {
+   int ret;
+
printf("Failed to find a valid event device,"
-   " testing with event_skeleton device\n");
-   return rte_vdev_init("event_skeleton", NULL);
+   " trying with event_skeleton device\n");
+   ret = rte_vdev_init("event_skeleton", NULL);
+   if (ret != 0) {
+   printf("No event device, skipping\n");
+   return TEST_SKIPPED;
+   }
}
return TEST_SUCCESS;
 }
-- 
2.43.0

Re: [PATCH] net/vmxnet3: fix use of interrupts on FreeBSD

[Lewis Donzis]

Did this get checked in?

Just curious because I don't see it in 22.11.4 that was released yesterday, so 
wasn't sure when it would show up.

Thanks,
lew

- On Jan 11, 2024, at 6:03 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:

> On 1/9/2024 4:00 PM, Lewis Donzis wrote:
>> 
>> 
>> - On Jan 9, 2024, at 8:23 AM, Bruce Richardson bruce.richard...@intel.com
>> wrote:
>> 
>>> DPDK does not support interrupts on FreeBSD, so the vmxnet3 driver
>>> returns error when enabling interrupts as it initializes. We can fix
>>> this by #ifdef'ing out the interrupt calls when building for FreeBSD,
>>> allowing the driver to initialize correctly.
>>>
>>> Fixes: 046f11619567 ("net/vmxnet3: support MSI-X interrupt")
>>>
>>> Reported-by: Lewis Donzis 
>>> Signed-off-by: Bruce Richardson 
>>> >
>> Tested-by: Lewis Donzis 
>>
> 
> Acked-by: Ferruh Yigit 
> 
> Applied to dpdk-next-net/main, thanks.

[PATCH] net/cnxk: support Tx queue descriptor count

[skoteshwar]

From: Satha Rao 

Added cnxk APIs to get used txq descriptor count.

Signed-off-by: Satha Rao 
---
 doc/guides/nics/features/cnxk.ini |  1 +
 drivers/net/cnxk/cn10k_ethdev.c   | 10 ++
 drivers/net/cnxk/cn9k_ethdev.c| 10 ++
 drivers/net/cnxk/cnxk_ethdev.h| 11 +++
 4 files changed, 32 insertions(+)

diff --git a/doc/guides/nics/features/cnxk.ini 
b/doc/guides/nics/features/cnxk.ini
index ac7de9a..5cc12ef 100644
--- a/doc/guides/nics/features/cnxk.ini
+++ b/doc/guides/nics/features/cnxk.ini
@@ -40,6 +40,7 @@ Timesync = Y
 Timestamp offload= Y
 Rx descriptor status = Y
 Tx descriptor status = Y
+Tx queue count   = Y
 Basic stats  = Y
 Stats per queue  = Y
 Extended stats   = Y
diff --git a/drivers/net/cnxk/cn10k_ethdev.c b/drivers/net/cnxk/cn10k_ethdev.c
index 4a4e972..3a3b8db 100644
--- a/drivers/net/cnxk/cn10k_ethdev.c
+++ b/drivers/net/cnxk/cn10k_ethdev.c
@@ -768,6 +768,14 @@
return rc;
 }
 
+static int
+cn10k_nix_tx_queue_count(void *tx_queue)
+{
+   struct cn10k_eth_txq *txq = (struct cn10k_eth_txq *)tx_queue;
+
+   return cnxk_nix_tx_queue_count(txq->fc_mem, txq->sqes_per_sqb_log2);
+}
+
 /* Update platform specific eth dev ops */
 static void
 nix_eth_dev_ops_override(void)
@@ -866,6 +874,8 @@
return -ENOENT;
}
 
+   eth_dev->tx_queue_count = cn10k_nix_tx_queue_count;
+
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
/* Setup callbacks for secondary process */
cn10k_eth_set_tx_function(eth_dev);
diff --git a/drivers/net/cnxk/cn9k_ethdev.c b/drivers/net/cnxk/cn9k_ethdev.c
index bae4dda..b7c4f59 100644
--- a/drivers/net/cnxk/cn9k_ethdev.c
+++ b/drivers/net/cnxk/cn9k_ethdev.c
@@ -689,6 +689,14 @@
cn9k_nix_timesync_read_tx_timestamp;
 }
 
+static int
+cn9k_nix_tx_queue_count(void *tx_queue)
+{
+   struct cn9k_eth_txq *txq = (struct cn9k_eth_txq *)tx_queue;
+
+   return cnxk_nix_tx_queue_count(txq->fc_mem, txq->sqes_per_sqb_log2);
+}
+
 /* Update platform specific eth dev ops */
 static void
 nix_tm_ops_override(void)
@@ -759,6 +767,8 @@
return -ENOENT;
}
 
+   eth_dev->tx_queue_count = cn9k_nix_tx_queue_count;
+
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
/* Setup callbacks for secondary process */
cn9k_eth_set_tx_function(eth_dev);
diff --git a/drivers/net/cnxk/cnxk_ethdev.h b/drivers/net/cnxk/cnxk_ethdev.h
index 4d3ebf1..0fe8b72 100644
--- a/drivers/net/cnxk/cnxk_ethdev.h
+++ b/drivers/net/cnxk/cnxk_ethdev.h
@@ -458,6 +458,17 @@ struct cnxk_eth_txq_sp {
return ((struct cnxk_eth_txq_sp *)__txq) - 1;
 }
 
+static inline int
+cnxk_nix_tx_queue_count(uint64_t *mem, uint16_t sqes_per_sqb_log2)
+{
+   uint64_t val;
+
+   val = rte_atomic_load_explicit(mem, rte_memory_order_relaxed);
+   val = (val << sqes_per_sqb_log2) - val;
+
+   return (val & 0x);
+}
+
 /* Common ethdev ops */
 extern struct eth_dev_ops cnxk_eth_dev_ops;
 
-- 
1.8.3.1

Re: [PATCH 01/12] eal: introduce more macro for bit definition

[Thomas Monjalon]

22/01/2024 04:57, Chengwen Feng:
> Introduce macros: RTE_MBIT64/RTE_MBIT32, RTE_GENMASK64/RTE_GENMASK32,
> and RTE_FIELD_GET64/RTE_FIELD_GET32.

A bit of context and description would help.

> +/**
> + * Get the uint64_t value for a multiple bits set.
> + *
> + * @param val
> + *   The value may not all 1s.
> + * @param nr
> + *   The bit number in range of 0 to (64 - width of val).
> + */
> +#define RTE_MBIT64(val, nr) (UINT64_C(val) << (nr))

I don't understand this macro.
I think you mean that val is shifted by nr.
Please revise the description.  
   

Re: [PATCH 04/12] test/argparse: add verify argument config test

[Thomas Monjalon]

22/01/2024 04:57, Chengwen Feng:
> This commit adds verify argument config test.
> 
> Signed-off-by: Chengwen Feng 

Test can be squashed in the commit adding the feature.

RE: [PATCH v4 1/8] arg_parser: new library for command line parsing

[Morten Brørup]

> From: Euan Bourke [mailto:euan.bou...@intel.com]
> Sent: Friday, 15 December 2023 18.26
> 
> Add a new library to make it easier for eal and other libraries to
> parse
> command line arguments.
> 
> The first function in this library is one to parse a corelist string
> into an array of individual core ids. The function will then return the
> total number of cores described in the corelist.
> 
> Signed-off-by: Euan Bourke 
> ---

It would be nice if the library supported open-ended ranges, i.e. "-3" meaning 
all available cores up to and including 3, and "3-" meaning all available cores 
from 3 and up.

Re: [PATCH 02/12] argparse: add argparse library

[Thomas Monjalon]

22/01/2024 04:57, Chengwen Feng:
> Introduce argparse library (which was inspired by the thread [1]). This
> commit provides public API and doc.
> 
> [1] 
> https://patchwork.dpdk.org/project/dpdk/patch/20231105054539.22303-2-fengcheng...@huawei.com/

I'm not sure how this helps with the initial problem
when using kvargs with key-only.
I think you should continue fixing kvargs API and usage.

About a generic argparse library, I imagine it could simplify DPDK internal 
parsing.
I have doubts about making it a public library as it is not really a DPDK goal.
The DMA example looks better with argparse so I imagine we want it.

I think this library would have a bigger value
if we integrate some specific syntax parsing
like coremask/corelist as done in another patchset:
https://patches.dpdk.org/project/dpdk/list/?series=30582

Re: [PATCH] lib: remove duplicate prefix in logs

[Bruce Richardson]

On Wed, Jan 24, 2024 at 01:04:49PM +0100, David Marchand wrote:
> RTE_LOG() macros prefixe the log messages based on the logtype.
> This results in logs like:
> 
> TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> TMTY: TELEMETRY: Socket creation and binding ok
> TMTY: TELEMETRY: Telemetry initialized ok
> 
> Remove redundancy in some libraries following their conversion to
> RTE_LOG/RTE_LOG_LINE.
> 
> Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
> 
> Reported-by: Thomas Monjalon 
> Signed-off-by: David Marchand 
> ---
>  lib/dmadev/rte_dmadev.c   | 3 +--
>  lib/gpudev/gpudev.c   | 3 +--
>  lib/graph/graph_private.h | 2 +-
>  lib/node/node_private.h   | 2 +-
>  lib/telemetry/telemetry.c | 4 ++--
>  lib/vhost/vhost.h | 6 +++---
>  6 files changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 5953a77bd6..dbaa14f262 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -35,8 +35,7 @@ RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
>  #define RTE_LOGTYPE_DMA rte_dma_logtype
>  
>  #define RTE_DMA_LOG(level, ...) \
> - RTE_LOG_LINE(level, DMA, RTE_FMT("dma: " RTE_FMT_HEAD(__VA_ARGS__ ,), \
> - RTE_FMT_TAIL(__VA_ARGS__ ,)))
> + RTE_LOG_LINE(level, DMA, "" __VA_ARGS__)
>  

Is it not useful to have the prefix in the log macro itself? That way it's
consistent across all messages.

/Bruce

Re: [PATCH 12/12] examples/dma: replace getopt with argparse

[Thomas Monjalon]

22/01/2024 04:58, Chengwen Feng:
> -#define CMD_LINE_OPT_MAC_UPDATING "mac-updating"
> -#define CMD_LINE_OPT_NO_MAC_UPDATING "no-mac-updating"
> -#define CMD_LINE_OPT_PORTMASK "portmask"
> -#define CMD_LINE_OPT_NB_QUEUE "nb-queue"
> -#define CMD_LINE_OPT_COPY_TYPE "copy-type"
> -#define CMD_LINE_OPT_RING_SIZE "ring-size"
> -#define CMD_LINE_OPT_BATCH_SIZE "dma-batch-size"
> -#define CMD_LINE_OPT_FRAME_SIZE "max-frame-size"
> -#define CMD_LINE_OPT_FORCE_COPY_SIZE "force-min-copy-size"
> -#define CMD_LINE_OPT_STATS_INTERVAL "stats-interval"
> +#define CMD_LINE_OPT_MAC_UPDATING "--mac-updating"
> +#define CMD_LINE_OPT_NO_MAC_UPDATING "--no-mac-updating"
> +#define CMD_LINE_OPT_PORTMASK "--portmask"
> +#define CMD_LINE_OPT_PORTMASK_INDEX 1
> +#define CMD_LINE_OPT_NB_QUEUE "--nb-queue"
> +#define CMD_LINE_OPT_COPY_TYPE "--copy-type"
> +#define CMD_LINE_OPT_COPY_TYPE_INDEX 2
> +#define CMD_LINE_OPT_RING_SIZE "--ring-size"
> +#define CMD_LINE_OPT_BATCH_SIZE "--dma-batch-size"
> +#define CMD_LINE_OPT_FRAME_SIZE "--max-frame-size"
> +#define CMD_LINE_OPT_FORCE_COPY_SIZE "--force-min-copy-size"
> +#define CMD_LINE_OPT_STATS_INTERVAL "--stats-interval"

I would completely drop these defines.
It would be easier to read the string directly in .args below:

[...]
> + .args = {
> + { CMD_LINE_OPT_MAC_UPDATING, NULL, "Enable MAC 
> addresses updating",
> +   &mac_updating, (void *)1,
> +   RTE_ARGPARSE_ARG_NO_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_INT,
> + },
> + { CMD_LINE_OPT_NO_MAC_UPDATING, NULL, "Disable MAC 
> addresses updating",
> +   &mac_updating, (void *)0,
> +   RTE_ARGPARSE_ARG_NO_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_INT,
> + },
> + { CMD_LINE_OPT_PORTMASK, "-p", "hexadecimal bitmask of 
> ports to configure",
> +   NULL, (void *)CMD_LINE_OPT_PORTMASK_INDEX,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE,
> + },
> + { CMD_LINE_OPT_NB_QUEUE, "-q", "number of RX queues per 
> port (default is 1)",
> +   &nb_queues, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U16,
> + },
> + { CMD_LINE_OPT_COPY_TYPE, "-c", "type of copy: sw|hw",
> +   NULL, (void *)CMD_LINE_OPT_COPY_TYPE_INDEX,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE,
> + },
> + { CMD_LINE_OPT_RING_SIZE, "-s", "size of dmadev 
> descriptor ring for hardware copy mode or rte_ring for software copy mode",
> +   &ring_size, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U16,
> + },
> + { CMD_LINE_OPT_BATCH_SIZE, "-b", "number of requests 
> per DMA batch",
> +   &dma_batch_sz, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U32,
> + },
> + { CMD_LINE_OPT_FRAME_SIZE, "-f", "max frame size",
> +   &max_frame_size, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U32,
> + },
> + { CMD_LINE_OPT_FORCE_COPY_SIZE, "-m", "force a minimum 
> copy length, even for smaller packets",
> +   &force_min_copy_size, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U32,
> + },
> + { CMD_LINE_OPT_STATS_INTERVAL, "-i", "interval, in 
> seconds, between stats prints (default is 1)",
> +   &stats_interval, NULL,
> +   RTE_ARGPARSE_ARG_REQUIRED_VALUE | 
> RTE_ARGPARSE_ARG_VALUE_U16,
> + },
> + ARGPARSE_ARG_END(),

Re: [PATCH] lib: remove duplicate prefix in logs

[Bruce Richardson]

On Wed, Jan 24, 2024 at 01:26:58PM +, Bruce Richardson wrote:
> On Wed, Jan 24, 2024 at 01:04:49PM +0100, David Marchand wrote:
> > RTE_LOG() macros prefixe the log messages based on the logtype.
> > This results in logs like:
> > 
> > TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> > TMTY: TELEMETRY: Socket creation and binding ok
> > TMTY: TELEMETRY: Telemetry initialized ok
> > 
> > Remove redundancy in some libraries following their conversion to
> > RTE_LOG/RTE_LOG_LINE.
> > 
> > Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> > Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
> > 
> > Reported-by: Thomas Monjalon 
> > Signed-off-by: David Marchand 
> > ---
> >  lib/dmadev/rte_dmadev.c   | 3 +--
> >  lib/gpudev/gpudev.c   | 3 +--
> >  lib/graph/graph_private.h | 2 +-
> >  lib/node/node_private.h   | 2 +-
> >  lib/telemetry/telemetry.c | 4 ++--
> >  lib/vhost/vhost.h | 6 +++---
> >  6 files changed, 9 insertions(+), 11 deletions(-)
> > 
> > diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> > index 5953a77bd6..dbaa14f262 100644
> > --- a/lib/dmadev/rte_dmadev.c
> > +++ b/lib/dmadev/rte_dmadev.c
> > @@ -35,8 +35,7 @@ RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
> >  #define RTE_LOGTYPE_DMA rte_dma_logtype
> >  
> >  #define RTE_DMA_LOG(level, ...) \
> > -   RTE_LOG_LINE(level, DMA, RTE_FMT("dma: " RTE_FMT_HEAD(__VA_ARGS__ ,), \
> > -   RTE_FMT_TAIL(__VA_ARGS__ ,)))
> > +   RTE_LOG_LINE(level, DMA, "" __VA_ARGS__)
> >  
> 
> Is it not useful to have the prefix in the log macro itself? That way it's
> consistent across all messages.
> 
Sorry, I think I misunderstood the problem and fix. Please ignore this
mail.

Re: [PATCH v4 1/8] arg_parser: new library for command line parsing

[Bruce Richardson]

On Wed, Jan 24, 2024 at 02:16:13PM +0100, Morten Brørup wrote:
> > From: Euan Bourke [mailto:euan.bou...@intel.com]
> > Sent: Friday, 15 December 2023 18.26
> > 
> > Add a new library to make it easier for eal and other libraries to
> > parse
> > command line arguments.
> > 
> > The first function in this library is one to parse a corelist string
> > into an array of individual core ids. The function will then return the
> > total number of cores described in the corelist.
> > 
> > Signed-off-by: Euan Bourke 
> > ---
> 
> It would be nice if the library supported open-ended ranges, i.e. "-3" 
> meaning all available cores up to and including 3, and "3-" meaning all 
> available cores from 3 and up.
> 
Yes, that could be a useful enhancement. For now these functions are just
based off what is already implemented in EAL, with minimal enhancements.

/Bruce

Re: [PATCH v4 0/8] add new command line argument parsing library

[Thomas Monjalon]

18/12/2023 10:18, Bruce Richardson:
> On Fri, Dec 15, 2023 at 01:53:21PM -0800, Stephen Hemminger wrote:
> > On Fri, 15 Dec 2023 17:26:24 +
> > Euan Bourke  wrote:
> > 
> > > A recent thread on the mailing list[1] discussed corelist and coremask
> > > parsing and the idea of a new library dedicated to command line parsing
> > > was mentioned[2]. This patchset adds the library, along with the new
> > > APIs, and edits the existing EAL, DLB2 driver and some example
> > > application functions to use these APIs, rather than each implementing
> > > their own copies.
> > > 
> > > The new APIs work similar to the existing functions in EAL, however
> > > instead of filling a core array like this:
> > > [1, -1, -1, 2, 3] (a non -1 refers to an 'active core' at that index)
> > > It fills it like this:
> > > [0, 3, 4] (with the value at each index being an 'active core').
> > > 
> > > The new APIs will also return the number of cores contained in the
> > > passed corelist/coremask, so in the above example, 3 would be returned.
> > > 
> > > Also included in this patchest is a heuristic parser which searches
> > > for key markers in the core string, returning a enum value based off
> > > this search to indicate if a parameter is likely a coremask or a
> > > corelist. This heuristic function is also wrapped in a parser
> > > function allowing apps to handle both coremasks and corelists
> > > simultaneously.
> > > 
> > > [1] https://mails.dpdk.org/archives/dev/2023-November/280957.html
> > > [2] https://mails.dpdk.org/archives/dev/2023-November/280966.html
> > > 
> > 
> > The code is ok, but the naming needs to change.
> > 
> > To me the name argparse implies that library implements something
> > similar to Python argparse. But that isn't what this library does.
> > It seems limited to just cpu masks. Perhaps cpuparse would be better name
> > or make it part of a larger implementation of a full library
> > more like Python argparse.
> 
> Yes, it is a limited set of functions, so the name is probably not ideal if
> that's what it's going to remaini (though what library ever stays
> un-expanded once started!).

This is a string parsing library.

> I think we need a general discussion
> on-list and probably in tech-board too about argument handling, since in
> the last couple of months there have been no less than 3 separate
> independent proposals around functionality for arguments.
> 
> There has been:
> * This set, for extracting out functions for processing coremask and
>   corelist arguments. Presumably other argument parsing types may look to
>   be included in future e.g. device args, perhaps.
> * A set from me [1], looking to take the slightly opposite side of things, 
> and 
>   make it easier for apps to initialize EAL with a custom argument set. So
>   it can be thought of as an argument-list management library.
> * An "argparse" library from Chengwen [2] which does what you describe
>   above and be a C implementation like the python argparse module.
> 
> We need to decide how to manage all these three, if we want to take them
> all, and if they should all be merged into a single library, or some kept
> separate from others.

Yes, we need to decide whether we want to keep this string parsing
as a standalone library, or we prefer to integrate it in Chengwen's
global argument parsing library.

The question is do we want to do string parsing out of the global argument 
parsing?
I suppose the answer is yes, at least when parsing devargs in drivers.
In this case we need this library to be standalone (and reused in Chengwen's 
argparse).

Re: [PATCH v5 05/11] net/nfp: use rte_pktmbuf_mtod_offset

[Thomas Monjalon]

10/07/2023 14:19, Niklas Söderlund:
> On 2023-07-07 18:57:12 -0700, Stephen Hemminger wrote:
> > Replace explicit packet offset computations with rte_pktmbuf_mtod_offset().
> > 
> > Signed-off-by: Stephen Hemminger 
> 
> Reviewed-by: Niklas Söderlund 

A similar change by Chaoyong He has been merged in 23.11.

[dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

[Rahul Gupta]

From: Rahul Gupta 

In continuation to the following email, I am sending this patch.
(https://inbox.dpdk.org/dev/20231110172523.ga17...@microsoft.com/)

Initialization requires rte_eal_init + rte_pktmbuf_pool_create which
can consume a total time of 500-600 ms:
a) For many devices FLR may take a significant chunk of time
   (200-250 ms in our use-case), this FLR is triggered during device
   probe in rte_eal_init().
b) rte_pktmbuf_pool_create() can consume up to 300-350 ms for
applications that require huge memory.

This cost is incurred on each restart (which happens in our use-case
during binary updates for servicing).
This patch provides an optimization using pthreads that applications
can use and which can save 200-230ms.

In this patch, rte_eal_init() is refactored into two parts-
a) 1st part is dependent code ie- it’s a perquisite of the FLR and
   mempool creation. So this code needs to be executed before any
   pthreads. Its named as rte_eal_init_setup()
b) 2nd part of code is independent code ie- it can execute in parallel
   to mempool creation in a pthread. Its named as rte_eal_init_async_setup().

In existing applications no changes are required unless they wish to leverage
the optimization.

If the application wants to leverage this optimization, then it needs to call
rte_eal_init_async() (instead of call rte_eal_init()), then it can create a
thread using rte_eal_remote_launch() to schedule a task it would like todo in
parallel rte_eal_init_async_setup(), this task can be a mbuf pool creation
using- rte_pktmbuf_pool_create()

After this, if next operations require completion of above task, then
user can use rte_eal_init_wait_async_setup_complete(),
or if user wants to just check status of that thread, then use-
rte_eal_init_async_setup_done()

---
v2: Address Stephen Hemminger's comment
---
v3: address support for single lcore
---
v4: address Brue Richardson and Stephen Hemminger comment
Existing application need not do any changes if bootup optimization is not 
needed.

 app/test-pmd/testpmd.c|  24 -
 lib/eal/include/rte_eal.h | 107 ++
 lib/eal/linux/eal.c   |  62 --
 lib/eal/version.map   |   7 +++
 4 files changed, 196 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 9e4e99e53b..c8eb194f64 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -4531,6 +4531,8 @@ main(int argc, char** argv)
portid_t port_id;
uint16_t count;
int ret;
+   int lcore_id;
+   int main_lcore_id;
 
 #ifdef RTE_EXEC_ENV_WINDOWS
signal(SIGINT, signal_handler);
@@ -4550,11 +4552,31 @@ main(int argc, char** argv)
rte_exit(EXIT_FAILURE, "Cannot register log type");
rte_log_set_level(testpmd_logtype, RTE_LOG_DEBUG);
 
-   diag = rte_eal_init(argc, argv);
+   diag = rte_eal_init_async(argc, argv);
if (diag < 0)
rte_exit(EXIT_FAILURE, "Cannot init EAL: %s\n",
 rte_strerror(rte_errno));
 
+   main_lcore_id = rte_get_main_lcore();
+   lcore_id = rte_get_next_lcore(main_lcore_id, 0, 1);
+   /* Gives status of rte_eal_init_async() */
+   if (main_lcore_id != lcore_id)
+   while (rte_eal_init_async_setup_done(lcore_id) == 0)
+   ;
+
+   /*
+* Use rte_eal_init_wait_async_setup_complete() to get return value of
+* rte_eal_init_async().
+* Or
+* if testpmd application don't want to know progress/status of
+* rte_eal_init_async() and just want to wait till it finishes
+* then use following function.
+*/
+   ret = rte_eal_init_wait_async_setup_complete();
+   if (ret < 0)
+   rte_exit(EXIT_FAILURE, "Cannot init EAL: "
+"rte_eal_init_async() failed: %s\n",
+strerror(ret));
/* allocate port structures, and init them */
init_port();
 
diff --git a/lib/eal/include/rte_eal.h b/lib/eal/include/rte_eal.h
index c2256f832e..6d7044b632 100644
--- a/lib/eal/include/rte_eal.h
+++ b/lib/eal/include/rte_eal.h
@@ -111,6 +111,113 @@ int rte_eal_iopl_init(void);
  */
 int rte_eal_init(int argc, char **argv);
 
+/**
+ * Initialize the Environment Abstraction Layer (EAL).
+ *
+ * This function is to be executed on the MAIN lcore only, as soon
+ * as possible in the application's main() function.
+ * It puts the WORKER lcores in the WAIT state.
+ *
+ * @param argc
+ *   A non-negative value.  If it is greater than 0, the array members
+ *   for argv[0] through argv[argc] (non-inclusive) shall contain pointers
+ *   to strings.
+ * @param argv
+ *   An array of strings.  The contents of the array, as well as the strings
+ *   which are pointed to by the array, may be modified by this function.
+ *   The program name pointer argv[0] is copied into the last parsed argv
+ *   so that argv[0] is still the same after

Re: [PATCH v5 06/11] net/tap: use rte_pktmbuf_motd_offset

[Thomas Monjalon]

08/07/2023 03:57, Stephen Hemminger:
> Replace explicit packet offset computations with rte_pktmbuf_mtod_offset().
> 
> Signed-off-by: Stephen Hemminger 

It has been reworked by David Marchand in 23.11.

RE: [24.03 RFC 1/3] args: new library to allow easier manipulation of cmdline args

[Honnappa Nagarahalli]

> 
> 02/11/2023 18:28, Bruce Richardson:
> > Add a new small library to make it easier for apps to work with
> > cmdline arguments and build up args to use when initializing EAL.
> >
> > This library is optional, and can be disabled at build time using the
> > disable libraries meson option.
> 
> This is an optional helper, so why not.
> 
> Another help for applications would be to allow initializing DPDK without the
> need of passing or building argc/argv arguments.
> I think we could add new functions rte_eal_init_*().
> Example:
>   rte_eal_init_prepare()
>   rte_eal_init_memory(memory parameters)
>   rte_eal_init_devices(devargs)
>   rte_eal_init_threads()
> 
> It should be possible to rebuild rte_eal_init() using above smaller functions 
> to
> keep the big old rte_eal_init with argc/argv for compatibility.
We have to ensure these new APIs and argc/argv are in sync in future changes. 
For ex: if we add a new parameter to the API, we need a new argv. This is not a 
problem, but we have to do this manually.

> 

Re: [PATCH] net/vmxnet3: fix use of interrupts on FreeBSD

[Ferruh Yigit]

On 1/24/2024 12:34 PM, Lewis Donzis wrote:

> - On Jan 11, 2024, at 6:03 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:
> 
>> On 1/9/2024 4:00 PM, Lewis Donzis wrote:
>>>
>>>
>>> - On Jan 9, 2024, at 8:23 AM, Bruce Richardson 
>>> bruce.richard...@intel.com
>>> wrote:
>>>
 DPDK does not support interrupts on FreeBSD, so the vmxnet3 driver
 returns error when enabling interrupts as it initializes. We can fix
 this by #ifdef'ing out the interrupt calls when building for FreeBSD,
 allowing the driver to initialize correctly.

 Fixes: 046f11619567 ("net/vmxnet3: support MSI-X interrupt")

 Reported-by: Lewis Donzis 
 Signed-off-by: Bruce Richardson 
>
>>> Tested-by: Lewis Donzis 
>>>
>>
>> Acked-by: Ferruh Yigit 
>>
>> Applied to dpdk-next-net/main, thanks.
>
> Did this get checked in?
>
> Just curious because I don't see it in 22.11.4 that was released
yesterday, so wasn't sure when it would show up.
>
>

Hi Lew,

It has been merged into the 'next-net' subtree and will be subsequently
pulled into the 'main' tree. Eventually, it will be included in the
24.03 release.

LTS releases will backport the fix after the release of v24.03.

If you are interested in 22.11.# LTS, this fix is expected to be
included in v22.11.5 scheduled for release in April."

Re: [PATCH] net/vmxnet3: fix use of interrupts on FreeBSD

[Lewis Donzis]

- On Jan 24, 2024, at 7:58 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:

> On 1/24/2024 12:34 PM, Lewis Donzis wrote:
> 
>> - On Jan 11, 2024, at 6:03 AM, Ferruh Yigit ferruh.yi...@amd.com wrote:
>> 
>>> On 1/9/2024 4:00 PM, Lewis Donzis wrote:


 - On Jan 9, 2024, at 8:23 AM, Bruce Richardson 
 bruce.richard...@intel.com
 wrote:

> DPDK does not support interrupts on FreeBSD, so the vmxnet3 driver
> returns error when enabling interrupts as it initializes. We can fix
> this by #ifdef'ing out the interrupt calls when building for FreeBSD,
> allowing the driver to initialize correctly.
>
> Fixes: 046f11619567 ("net/vmxnet3: support MSI-X interrupt")
>
> Reported-by: Lewis Donzis 
> Signed-off-by: Bruce Richardson 
>>
 Tested-by: Lewis Donzis 

>>>
>>> Acked-by: Ferruh Yigit 
>>>
>>> Applied to dpdk-next-net/main, thanks.
>>
>> Did this get checked in?
>>
>> Just curious because I don't see it in 22.11.4 that was released
> yesterday, so wasn't sure when it would show up.
>>
>>
> 
> Hi Lew,
> 
> It has been merged into the 'next-net' subtree and will be subsequently
> pulled into the 'main' tree. Eventually, it will be included in the
> 24.03 release.
> 
> LTS releases will backport the fix after the release of v24.03.
> 
> If you are interested in 22.11.# LTS, this fix is expected to be
> included in v22.11.5 scheduled for release in April."

Perfect, thanks very much for the explanation.

lew

RE: [PATCH] lib: remove duplicate prefix in logs

[Power, Ciara]

> -Original Message-
> From: David Marchand 
> Sent: Wednesday, January 24, 2024 12:05 PM
> To: dev@dpdk.org
> Cc: Thomas Monjalon ; Chengwen Feng
> ; Laatz, Kevin ;
> Richardson, Bruce ; Elena Agostini
> ; Jerin Jacob ; Kiran Kumar K
> ; Nithin Dabilpuram
> ; Yan, Zhirun ; Pavan
> Nikhilesh ; Power, Ciara
> ; Maxime Coquelin
> ; Chenbo Xia ;
> Andrew Rybchenko 
> Subject: [PATCH] lib: remove duplicate prefix in logs
> 
> RTE_LOG() macros prefixe the log messages based on the logtype.
> This results in logs like:
> 
> TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> TMTY: TELEMETRY: Socket creation and binding ok
> TMTY: TELEMETRY: Telemetry initialized ok
> 
> Remove redundancy in some libraries following their conversion to
> RTE_LOG/RTE_LOG_LINE.
> 
> Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
> 
> Reported-by: Thomas Monjalon 
> Signed-off-by: David Marchand 
> ---
>  lib/dmadev/rte_dmadev.c   | 3 +--
>  lib/gpudev/gpudev.c   | 3 +--
>  lib/graph/graph_private.h | 2 +-
>  lib/node/node_private.h   | 2 +-
>  lib/telemetry/telemetry.c | 4 ++--
>  lib/vhost/vhost.h | 6 +++---
>  6 files changed, 9 insertions(+), 11 deletions(-)
> 


Acked-by: Ciara Power 

Re: [PATCH v5 00/11] use rte_pktmbuf_mto_offset

[Thomas Monjalon]

> > Stephen Hemminger (11):
> >   gro: use rte_pktmbuf_mtod_offset
> >   gso: use rte_pktmbuf_mtod_offset
> >   test/crypto_dev: use rte_pktmbuf_mtod_offset
> >   drivers/crypto: use rte_pktmbuf_mtod_offset
> >   net/nfp: use rte_pktmbuf_mtod_offset
> >   net/tap: use rte_pktmbuf_motd_offset
> >   baseband/fpga: use rte_pktmbuf_offset
> >   cpt: use rte_pktmbuf_mtod_offset
> >   testpmd: use rte_pktmbuf_mtod_offset
> >   examples/ptpclient: use rte_pktmbuf_mtod_offset
> >   examples/l2fwd-crypto: use rte_pktmbuf_mtod_offset
> 
> Series-acked-by: Chengwen Feng 

Applied except 2 patches which are no longer relevant, thanks.

RE: [EXT] Re: [PATCH 1/2] config/arm: avoid mcpu and march conflicts

[Pavan Nikhilesh Bhagavatula]

> -Original Message-
> From: Juraj Linkeš 
> Sent: Monday, January 22, 2024 9:57 PM
> To: Pavan Nikhilesh Bhagavatula 
> Cc: Jerin Jacob ; ruifeng.w...@arm.com;
> n...@arm.com; Bruce Richardson ;
> dev@dpdk.org
> Subject: Re: [EXT] Re: [PATCH 1/2] config/arm: avoid mcpu and march
> conflicts
> 
> On Mon, Jan 22, 2024 at 12:54 PM Pavan Nikhilesh Bhagavatula
>  wrote:
> >
> > > On Sun, Jan 21, 2024 at 10:37 AM  wrote:
> > > >
> > > > From: Pavan Nikhilesh 
> > > >
> > > > The compiler options march and mtune are a subset
> > > > of mcpu and will lead to conflicts if improper march
> > > > is chosen for a given mcpu.
> > > > To avoid conflicts, force part number march when
> > > > mcpu is available and is supported by the compiler.
> > > >
> > > > Example:
> > > > march = armv9-a
> > > > mcpu = neoverse-n2
> > > >
> > > > mcpu supported, march supported
> > > > machine_args = ['-mcpu=neoverse-n2', '-march=armv9-a']
> > > >
> > > > mcpu supported, march not supported
> > > > machine_args = ['-mcpu=neoverse-n2']
> > > >
> > > > mcpu not supported, march supported
> > > > machine_args = ['-march=armv9-a']
> > > >
> > > > mcpu not supported, march not supported
> > > > machine_args = ['-march=armv8.6-a']
> > > >
> > > > Signed-off-by: Pavan Nikhilesh 
> > > > ---
> > > >  config/arm/meson.build | 109 +-
> -
> > > --
> > > >  1 file changed, 67 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/config/arm/meson.build b/config/arm/meson.build
> > > > index 36f21d2259..8c8cfccca0 100644
> > > > --- a/config/arm/meson.build
> > > > +++ b/config/arm/meson.build
> > > 
> > > > @@ -127,21 +128,22 @@ implementer_cavium = {
> > > >  ],
> > > >  'part_number_config': {
> > > >  '0xa1': {
> > > > -'compiler_options': ['-mcpu=thunderxt88'],
> > > > +'mcpu': 'thunderxt88',
> > > >  'flags': flags_part_number_thunderx
> > > >  },
> > > >  '0xa2': {
> > > > -'compiler_options': ['-mcpu=thunderxt81'],
> > > > +'mcpu': 'thunderxt81',
> > > >  'flags': flags_part_number_thunderx
> > > >  },
> > > >  '0xa3': {
> > > > -'compiler_options': ['-march=armv8-a+crc', '-
> mcpu=thunderxt83'],
> > > > +'mcpu': 'thunderxt83',
> > > > +'compiler_options': ['-march=armv8-a+crc'],
> > >
> > > Let's unify this with the rest and specify 'march': 'armv8-a+crc'
> > > instead of having it under compiler_options.
> >
> > Ack.
> >
> > >
> > > >  'flags': flags_part_number_thunderx
> > > >  },
> > > >  '0xaf': {
> > > >  'march': 'armv8.1-a',
> > > >  'march_features': ['crc', 'crypto'],
> > > > -'compiler_options': ['-mcpu=thunderx2t99'],
> > > > +'mcpu': 'thunderx2t99',
> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"thunderx2"'],
> > > >  ['RTE_ARM_FEATURE_ATOMICS', true],
> > > > @@ -153,7 +155,7 @@ implementer_cavium = {
> > > >  '0xb2': {
> > > >  'march': 'armv8.2-a',
> > > >  'march_features': ['crc', 'crypto', 'lse'],
> > > > -'compiler_options': ['-mcpu=octeontx2'],
> > > > +'mcpu': 'octeontx2',
> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"cn9k"'],
> > > >  ['RTE_ARM_FEATURE_ATOMICS', true],
> > > > @@ -176,7 +178,7 @@ implementer_ampere = {
> > > >  '0x0': {
> > > >  'march': 'armv8-a',
> > > >  'march_features': ['crc', 'crypto'],
> > > > -'compiler_options':  ['-mtune=emag'],
> > > > +'mcpu': 'emag',
> > >
> > > We're changing mtune to mcpu, is this equivalent?
> > >
> >
> > Both march and mtune are a subset of mcpu.
> >
> 
> Sure, but we replaced '-mtune=emag' with '-mcpu=emag'. Are these two
> builds going to be different or the same?
> 

Yeah, I believe both are same.

> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"eMAG"'],
> > > >  ['RTE_MAX_LCORE', 32],
> > > > @@ -186,7 +188,7 @@ implementer_ampere = {
> > > >  '0xac3': {
> > > >  'march': 'armv8.6-a',
> > > >  'march_features': ['crc', 'crypto'],
> > > > -'compiler_options':  ['-mcpu=ampere1'],
> > > > +'mcpu': 'ampere1',
> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"AmpereOne"'],
> > > >  ['RTE_MAX_LCORE', 320],
> > > > @@ -206,7 +208,7 @@ implementer_hisilicon = {
> > > >  '0xd01': {
> > > >  'march': 'armv8.2-a',
> > > >  'march_features': ['crypto'],
> > > > -'compiler_options': ['-mtune=tsv110'],
> > > > +'mcpu': 'tsv110',
> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"Kunpeng 920"'],
> > > >   

RE: [EXT] Re: [PATCH 2/2] config/arm: add support for fallback march

[Pavan Nikhilesh Bhagavatula]

> -Original Message-
> From: Juraj Linkeš 
> Sent: Monday, January 22, 2024 9:59 PM
> To: Pavan Nikhilesh Bhagavatula 
> Cc: Jerin Jacob ; ruifeng.w...@arm.com;
> n...@arm.com; Bruce Richardson ;
> dev@dpdk.org
> Subject: Re: [EXT] Re: [PATCH 2/2] config/arm: add support for fallback march
> 
> On Mon, Jan 22, 2024 at 1:16 PM Pavan Nikhilesh Bhagavatula
>  wrote:
> >
> > > On Sun, Jan 21, 2024 at 10:37 AM  wrote:
> > > >
> > > > From: Pavan Nikhilesh 
> > > >
> > > > Some ARM CPUs have specific march requirements and
> > > > are not compatible with the supported march list.
> > > > Add fallback march in case the mcpu and the march
> > > > advertised in the part_number_config are not supported
> > > > by the compiler.
> > > >
> > >
> > > It's not clear to me what this patch adds. We already have a fallback
> > > mechanism and this basically does the same thing, but there's some
> > > extra logic that's not clear to me. Looks like there are some extra
> > > conditions around mcpu. In that case, all of the mcpu/march processing
> > > should be done first and then we should do a common fallback.
> > >
> >
> > The current fallback does a simple reverse compatibility check with the
> compiler
> > when force march is not enabled.
> > But this is not true for neoverse-n2 case, as it is based on armv9-a which 
> > is a
> super set of
> > armv8.5-a and other features[1]
> > In the current fallback path if both march neoverse-n2 and mcpu armv9-a
> are not supported
> > then it would fallback to armv8.6-a but this not correct as neoverse-n2 is
> not based on armv8.5-a
> >
> > The fallback march armv8.5-a kicks in (if supported) when neoverse-n2 and
> armv9-a are not supported.
> >
> 
> Can the two fallback mechanisms be combined? They seem very similar.

I will try to combine them in the next version.

Thanks,
Pavan.

> 
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_gcc-
> 2Dmirror_gcc_blob_615e25c82de97acc17ab438f88d6788cf7ffe1d6_gcc_confi
> g_arm_arm-2Dcpus.in-
> 23L306&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=-
> Xknjo5NapybFKTREn10YXl4HKVFwvwF7ZNL_2ks7_DxKC9Xynna3Ms2DLynVO
> Fh&s=o_Pt0fUjpeoar7QSgqshIXDxOZVUSNQYcCtRJWhNS8I&e=
> >
> >
> > > > Example
> > > > mcpu = neoverse-n2
> > > > march = armv9-a
> > > > fallback_march = armv8.5-a
> > > >
> > > > mcpu, march not supported
> > > > machine_args = ['-march=armv8.5-a']
> > > >
> > > > mcpu, march, fallback_march not supported
> > > > least march supported = armv8-a
> > > >
> > > > machine_args = ['-march=armv8-a']
> > > >
> > > > Signed-off-by: Pavan Nikhilesh 
> > > > ---
> > > >  config/arm/meson.build | 15 +--
> > > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/config/arm/meson.build b/config/arm/meson.build
> > > > index 8c8cfccca0..2aaf78a81a 100644
> > > > --- a/config/arm/meson.build
> > > > +++ b/config/arm/meson.build
> > > > @@ -94,6 +94,7 @@ part_number_config_arm = {
> > > >  '0xd49': {
> > > >  'march': 'armv9-a',
> > > >  'march_features': ['sve2'],
> > > > +'fallback_march': 'armv8.5-a',
> > > >  'mcpu': 'neoverse-n2',
> > > >  'flags': [
> > > >  ['RTE_MACHINE', '"neoverse-n2"'],
> > > > @@ -709,14 +710,14 @@ if update_flags
> > > >
> > > >  # probe supported archs and their features
> > > >  candidate_march = ''
> > > > +supported_marchs = ['armv9-a', 'armv8.6-a', 'armv8.5-a', 
> > > > 'armv8.4-a',
> > > > +'armv8.3-a', 'armv8.2-a', 'armv8.1-a', 
> > > > 'armv8-a']
> > > >  if part_number_config.has_key('march')
> > > >  if part_number_config.get('force_march', false) or support_mcpu
> > > >  if cc.has_argument('-march=' +  
> > > > part_number_config['march'])
> > > >  candidate_march = part_number_config['march']
> > > >  endif
> > > >  else
> > > > -supported_marchs = ['armv8.6-a', 'armv8.5-a', 'armv8.4-a',
> 'armv8.3-
> > > a',
> > > > -'armv8.2-a', 'armv8.1-a', 'armv8-a']
> > > >  check_compiler_support = false
> > > >  foreach supported_march: supported_marchs
> > > >  if supported_march == part_number_config['march']
> > > > @@ -733,6 +734,16 @@ if update_flags
> > > >  endif
> > > >
> > > >  if candidate_march != part_number_config['march']
> > > > +if part_number_config.has_key('fallback_march') and not
> > > support_mcpu
> > > > +fallback_march = part_number_config['fallback_march']
> > > > +foreach supported_march: supported_marchs
> > > > +if (supported_march == fallback_march
> > > > +and cc.has_argument('-march=' + 
> > > > supported_march))
> > > > +candidate_march = supported_march

Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

[Stephen Hemminger]

On Wed, 24 Jan 2024 05:45:11 -0800
Rahul Gupta  wrote:

> +
> +/*
> + * waits until function executing on given lcore finishes.
> + * returns value returned by the function executing on that lcore.
> + */
> +__rte_experimental int
> +rte_eal_init_wait_async_setup_complete(void)
> +{
> + int lcore_id = -1;
> + lcore_id = rte_lcore_id();

Useless initialization.

Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

[Stephen Hemminger]

On Wed, 24 Jan 2024 05:45:11 -0800
Rahul Gupta  wrote:

> + * returns current status of execution on a given lcore
> + */
> +__rte_experimental int
> +rte_eal_init_async_setup_done(int lcore_id)
> +{
> + int ret = (lcore_config[lcore_id].state)

parenthesis not needed here

Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

[David Marchand]

On Wed, Jan 24, 2024 at 2:45 PM Rahul Gupta
 wrote:
>
> From: Rahul Gupta 
>
> In continuation to the following email, I am sending this patch.
> (https://inbox.dpdk.org/dev/20231110172523.ga17...@microsoft.com/)
>
> Initialization requires rte_eal_init + rte_pktmbuf_pool_create which
> can consume a total time of 500-600 ms:
> a) For many devices FLR may take a significant chunk of time
>(200-250 ms in our use-case), this FLR is triggered during device
>probe in rte_eal_init().
> b) rte_pktmbuf_pool_create() can consume up to 300-350 ms for
> applications that require huge memory.
>
> This cost is incurred on each restart (which happens in our use-case
> during binary updates for servicing).
> This patch provides an optimization using pthreads that applications
> can use and which can save 200-230ms.
>
> In this patch, rte_eal_init() is refactored into two parts-
> a) 1st part is dependent code ie- it’s a perquisite of the FLR and
>mempool creation. So this code needs to be executed before any
>pthreads. Its named as rte_eal_init_setup()
> b) 2nd part of code is independent code ie- it can execute in parallel
>to mempool creation in a pthread. Its named as rte_eal_init_async_setup().
>
> In existing applications no changes are required unless they wish to leverage
> the optimization.
>
> If the application wants to leverage this optimization, then it needs to call
> rte_eal_init_async() (instead of call rte_eal_init()), then it can create a
> thread using rte_eal_remote_launch() to schedule a task it would like todo in
> parallel rte_eal_init_async_setup(), this task can be a mbuf pool creation
> using- rte_pktmbuf_pool_create()
>
> After this, if next operations require completion of above task, then
> user can use rte_eal_init_wait_async_setup_complete(),
> or if user wants to just check status of that thread, then use-
> rte_eal_init_async_setup_done()

Looking at what this patch does.. I am under the impression all you
really need is rte_eal_init without initial probing.
Such behavior can probably be achieved with a allowlist set to a non
existing device (like for example "-a :00:00.0"), then later, use
device hotplug.


Some quick note on this patch.

- don't expose symbols externally if they are only for internal use in
the same library,
- current version is 24.03, not 24.01 (wrt comment in version.map),
- other OSes are not handled by this patch, please do the work for
FreeBSD and Windows,
- as a followup of the previous point, please check if we can share
code between OSes and, if so, move the shared code to lib/eal/common,
- did you test this series with multiprocess?
- why should telemetry and other parts of the current rte_eal_init()
be left in the second stage of this initialisation pipeline?


-- 
David Marchand

Re: [24.03 RFC] argparse: add argparse library

[Stephen Hemminger]

On Tue, 21 Nov 2023 12:26:51 +
Chengwen Feng  wrote:

> Introduce argparse library (which was inspired by the thread [1]),
> compared with getopt, the argparse has following advantages:
> 1) Set the help information when defining parameters.
> 2) Support positional parameters.
> 
> The parameters parsing according following:
> 1) positional: use callback to parse (passed the long-name as the key
>for callback).
> 2) optional:
>In addition to callback to parse, but also support:
> 2.1) no-val: support set default value to saver.
> 2.2) has-val: support set value to saver, the value must be conform
>   RTE_ARGPARSE_ARG_VAL_xxx.
> 2.3) opt-val: if current without value then treat as no-val, else could
>   treat as has-val.

How compatiable is this with Python or other implementations of argparse
in C?

[PATCH 0/2] RTE_LOG_DP cleanups

[Stephen Hemminger]

This patch set was suggested by David while reviewing
the RTE_LOGTYPE_PMD patches.

Stephen Hemminger (2):
  drivers: remove unnecessary RTE_LOG_DP macros
  drivers: RTE_LOG_DP newline consistency

 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |  2 +-
 drivers/bus/cdx/cdx_logs.h| 11 -
 drivers/bus/fslmc/fslmc_logs.h| 11 -
 drivers/common/dpaax/dpaax_logs.h | 11 -
 drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h |  2 +-
 drivers/crypto/dpaa_sec/dpaa_sec_log.h|  2 +-
 drivers/event/dlb2/dlb2_log.h |  2 +-
 drivers/event/dpaa2/dpaa2_eventdev_logs.h | 11 -
 drivers/event/dsw/dsw_evdev.h |  2 +-
 drivers/event/dsw/dsw_event.c | 40 -
 drivers/mempool/dpaa/dpaa_mempool.c   |  2 +-
 drivers/mempool/dpaa/dpaa_mempool.h   |  2 +-
 drivers/mempool/dpaa2/dpaa2_hw_mempool.c  |  6 +--
 drivers/mempool/dpaa2/dpaa2_hw_mempool_logs.h |  2 +-
 drivers/net/dpaa/dpaa_ethdev.h|  2 +-
 drivers/net/dpaa2/dpaa2_pmd_logs.h|  2 +-
 drivers/net/dpaa2/dpaa2_rxtx.c| 44 +--
 drivers/net/enetc/enetc_logs.h|  2 +-
 drivers/net/enetc/enetc_rxtx.c|  2 +-
 drivers/net/enetfec/enet_pmd_logs.h   |  2 +-
 drivers/net/pfe/pfe_logs.h|  2 +-
 21 files changed, 59 insertions(+), 103 deletions(-)

-- 
2.43.0

[PATCH 1/2] drivers: remove unnecessary RTE_LOG_DP macros

[Stephen Hemminger]

Several drivers did copy/paste of log macros for datapath
but are not using them, so remove them.

Signed-off-by: Stephen Hemminger 
---
 drivers/bus/cdx/cdx_logs.h| 11 ---
 drivers/bus/fslmc/fslmc_logs.h| 11 ---
 drivers/common/dpaax/dpaax_logs.h | 11 ---
 drivers/event/dpaa2/dpaa2_eventdev_logs.h | 11 ---
 4 files changed, 44 deletions(-)

diff --git a/drivers/bus/cdx/cdx_logs.h b/drivers/bus/cdx/cdx_logs.h
index a1046ce544a6..0ec39e9dd489 100644
--- a/drivers/bus/cdx/cdx_logs.h
+++ b/drivers/bus/cdx/cdx_logs.h
@@ -23,15 +23,4 @@ extern int cdx_logtype_bus;
 #define CDX_BUS_WARN(fmt, args...) \
CDX_BUS_LOG(WARNING, fmt, ## args)
 
-/* DP Logs, toggled out at compile time if level lower than current level */
-#define CDX_BUS_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
-
-#define CDX_BUS_DP_DEBUG(fmt, args...) \
-   CDX_BUS_DP_LOG(DEBUG, fmt, ## args)
-#define CDX_BUS_DP_INFO(fmt, args...) \
-   CDX_BUS_DP_LOG(INFO, fmt, ## args)
-#define CDX_BUS_DP_WARN(fmt, args...) \
-   CDX_BUS_DP_LOG(WARNING, fmt, ## args)
-
 #endif /* CDX_LOGS_H */
diff --git a/drivers/bus/fslmc/fslmc_logs.h b/drivers/bus/fslmc/fslmc_logs.h
index a1e14dd84e9a..e15c603426b2 100644
--- a/drivers/bus/fslmc/fslmc_logs.h
+++ b/drivers/bus/fslmc/fslmc_logs.h
@@ -25,15 +25,4 @@ extern int dpaa2_logtype_bus;
 #define DPAA2_BUS_WARN(fmt, args...) \
DPAA2_BUS_LOG(WARNING, fmt, ## args)
 
-/* DP Logs, toggled out at compile time if level lower than current level */
-#define DPAA2_BUS_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
-
-#define DPAA2_BUS_DP_DEBUG(fmt, args...) \
-   DPAA2_BUS_DP_LOG(DEBUG, fmt, ## args)
-#define DPAA2_BUS_DP_INFO(fmt, args...) \
-   DPAA2_BUS_DP_LOG(INFO, fmt, ## args)
-#define DPAA2_BUS_DP_WARN(fmt, args...) \
-   DPAA2_BUS_DP_LOG(WARNING, fmt, ## args)
-
 #endif /* _FSLMC_LOGS_H_ */
diff --git a/drivers/common/dpaax/dpaax_logs.h 
b/drivers/common/dpaax/dpaax_logs.h
index 180476f6757c..f667aaff72fd 100644
--- a/drivers/common/dpaax/dpaax_logs.h
+++ b/drivers/common/dpaax/dpaax_logs.h
@@ -35,15 +35,4 @@ extern int dpaax_logger;
 #define DPAAX_WARN(fmt, args...) \
DPAAX_LOG(WARNING, fmt, ## args)
 
-/* DP Logs, toggled out at compile time if level lower than current level */
-#define DPAAX_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
-
-#define DPAAX_DP_DEBUG(fmt, args...) \
-   DPAAX_DP_LOG(DEBUG, fmt, ## args)
-#define DPAAX_DP_INFO(fmt, args...) \
-   DPAAX_DP_LOG(INFO, fmt, ## args)
-#define DPAAX_DP_WARN(fmt, args...) \
-   DPAAX_DP_LOG(WARNING, fmt, ## args)
-
 #endif /* _DPAAX_LOGS_H_ */
diff --git a/drivers/event/dpaa2/dpaa2_eventdev_logs.h 
b/drivers/event/dpaa2/dpaa2_eventdev_logs.h
index 66c8c772740d..b894fb32996a 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev_logs.h
+++ b/drivers/event/dpaa2/dpaa2_eventdev_logs.h
@@ -24,17 +24,6 @@ extern int dpaa2_logtype_event;
 #define DPAA2_EVENTDEV_WARN(fmt, args...) \
DPAA2_EVENTDEV_LOG(WARNING, fmt, ## args)
 
-/* DP Logs, toggled out at compile time if level lower than current level */
-#define DPAA2_EVENTDEV_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
-
-#define DPAA2_EVENTDEV_DP_DEBUG(fmt, args...) \
-   DPAA2_EVENTDEV_DP_LOG(DEBUG, fmt, ## args)
-#define DPAA2_EVENTDEV_DP_INFO(fmt, args...) \
-   DPAA2_EVENTDEV_DP_LOG(INFO, fmt, ## args)
-#define DPAA2_EVENTDEV_DP_WARN(fmt, args...) \
-   DPAA2_EVENTDEV_DP_LOG(WARNING, fmt, ## args)
-
 #define dpaa2_evdev_info(fmt, ...) DPAA2_EVENTDEV_LOG(INFO, fmt, ##__VA_ARGS__)
 #define dpaa2_evdev_dbg(fmt, ...) DPAA2_EVENTDEV_LOG(DEBUG, fmt, ##__VA_ARGS__)
 #define dpaa2_evdev_err(fmt, ...) DPAA2_EVENTDEV_LOG(ERR, fmt, ##__VA_ARGS__)
-- 
2.43.0

[PATCH 2/2] drivers: RTE_LOG_DP newline consistency

[Stephen Hemminger]

Make sure use of RTE_LOG_DP has newline just like uses of RTE_LOG.

Signed-off-by: Stephen Hemminger 
---
 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |  2 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h |  2 +-
 drivers/crypto/dpaa_sec/dpaa_sec_log.h|  2 +-
 drivers/event/dlb2/dlb2_log.h |  2 +-
 drivers/event/dsw/dsw_evdev.h |  2 +-
 drivers/event/dsw/dsw_event.c | 40 -
 drivers/mempool/dpaa/dpaa_mempool.c   |  2 +-
 drivers/mempool/dpaa/dpaa_mempool.h   |  2 +-
 drivers/mempool/dpaa2/dpaa2_hw_mempool.c  |  6 +--
 drivers/mempool/dpaa2/dpaa2_hw_mempool_logs.h |  2 +-
 drivers/net/dpaa/dpaa_ethdev.h|  2 +-
 drivers/net/dpaa2/dpaa2_pmd_logs.h|  2 +-
 drivers/net/dpaa2/dpaa2_rxtx.c| 44 +--
 drivers/net/enetc/enetc_logs.h|  2 +-
 drivers/net/enetc/enetc_rxtx.c|  2 +-
 drivers/net/enetfec/enet_pmd_logs.h   |  2 +-
 drivers/net/pfe/pfe_logs.h|  2 +-
 17 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h 
b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
index 452435ccb942..bddf4e6cd2f4 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
+++ b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
@@ -23,6 +23,6 @@ extern int bbdev_la12xx_logtype;
 
 /* 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)
+   RTE_LOG_DP(level, PMD, fmt "\n", ## args)
 
 #endif /* _BBDEV_LA12XX_PMD_LOGS_H_ */
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h 
b/drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h
index c2e11f9516f9..b1c24fd1c325 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h
@@ -29,7 +29,7 @@ extern int dpaa2_logtype_sec;
 
 /* DP Logs, toggled out at compile time if level lower than current level */
 #define DPAA2_SEC_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
+   RTE_LOG_DP(level, PMD, fmt "\n", ## args)
 
 #define DPAA2_SEC_DP_DEBUG(fmt, args...) \
DPAA2_SEC_DP_LOG(DEBUG, fmt, ## args)
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec_log.h 
b/drivers/crypto/dpaa_sec/dpaa_sec_log.h
index fb895a8bc67f..d298ac5b5755 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec_log.h
+++ b/drivers/crypto/dpaa_sec/dpaa_sec_log.h
@@ -29,7 +29,7 @@ extern int dpaa_logtype_sec;
 
 /* DP Logs, toggled out at compile time if level lower than current level */
 #define DPAA_SEC_DP_LOG(level, fmt, args...) \
-   RTE_LOG_DP(level, PMD, fmt, ## args)
+   RTE_LOG_DP(level, PMD, fmt "\n", ## args)
 
 #define DPAA_SEC_DP_DEBUG(fmt, args...) \
DPAA_SEC_DP_LOG(DEBUG, fmt, ## args)
diff --git a/drivers/event/dlb2/dlb2_log.h b/drivers/event/dlb2/dlb2_log.h
index dc1481ef870c..1582f8bdf7bd 100644
--- a/drivers/event/dlb2/dlb2_log.h
+++ b/drivers/event/dlb2/dlb2_log.h
@@ -20,6 +20,6 @@ extern int eventdev_dlb2_log_level;
 
 /* remove debug logs at compile time unless actually debugging */
 #define DLB2_LOG_DBG(fmt, args...) \
-   RTE_LOG_DP(DEBUG, PMD, fmt, ## args)
+   RTE_LOG_DP(DEBUG, PMD, fmt "\n", ## args)
 
 #endif /* _DLB2_EVDEV_LOG_H_ */
diff --git a/drivers/event/dsw/dsw_evdev.h b/drivers/event/dsw/dsw_evdev.h
index 6416a8a898d6..f6fc402f6d29 100644
--- a/drivers/event/dsw/dsw_evdev.h
+++ b/drivers/event/dsw/dsw_evdev.h
@@ -297,7 +297,7 @@ dsw_pmd_priv(const struct rte_eventdev *eventdev)
 }
 
 #define DSW_LOG_DP(level, fmt, args...)
\
-   RTE_LOG_DP(level, EVENTDEV, "[%s] %s() line %u: " fmt,  \
+   RTE_LOG_DP(level, EVENTDEV, "[%s] %s() line %u: " fmt "\n", \
   DSW_PMD_NAME,\
   __func__, __LINE__, ## args)
 
diff --git a/drivers/event/dsw/dsw_event.c b/drivers/event/dsw/dsw_event.c
index 93bbeead2efe..6dc6b45d92ab 100644
--- a/drivers/event/dsw/dsw_event.c
+++ b/drivers/event/dsw/dsw_event.c
@@ -55,7 +55,7 @@ dsw_port_acquire_credits(struct dsw_evdev *dsw, struct 
dsw_port *port,
return false;
}
 
-   DSW_LOG_DP_PORT(DEBUG, port->id, "Acquired %d tokens from pool.\n",
+   DSW_LOG_DP_PORT(DEBUG, port->id, "Acquired %d tokens from pool.",
acquired_credits);
 
port->inflight_credits += acquired_credits;
@@ -81,7 +81,7 @@ dsw_port_return_credits(struct dsw_evdev *dsw, struct 
dsw_port *port,
   __ATOMIC_RELAXED);
 
DSW_LOG_DP_PORT(DEBUG, port->id,
-   "Returned %d tokens to pool.\n",
+   "Returned %d tokens to pool.",
return_credits);
}
 }
@@ -257,7 +257,7 @@ dsw_port_add_paused_flows(struct dsw_port *po

Testing scatter support for PMDs using testpmd

[Jeremy Spewock]

Hello maintainers,

In porting over the first ethdev suite to the new DTS framework, there was
an inconsistency that we found and we were wondering if anyone would be
able to shed some light on this. In general the inconsistency pertains to
Intel and Mellanox NICs, where one will throw an error and not start
testpmd while the other will work as expected.

In the original DTS suite for testing scattered packets, testpmd is started
with the flags --max-packet-len=9000 and --mbuf-size=2048. This starts and
works fine on Intel NICs, but when you use the same flags on a Mellanox
NIC, it will produce the error seen below. There is a flag that exists for
testpmd called --enable-scatter and when this flag is provided, the
Mellanox NIC seems to accept the flags and start without error.

Our assumption is that this should be consistent between NICs, is there a
reason that one NIC would allow for starting testpmd without explicitly
enabling scatter and the other wouldn't? Should this flag always be
present, and is it an error that testpmd can start without it in the first
place?

Here is the error provided when attempting to run on a Mellanox NIC:

mlx5_net: port 0 Rx queue 0: Scatter offload is not configured and no
enough mbuf space(2048) to contain the maximum RX packet length(9000) with
head-room(128)
mlx5_net: port 0 unable to allocate rx queue index 0
Fail to configure port 0 rx queues
Start ports failed

Thank you for any insight,
Jeremy

RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW

[Kusztal, ArkadiuszX]

> -Original Message-
> From: Gowrishankar Muthukrishnan 
> Sent: Thursday, January 4, 2024 2:38 PM
> To: Kusztal, ArkadiuszX 
> Cc: Akhil Goyal ; Ji, Kai ; Power, Ciara
> ; Anoob Joseph ;
> dev@dpdk.org
> Subject: RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and
> encryption for HW
> 
> Hi,
> 
> > This commit adds comments for the proposal of addition of SM2
> > algorithm key exchange and encryption/decryption operation.
> >
> > Signed-off-by: Arkadiusz Kusztal 
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 39d3da3952..6911a14dbd 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -639,6 +639,10 @@ struct rte_crypto_asym_xform {  struct
> > rte_crypto_sm2_op_param {
> > enum rte_crypto_asym_op_type op_type;
> > /**< Signature generation or verification. */
> > +   /*
> > +* For key exchange operation, new struct should be created.
> > +* Doing that, the current struct could be split into signature and
> > encryption.
> > +*/
> >
> > enum rte_crypto_auth_algorithm hash;
> > /**< Hash algorithm used in EC op. */ @@ -672,6 +676,18 @@ struct
> > rte_crypto_sm2_op_param {
> >  * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> >  * be overwritten by the PMD with the encrypted length.
> >  */
> > +   /* SM2 encryption algorithm relies on certain cryptographic functions,
> > +* that HW devices not necesseraly need to implement.
> > +* When C1 is a elliptic curve point, C2 and C3 need additional
> > +* operation like KDF and Hash. The question here is: should only
> > +* elliptic curve output parameters (namely C1 and PB) be returned
> > +to
> > the user,
> > +* or should encryption be, in this case, computed within the PMD using
> > +* software methods, or should both option be available?
> > +*/
> 
> I second on splitting this struct for PKE (may be _pke and _dsa).
> 
> At the same time, handling these structs should be followed by some capability
> check and that was what I have been thinking on to propose as asym OP
> capability in this release.
> Right now, asymmetric capability is defined only by xform (not also by op).
> But we could add op capab also as below.
> 
> struct rte_cryptodev_capabilities caps_sm2[] = {
>   .op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
>   {
>   .asym = {
>   .xform_capa = {
>   .xform_type =
> RTE_CRYPTO_ASYM_XFORM_SM2,
>   .op_types = ...
>   },
>   .op_capa = [
>   {
>   .op_type =
> RTE_CRYPTO_ASYM_OP_ENC,
>   .capa = (1 <<
> RTE_CRYPTO_ASYM_SM2_PKE_KDF | 1 <<
> RTE_CRYPTO_ASYM_SM2_PKE_HASH)   NEW ENUM 
>   }
>   ]
>   }
>   }
> }
> 
> Doing this, hash_algos member in asym xform capability today can eventually be
> removed And it sounds better for an op. Also, this op capability check could 
> be
> done once for the session.
> If you are also aligned, I can send an RFC for capab check.

Yes, please send.
Additionally, on top of it, we need to add several fields to the sm2.
We have never had this problem, as most of the algorithms are self-sufficient, 
which is not a case for smX, as well as EdDSA for example. 
So for certain HW cases:
For encryption and decryption, there should be C1 as an input or output.
For key exchange, there should be (xU/V,yU/V) as an output.

> 
> > +   /* Similar applies to the key exchange in the HW. The second phase
> > +of
> > KE, most likely,
> > +* will go as far as to obtain xU,yU(xV,xV), where SW can easily
> > calculate SA.
> 
> What does SA mean here ? Signature algorithm ??.
> 
> Thanks,
> Gowrishankar
> 
> > +* Should then both options be available?
> > +*/
> >
> > rte_crypto_uint id;
> > /**< The SM2 id used by signer and verifier. */
> > --
> > 2.13.6

Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

[Tyler Retzlaff]

On Wed, Jan 24, 2024 at 05:45:11AM -0800, Rahul Gupta wrote:
> From: Rahul Gupta 
> 
> In continuation to the following email, I am sending this patch.
> (https://inbox.dpdk.org/dev/20231110172523.ga17...@microsoft.com/)
> 
> Initialization requires rte_eal_init + rte_pktmbuf_pool_create which
> can consume a total time of 500-600 ms:
> a) For many devices FLR may take a significant chunk of time
>(200-250 ms in our use-case), this FLR is triggered during device
>probe in rte_eal_init().
> b) rte_pktmbuf_pool_create() can consume up to 300-350 ms for
> applications that require huge memory.
> 
> This cost is incurred on each restart (which happens in our use-case
> during binary updates for servicing).
> This patch provides an optimization using pthreads that applications
> can use and which can save 200-230ms.
> 
> In this patch, rte_eal_init() is refactored into two parts-
> a) 1st part is dependent code ie- it’s a perquisite of the FLR and
>mempool creation. So this code needs to be executed before any
>pthreads. Its named as rte_eal_init_setup()
> b) 2nd part of code is independent code ie- it can execute in parallel
>to mempool creation in a pthread. Its named as rte_eal_init_async_setup().
> 
> In existing applications no changes are required unless they wish to leverage
> the optimization.
> 
> If the application wants to leverage this optimization, then it needs to call
> rte_eal_init_async() (instead of call rte_eal_init()), then it can create a
> thread using rte_eal_remote_launch() to schedule a task it would like todo in
> parallel rte_eal_init_async_setup(), this task can be a mbuf pool creation
> using- rte_pktmbuf_pool_create()
> 
> After this, if next operations require completion of above task, then
> user can use rte_eal_init_wait_async_setup_complete(),
> or if user wants to just check status of that thread, then use-
> rte_eal_init_async_setup_done()
> 
> ---
> v2: Address Stephen Hemminger's comment
> ---
> v3: address support for single lcore
> ---
> v4: address Brue Richardson and Stephen Hemminger comment
> Existing application need not do any changes if bootup optimization is not 
> needed.
> 
>  app/test-pmd/testpmd.c|  24 -
>  lib/eal/include/rte_eal.h | 107 ++
>  lib/eal/linux/eal.c   |  62 --
>  lib/eal/version.map   |   7 +++
>  4 files changed, 196 insertions(+), 4 deletions(-)

NAK

changes to EAL need to cover all support OS/platforms, EAL is not
Linux-only library.

[PATCH] doc/linux_gsg: add amd configuration section

[Vipin Varghese]

Add AMD EPYC SoC tuning guide as new setcion of linux getting
started guide.

Signed-off-by: Vipin Varghese 
---
 MAINTAINERS   |  4 ++
 doc/guides/linux_gsg/amd_platform.rst | 70 +++
 doc/guides/linux_gsg/index.rst|  1 +
 3 files changed, 75 insertions(+)
 create mode 100644 doc/guides/linux_gsg/amd_platform.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..e7122f1a85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -275,6 +275,10 @@ F: lib/eal/include/rte_random.h
 F: lib/eal/common/rte_random.c
 F: app/test/test_rand_perf.c
 
+AMD x86
+M: Vipin Varghese 
+F: doc/guides/linux_gsg/amd_platform.rst
+
 ARM v7
 M: Ruifeng Wang 
 F: config/arm/
diff --git a/doc/guides/linux_gsg/amd_platform.rst 
b/doc/guides/linux_gsg/amd_platform.rst
new file mode 100644
index 00..237f84785a
--- /dev/null
+++ b/doc/guides/linux_gsg/amd_platform.rst
@@ -0,0 +1,70 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+How to get best performance on AMD platform
+===
+
+This document provides a detailed, step-by-step guide on configuring AMD EPYC
+System-on-Chip (SoC) for optimal performance in DPDK applications across 
different
+SoC families.
+
+The overall performance is influenced by factors such as BIOS settings, NUMA 
Per
+Socket configuration, Memory per NUMA allocation, and proximity to IO devices.
+
+These are covered in various sections of tuning guides shared below.
+
+
+Tuning Guide for AMD EPYC SoC
+-
+
+#. `MILAN 
`_
+
+#. `GENOA 
`_
+
+#. `BERGAMO|SIENNA 
`_
+
+
+General Requirements
+
+
+Memory
+~~
+
+Refer to the 'Memory Configuration' section for specific details related to 
the System-on-Chip (SoC).
+
+.. Note::
+
+   As a general guideline, it is recommended to populate at least one memory 
DIMM in each memory channel.
+   The optimal memory size for each DIMM is at least 8, 16, or 32 GB, 
utilizing ECC modules.
+
+
+BIOS
+
+
+Refer to the `BIOS Performance` section in tuning guide for recommended 
settings.
+
+
+Linux Grub
+--
+
+Refer to the `Linux OS & Kernel` in tuning guide for recommended settings.
+
+
+NIC and Accelerator
+---
+
+AMD EPYC supports PCIe Generation of 1|2|3|4|5 depending upon SoC families.
+For best performance ensure the right slots are used which provides adequate 
bandwidth.
+
+Use ``lspci`` to check the speed of a PCI slot ::
+
+  lspci -s 41:00.0 -vv | grep LnkSta
+
+  LnkSta: Speed 16GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- ...
+  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ ...
+
+
+Compiler
+
+
+Refer to the `Compiler Flags` in tuning guide for recommended version and 
`-march` flags.
diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
index c3e67bf9ec..ecdaf35eec 100644
--- a/doc/guides/linux_gsg/index.rst
+++ b/doc/guides/linux_gsg/index.rst
@@ -21,3 +21,4 @@ Getting Started Guide for Linux
 linux_eal_parameters
 enable_func
 nic_perf_intel_platform
+amd_platform
-- 
2.39.3

Re: [PATCH 1/2] drivers: remove unnecessary RTE_LOG_DP macros

[Tyler Retzlaff]

On Wed, Jan 24, 2024 at 08:28:34AM -0800, Stephen Hemminger wrote:
> Several drivers did copy/paste of log macros for datapath
> but are not using them, so remove them.
> 
> Signed-off-by: Stephen Hemminger 
> ---

Acked-by: Tyler Retzlaff 

[PATCH] doc/linux_gsg: add amd configuration section

[Vipin Varghese]

Add AMD EPYC SoC tuning guide as new section of linux getting
started guide.

Signed-off-by: Vipin Varghese 
---
 MAINTAINERS   |  4 ++
 doc/guides/linux_gsg/amd_platform.rst | 70 +++
 doc/guides/linux_gsg/index.rst|  1 +
 3 files changed, 75 insertions(+)
 create mode 100644 doc/guides/linux_gsg/amd_platform.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..e7122f1a85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -275,6 +275,10 @@ F: lib/eal/include/rte_random.h
 F: lib/eal/common/rte_random.c
 F: app/test/test_rand_perf.c
 
+AMD x86
+M: Vipin Varghese 
+F: doc/guides/linux_gsg/amd_platform.rst
+
 ARM v7
 M: Ruifeng Wang 
 F: config/arm/
diff --git a/doc/guides/linux_gsg/amd_platform.rst 
b/doc/guides/linux_gsg/amd_platform.rst
new file mode 100644
index 00..237f84785a
--- /dev/null
+++ b/doc/guides/linux_gsg/amd_platform.rst
@@ -0,0 +1,70 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+How to get best performance on AMD platform
+===
+
+This document provides a detailed, step-by-step guide on configuring AMD EPYC
+System-on-Chip (SoC) for optimal performance in DPDK applications across 
different
+SoC families.
+
+The overall performance is influenced by factors such as BIOS settings, NUMA 
Per
+Socket configuration, Memory per NUMA allocation, and proximity to IO devices.
+
+These are covered in various sections of tuning guides shared below.
+
+
+Tuning Guide for AMD EPYC SoC
+-
+
+#. `MILAN 
`_
+
+#. `GENOA 
`_
+
+#. `BERGAMO|SIENNA 
`_
+
+
+General Requirements
+
+
+Memory
+~~
+
+Refer to the 'Memory Configuration' section for specific details related to 
the System-on-Chip (SoC).
+
+.. Note::
+
+   As a general guideline, it is recommended to populate at least one memory 
DIMM in each memory channel.
+   The optimal memory size for each DIMM is at least 8, 16, or 32 GB, 
utilizing ECC modules.
+
+
+BIOS
+
+
+Refer to the `BIOS Performance` section in tuning guide for recommended 
settings.
+
+
+Linux Grub
+--
+
+Refer to the `Linux OS & Kernel` in tuning guide for recommended settings.
+
+
+NIC and Accelerator
+---
+
+AMD EPYC supports PCIe Generation of 1|2|3|4|5 depending upon SoC families.
+For best performance ensure the right slots are used which provides adequate 
bandwidth.
+
+Use ``lspci`` to check the speed of a PCI slot ::
+
+  lspci -s 41:00.0 -vv | grep LnkSta
+
+  LnkSta: Speed 16GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- ...
+  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ ...
+
+
+Compiler
+
+
+Refer to the `Compiler Flags` in tuning guide for recommended version and 
`-march` flags.
diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
index c3e67bf9ec..ecdaf35eec 100644
--- a/doc/guides/linux_gsg/index.rst
+++ b/doc/guides/linux_gsg/index.rst
@@ -21,3 +21,4 @@ Getting Started Guide for Linux
 linux_eal_parameters
 enable_func
 nic_perf_intel_platform
+amd_platform
-- 
2.39.3

Re: [RFC] doc/linux_gsg: add amd configuration section

[Varghese, Vipin]

On 1/16/2024 8:44 PM, Thomas Monjalon wrote:

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


There was no comment on this doc.
It is RFC, is it ready to merge?


new patch shared doc/linux_gsg: add amd configuration section - 
Patchwork (dpdk.org) 






Instead of the Linux guide, should we add it to the platform guides?
 doc/guides/platform/

We may want to create an entry in MAINTAINERS as well.


thank you, added the same under `AMD x86`



More details below.


10/10/2023 17:34, Vipin Varghese:

Add AMD EPYC SoC tuning guide as new setcion of linux getting

typo: section

fixed, spell check did not catch this for me. My mistake

started guide.

Signed-off-by: Vipin Varghese
---
+This document shares step-by-step guide for configuring AMD EPYC SoC across 
various families for getting best performance for DPDK applications.
+Various factors like BIOS, Numa Per Socket, Memory per Numa, near-far from IO 
device affects the overall performance.

Numa -> NUMA

changed to all capital

+
+These are covered in various sections of tuning guides shared below.
+
+
+Tuning Guide for AMD EPYC SoC
+-
+
+#. 
`MILAN`_
+
+#. 
`GENOA`_
+
+#. 
`BERGAMO|SIENNA`_
+
+
+General Requirements
+
+
+Memory
+~~
+
+Refer `Memory Configuration` section for SoC specific details.
+
+Note: general thumb rule is to ensure that each memory channel has at least 
one memory DIMM populated. The ideal memory size for each is at least 8|16|32 
GB ECC modules.

Please start a new sentence on a new line.

correction applied.

Re: [PATCH 2/2] drivers: RTE_LOG_DP newline consistency

[Tyler Retzlaff]

On Wed, Jan 24, 2024 at 08:28:35AM -0800, Stephen Hemminger wrote:
> Make sure use of RTE_LOG_DP has newline just like uses of RTE_LOG.
> 
> Signed-off-by: Stephen Hemminger 
> ---

Acked-by: Tyler Retzlaff 

[PATCH v2 1/8] pipeline: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.0 20231102 (experimental)

[2]
 Compiling C object .../pipeline_rte_swx_pipeline_spec.c.o
.../rte_swx_pipeline_spec.c: In function ‘pipeline_spec_parse’:
../lib/pipeline/rte_swx_pipeline_spec.c:2893:11:
  warning: allocation of insufficient size ‘1’ for type
   ‘struct pipeline_spec’ with size ‘144’ [-Walloc-size]
 2893 | s = calloc(sizeof(struct pipeline_spec), 1);
  |   ^

.../rte_swx_pipeline_spec.c: In function ‘pipeline_iospec_parse’:
../lib/pipeline/rte_swx_pipeline_spec.c:4244:11:
  warning: allocation of insufficient size ‘1’ for type
   ‘struct pipeline_iospec’ with size ‘64’ [-Walloc-size]
 4244 | s = calloc(sizeof(struct pipeline_iospec), 1);
  |   ^

Fixes: 30c4abb90942 ("pipeline: rework specification file-based pipeline build")
Fixes: 54cae37ef4ef ("pipeline: support I/O specification")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
Acked-by: Cristian Dumitrescu 
---
Cc: cristian.dumitre...@intel.com
---
 lib/pipeline/rte_swx_pipeline_spec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/pipeline/rte_swx_pipeline_spec.c 
b/lib/pipeline/rte_swx_pipeline_spec.c
index 2bba0d0524d0..17419e7b854b 100644
--- a/lib/pipeline/rte_swx_pipeline_spec.c
+++ b/lib/pipeline/rte_swx_pipeline_spec.c
@@ -2890,7 +2890,7 @@ pipeline_spec_parse(FILE *spec,
}
 
/* Memory allocation. */
-   s = calloc(sizeof(struct pipeline_spec), 1);
+   s = calloc(1, sizeof(struct pipeline_spec));
if (!s) {
if (err_line)
*err_line = n_lines;
@@ -4241,7 +4241,7 @@ pipeline_iospec_parse(FILE *spec,
}
 
/* Memory allocation. */
-   s = calloc(sizeof(struct pipeline_iospec), 1);
+   s = calloc(1, sizeof(struct pipeline_iospec));
if (!s) {
if (err_line)
*err_line = n_lines;
-- 
2.34.1

[PATCH v2 2/8] net/nfp: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.0 20231102 (experimental)

[2]
Compiling C object .../net_nfp_nfpcore_nfp_mutex.c.o
.../net/nfp/nfpcore/nfp_mutex.c: In function ‘nfp_cpp_mutex_alloc’:
../drivers/net/nfp/nfpcore/nfp_mutex.c:171:15:
  warning: allocation of insufficient size ‘1’ for type
   ‘struct nfp_cpp_mutex’ with size ‘48’ [-Walloc-size]
  171 | mutex = calloc(sizeof(*mutex), 1);
  |   ^

Fixes: c7e9729da6b5 ("net/nfp: support CPP")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
Acked-by: Chaoyong He 
---
Cc: alejandro.luc...@netronome.com
---
 drivers/net/nfp/nfpcore/nfp_mutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/nfp/nfpcore/nfp_mutex.c 
b/drivers/net/nfp/nfpcore/nfp_mutex.c
index 3c10c7a090c0..edb78dfdc917 100644
--- a/drivers/net/nfp/nfpcore/nfp_mutex.c
+++ b/drivers/net/nfp/nfpcore/nfp_mutex.c
@@ -168,7 +168,7 @@ nfp_cpp_mutex_alloc(struct nfp_cpp *cpp,
if (tmp != key)
return NULL;
 
-   mutex = calloc(sizeof(*mutex), 1);
+   mutex = calloc(1, sizeof(*mutex));
if (mutex == NULL)
return NULL;
 
-- 
2.34.1

[PATCH v2 4/8] eventdev: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.1 20240124 (experimental)

[2]
Compiling C object lib/librte_eventdev.a.p/eventdev_rte_eventdev.c.o
../lib/eventdev/rte_eventdev.c: In function ‘handle_dev_dump’:
../lib/eventdev/rte_eventdev.c:2005:29:
  warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
  argument and not in the later argument [-Wcalloc-transposed-args]
 2005 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
  | ^~~~

Fixes: a3b7b476d723 ("eventdev: support telemetry dump eventdev")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: fengcheng...@huawei.com
---
 lib/eventdev/rte_eventdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 157752868d5b..1c865e993fec 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -2002,7 +2002,7 @@ handle_dev_dump(const char *cmd __rte_unused,
 
RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
 
-   buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
+   buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
if (buf == NULL)
return -ENOMEM;
 
-- 
2.34.1

[PATCH v2 5/8] dmadev: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.1 20240124 (experimental)

[2]
Compiling C object lib/librte_dmadev.a.p/dmadev_rte_dmadev.c.o
../lib/dmadev/rte_dmadev.c: In function ‘dmadev_handle_dev_dump’:
../lib/dmadev/rte_dmadev.c:1033:29:
  warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
  argument and not in the later argument [-Wcalloc-transposed-args]
 1033 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
  | ^~~~

Fixes: 94043b04212a ("dmadev: support telemetry dump dmadev")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: fengcheng...@huawei.com
---
 lib/dmadev/rte_dmadev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 5953a77bd6f9..c4e909270058 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -1030,7 +1030,7 @@ dmadev_handle_dev_dump(const char *cmd __rte_unused,
if (*end_param != '\0')
RTE_DMA_LOG(WARNING, "Extra parameters passed to dmadev 
telemetry command, ignoring");
 
-   buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
+   buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
if (buf == NULL)
return -ENOMEM;
 
-- 
2.34.1

[PATCH v2 3/8] rawdev: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.0 20240108 (experimental)

[2]
Compiling C object .../lib/librte_rawdev.a.p/rawdev_rte_rawdev.c.o
../lib/rawdev/rte_rawdev.c: In function ‘handle_dev_dump’:
../lib/rawdev/rte_rawdev.c:659:29:
  error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
  argument and not in the later argument
  [-Werror=calloc-transposed-args]
  659 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
  | ^~~~

Fixes: e915d404eb72 ("rawdev: support telemetry dump rawdev")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: fengcheng...@huawei.com
---
 lib/rawdev/rte_rawdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/rawdev/rte_rawdev.c b/lib/rawdev/rte_rawdev.c
index 474bdc95407f..4f8897b63947 100644
--- a/lib/rawdev/rte_rawdev.c
+++ b/lib/rawdev/rte_rawdev.c
@@ -656,7 +656,7 @@ handle_dev_dump(const char *cmd __rte_unused,
if (!rte_rawdev_pmd_is_valid_dev(dev_id))
return -EINVAL;
 
-   buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
+   buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
if (buf == NULL)
return -ENOMEM;
 
-- 
2.34.1

[PATCH v2 6/8] common/mlx5: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about calloc usage, because calloc
parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.1 20240124 (experimental)

[2]
Compiling C object .../common_mlx5_mlx5_common_mr.c.o
.../mlx5/mlx5_common_mr.c: In function ‘mlx5_mempool_get_chunks’:
.../common/mlx5/mlx5_common_mr.c:1384:29:
  warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
  argument and not in the later argument [-Wcalloc-transposed-args]
 1384 | *out = calloc(sizeof(**out), n);
  | ^

Fixes: 7297d2cdecce ("common/mlx5: fix external memory pool registration")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: dkozl...@nvidia.com
---
 drivers/common/mlx5/mlx5_common_mr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/mlx5/mlx5_common_mr.c 
b/drivers/common/mlx5/mlx5_common_mr.c
index 40ff9153bd8e..85ec10d2ee36 100644
--- a/drivers/common/mlx5/mlx5_common_mr.c
+++ b/drivers/common/mlx5/mlx5_common_mr.c
@@ -1381,7 +1381,7 @@ mlx5_mempool_get_chunks(struct rte_mempool *mp, struct 
mlx5_range **out,
 
DRV_LOG(DEBUG, "Collecting chunks of regular mempool %s", mp->name);
n = mp->nb_mem_chunks;
-   *out = calloc(sizeof(**out), n);
+   *out = calloc(n, sizeof(**out));
if (*out == NULL)
return -1;
rte_mempool_mem_iter(mp, mlx5_range_from_mempool_chunk, *out);
-- 
2.34.1

[PATCH v2 7/8] net/bnx2x: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about rte_calloc usage, because
rte_calloc parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.1 20240124 (experimental)

[2]
Compiling C object drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x.c.o
../drivers/net/bnx2x/bnx2x.c: In function ‘bnx2x_alloc_ilt_lines_mem’:
../drivers/net/bnx2x/bnx2x.c:2392:44:
 warning: ‘rte_calloc’ sizes specified with ‘sizeof’ in the earlier
 argument and not in the later argument [-Wcalloc-transposed-args]
 2392 | sizeof(struct ilt_line), ILT_MAX_LINES,
  |^~

Fixes: 540a211084a7 ("bnx2x: driver core")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: step...@networkplumber.org
---
 drivers/net/bnx2x/bnx2x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index c3283c94f38f..597ee4335977 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2389,7 +2389,7 @@ int bnx2x_alloc_ilt_mem(struct bnx2x_softc *sc)
 static int bnx2x_alloc_ilt_lines_mem(struct bnx2x_softc *sc)
 {
sc->ilt->lines = rte_calloc("",
-   sizeof(struct ilt_line), ILT_MAX_LINES,
+   ILT_MAX_LINES, sizeof(struct ilt_line),
RTE_CACHE_LINE_SIZE);
return sc->ilt->lines == NULL;
 }
-- 
2.34.1

[PATCH v2 8/8] net/sfc: fix calloc parameters

[Ferruh Yigit]

gcc [1] generates warning [2] about rte_calloc usage, because
rte_calloc parameter order is wrong, fixing it by replacing parameters.

[1]
gcc (GCC) 14.0.1 20240124 (experimental)

[2]
Compiling C object drivers/libtmp_rte_net_sfc.a.p/net_sfc_sfc_mae.c.o
../net/sfc/sfc_mae.c: In function ‘sfc_mae_action_set_list_add’:
../drivers/net/sfc/sfc_mae.c:1353:35:
 warning: ‘rte_calloc’ sizes specified with ‘sizeof’ in the earlier
 argument and not in the later argument [-Wcalloc-transposed-args]
 1353 |sizeof(struct sfc_mae_action_set *),
  |   ^~

Fixes: 002f591f54c3 ("net/sfc: support packet replay in transfer flows")
Cc: sta...@dpdk.org

Signed-off-by: Ferruh Yigit 
---
Cc: ivan.ma...@arknetworks.am
---
 drivers/net/sfc/sfc_mae.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/sfc/sfc_mae.c b/drivers/net/sfc/sfc_mae.c
index e5ec0ae49d4d..60ff6d21810a 100644
--- a/drivers/net/sfc/sfc_mae.c
+++ b/drivers/net/sfc/sfc_mae.c
@@ -1350,8 +1350,8 @@ sfc_mae_action_set_list_add(struct sfc_adapter *sa,
 
action_set_list->action_sets =
rte_calloc("sfc_mae_action_set_list_action_sets",
-  sizeof(struct sfc_mae_action_set *),
-  action_set_list->nb_action_sets, 0);
+  action_set_list->nb_action_sets,
+  sizeof(struct sfc_mae_action_set *), 0);
if (action_set_list->action_sets == NULL) {
sfc_err(sa, "failed to allocate action set list");
rte_free(action_set_list);
-- 
2.34.1

RE: [PATCH v2 4/8] eventdev: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object lib/librte_eventdev.a.p/eventdev_rte_eventdev.c.o
> ../lib/eventdev/rte_eventdev.c: In function ‘handle_dev_dump’:
> ../lib/eventdev/rte_eventdev.c:2005:29:
>   warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument [-Wcalloc-transposed-args]
>  2005 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: a3b7b476d723 ("eventdev: support telemetry dump eventdev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 3/8] rawdev: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.0 20240108 (experimental)
> 
> [2]
> Compiling C object .../lib/librte_rawdev.a.p/rawdev_rte_rawdev.c.o
> ../lib/rawdev/rte_rawdev.c: In function ‘handle_dev_dump’:
> ../lib/rawdev/rte_rawdev.c:659:29:
>   error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument
>   [-Werror=calloc-transposed-args]
>   659 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: e915d404eb72 ("rawdev: support telemetry dump rawdev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 5/8] dmadev: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> To: Chengwen Feng; Kevin Laatz; Bruce Richardson; Morten Brørup
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH v2 5/8] dmadev: fix calloc parameters
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object lib/librte_dmadev.a.p/dmadev_rte_dmadev.c.o
> ../lib/dmadev/rte_dmadev.c: In function ‘dmadev_handle_dev_dump’:
> ../lib/dmadev/rte_dmadev.c:1033:29:
>   warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument [-Wcalloc-transposed-args]
>  1033 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: 94043b04212a ("dmadev: support telemetry dump dmadev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 1/8] pipeline: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.0 20231102 (experimental)
> 
> [2]
>  Compiling C object .../pipeline_rte_swx_pipeline_spec.c.o
> .../rte_swx_pipeline_spec.c: In function ‘pipeline_spec_parse’:
> ../lib/pipeline/rte_swx_pipeline_spec.c:2893:11:
>   warning: allocation of insufficient size ‘1’ for type
>‘struct pipeline_spec’ with size ‘144’ [-Walloc-size]
>  2893 | s = calloc(sizeof(struct pipeline_spec), 1);
>   |   ^
> 
> .../rte_swx_pipeline_spec.c: In function ‘pipeline_iospec_parse’:
> ../lib/pipeline/rte_swx_pipeline_spec.c:4244:11:
>   warning: allocation of insufficient size ‘1’ for type
>‘struct pipeline_iospec’ with size ‘64’ [-Walloc-size]
>  4244 | s = calloc(sizeof(struct pipeline_iospec), 1);
>   |   ^
> 
> Fixes: 30c4abb90942 ("pipeline: rework specification file-based
> pipeline build")
> Fixes: 54cae37ef4ef ("pipeline: support I/O specification")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> Acked-by: Cristian Dumitrescu 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 2/8] net/nfp: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.0 20231102 (experimental)
> 
> [2]
> Compiling C object .../net_nfp_nfpcore_nfp_mutex.c.o
> .../net/nfp/nfpcore/nfp_mutex.c: In function ‘nfp_cpp_mutex_alloc’:
> ../drivers/net/nfp/nfpcore/nfp_mutex.c:171:15:
>   warning: allocation of insufficient size ‘1’ for type
>‘struct nfp_cpp_mutex’ with size ‘48’ [-Walloc-size]
>   171 | mutex = calloc(sizeof(*mutex), 1);
>   |   ^
> 
> Fixes: c7e9729da6b5 ("net/nfp: support CPP")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> Acked-by: Chaoyong He 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 6/8] common/mlx5: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object .../common_mlx5_mlx5_common_mr.c.o
> .../mlx5/mlx5_common_mr.c: In function ‘mlx5_mempool_get_chunks’:
> .../common/mlx5/mlx5_common_mr.c:1384:29:
>   warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument [-Wcalloc-transposed-args]
>  1384 | *out = calloc(sizeof(**out), n);
>   | ^
> 
> Fixes: 7297d2cdecce ("common/mlx5: fix external memory pool
> registration")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 7/8] net/bnx2x: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about rte_calloc usage, because
> rte_calloc parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x.c.o
> ../drivers/net/bnx2x/bnx2x.c: In function ‘bnx2x_alloc_ilt_lines_mem’:
> ../drivers/net/bnx2x/bnx2x.c:2392:44:
>  warning: ‘rte_calloc’ sizes specified with ‘sizeof’ in the earlier
>  argument and not in the later argument [-Wcalloc-transposed-args]
>  2392 | sizeof(struct ilt_line), ILT_MAX_LINES,
>   |^~
> 
> Fixes: 540a211084a7 ("bnx2x: driver core")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

RE: [PATCH v2 8/8] net/sfc: fix calloc parameters

[Morten Brørup]

> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Wednesday, 24 January 2024 19.54
> 
> gcc [1] generates warning [2] about rte_calloc usage, because
> rte_calloc parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object drivers/libtmp_rte_net_sfc.a.p/net_sfc_sfc_mae.c.o
> ../net/sfc/sfc_mae.c: In function ‘sfc_mae_action_set_list_add’:
> ../drivers/net/sfc/sfc_mae.c:1353:35:
>  warning: ‘rte_calloc’ sizes specified with ‘sizeof’ in the earlier
>  argument and not in the later argument [-Wcalloc-transposed-args]
>  1353 |sizeof(struct sfc_mae_action_set *),
>   |   ^~
> 
> Fixes: 002f591f54c3 ("net/sfc: support packet replay in transfer
> flows")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---

Acked-by: Morten Brørup 

[PATCH 0/2] more replacement of zero length array

[Tyler Retzlaff]

Replace some missed zero length arrays not captured in the
original series.
https://patchwork.dpdk.org/project/dpdk/list/?series=30410&state=*

Zero length arrays are a GNU extension that has been
superseded by flex arrays.

https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Tyler Retzlaff (2):
  hash: replace zero length array with flex array
  rcu: replace zero length array with flex array

 lib/hash/rte_thash.c   | 4 ++--
 lib/rcu/rcu_qsbr_pvt.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.8.3.1

[PATCH 2/2] rcu: replace zero length array with flex array

[Tyler Retzlaff]

Zero length arrays are GNU extension. Replace with
standard flex array.

Signed-off-by: Tyler Retzlaff 
---
 lib/rcu/rcu_qsbr_pvt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/rcu/rcu_qsbr_pvt.h b/lib/rcu/rcu_qsbr_pvt.h
index 5fd7ca2..96d05e6 100644
--- a/lib/rcu/rcu_qsbr_pvt.h
+++ b/lib/rcu/rcu_qsbr_pvt.h
@@ -52,7 +52,7 @@ struct rte_rcu_qsbr_dq {
  */
 typedef struct {
uint64_t token;  /**< Token */
-   uint8_t elem[0]; /**< Pointer to user element */
+   uint8_t elem[]; /**< Pointer to user element */
 } __attribute__((__may_alias__)) __rte_rcu_qsbr_dq_elem_t;
 
 #endif /* _RTE_RCU_QSBR_PVT_H_ */
-- 
1.8.3.1

[PATCH 1/2] hash: replace zero length array with flex array

[Tyler Retzlaff]

Zero length arrays are GNU extension. Replace with
standard flex array.

Signed-off-by: Tyler Retzlaff 
---
 lib/hash/rte_thash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
index e8de071..1982051 100644
--- a/lib/hash/rte_thash.c
+++ b/lib/hash/rte_thash.c
@@ -80,7 +80,7 @@ struct rte_thash_subtuple_helper {
uint32_ttuple_offset;   /** < Offset in bits of the subtuple */
uint32_ttuple_len;  /** < Length in bits of the subtuple */
uint32_tlsb_msk;/** < (1 << reta_sz_log) - 1 */
-   __extension__ uint32_t  compl_table[0] __rte_cache_aligned;
+   uint32_tcompl_table[] __rte_cache_aligned;
/** < Complementary table */
 };
 
@@ -93,7 +93,7 @@ struct rte_thash_ctx {
uint32_tflags;
uint64_t*matrices;
/**< matrices used with rte_thash_gfni implementation */
-   uint8_t hash_key[0];
+   uint8_t hash_key[];
 };
 
 int
-- 
1.8.3.1

RE: [PATCH 2/2] rcu: replace zero length array with flex array

[Honnappa Nagarahalli]

> -Original Message-
> From: Tyler Retzlaff 
> Sent: Wednesday, January 24, 2024 4:18 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson ; Honnappa Nagarahalli
> ; Sameh Gobriel
> ; Vladimir Medvedkin
> ; Yipeng Wang ;
> Stephen Hemminger ; Tyler Retzlaff
> 
> Subject: [PATCH 2/2] rcu: replace zero length array with flex array
> 
> Zero length arrays are GNU extension. Replace with standard flex array.
> 
> Signed-off-by: Tyler Retzlaff 
Reviewed-by: Honnappa Nagarahalli 

> ---
>  lib/rcu/rcu_qsbr_pvt.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/rcu/rcu_qsbr_pvt.h b/lib/rcu/rcu_qsbr_pvt.h index
> 5fd7ca2..96d05e6 100644
> --- a/lib/rcu/rcu_qsbr_pvt.h
> +++ b/lib/rcu/rcu_qsbr_pvt.h
> @@ -52,7 +52,7 @@ struct rte_rcu_qsbr_dq {
>   */
>  typedef struct {
>   uint64_t token;  /**< Token */
> - uint8_t elem[0]; /**< Pointer to user element */
> + uint8_t elem[]; /**< Pointer to user element */
>  } __attribute__((__may_alias__)) __rte_rcu_qsbr_dq_elem_t;
> 
>  #endif /* _RTE_RCU_QSBR_PVT_H_ */
> --
> 1.8.3.1

RE: [PATCH 1/2] hash: replace zero length array with flex array

[Honnappa Nagarahalli]

> -Original Message-
> From: Tyler Retzlaff 
> Sent: Wednesday, January 24, 2024 4:18 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson ; Honnappa Nagarahalli
> ; Sameh Gobriel
> ; Vladimir Medvedkin
> ; Yipeng Wang ;
> Stephen Hemminger ; Tyler Retzlaff
> 
> Subject: [PATCH 1/2] hash: replace zero length array with flex array
> 
> Zero length arrays are GNU extension. Replace with standard flex array.
> 
> Signed-off-by: Tyler Retzlaff 
Reviewed-by: Honnappa Nagarahalli 

> ---
>  lib/hash/rte_thash.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c index 
> e8de071..1982051
> 100644
> --- a/lib/hash/rte_thash.c
> +++ b/lib/hash/rte_thash.c
> @@ -80,7 +80,7 @@ struct rte_thash_subtuple_helper {
>   uint32_ttuple_offset;   /** < Offset in bits of the subtuple */
>   uint32_ttuple_len;  /** < Length in bits of the subtuple */
>   uint32_tlsb_msk;/** < (1 << reta_sz_log) - 1 */
> - __extension__ uint32_t  compl_table[0] __rte_cache_aligned;
> + uint32_tcompl_table[] __rte_cache_aligned;
>   /** < Complementary table */
>  };
> 
> @@ -93,7 +93,7 @@ struct rte_thash_ctx {
>   uint32_tflags;
>   uint64_t*matrices;
>   /**< matrices used with rte_thash_gfni implementation */
> - uint8_t hash_key[0];
> + uint8_t hash_key[];
>  };
> 
>  int
> --
> 1.8.3.1

[PATCH 0/9] use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) and __alignof__(e) with C11 alignof(T)
and alignof(typeof(e)) respectively to improve portability of the code
between toolchains.

Tyler Retzlaff (9):
  ring: use C11 alignof
  mbuf: use C11 alignof
  ethdev: use C11 alignof
  eventdev: use C11 alignof
  stack: use C11 alignof
  node: use C11 alignof
  pdcp: use C11 alignof
  reorder: use C11 alignof
  security: use C11 alignof

 lib/ethdev/ethdev_driver.c  | 3 ++-
 lib/ethdev/rte_flow.c   | 3 ++-
 lib/eventdev/rte_eventdev.c | 3 ++-
 lib/mbuf/rte_mbuf_dyn.c | 3 ++-
 lib/node/node_private.h | 4 +++-
 lib/pdcp/rte_pdcp.c | 4 +++-
 lib/reorder/rte_reorder.c   | 3 ++-
 lib/ring/rte_ring.c | 3 ++-
 lib/security/rte_security.c | 5 +++--
 lib/stack/rte_stack.c   | 3 ++-
 10 files changed, 23 insertions(+), 11 deletions(-)

-- 
1.8.3.1

[PATCH 1/9] ring: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(e) with C11 alignof(typeof(e)) to improve
portability between toolchains

Signed-off-by: Tyler Retzlaff 
---
 lib/ring/rte_ring.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index c59f626..a783299 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -7,6 +7,7 @@
  * Used as BSD-3 Licensed with permission from Kip Macy.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -288,7 +289,7 @@ struct rte_ring *
 * rte_errno for us appropriately - hence no check in this function
 */
mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
-mz_flags, __alignof__(*r));
+mz_flags, alignof(typeof(*r)));
if (mz != NULL) {
r = mz->addr;
/* no need to check return value here, we already checked the
-- 
1.8.3.1

[PATCH 2/9] mbuf: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/mbuf/rte_mbuf_dyn.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/mbuf/rte_mbuf_dyn.c b/lib/mbuf/rte_mbuf_dyn.c
index 446018f..1cfb329 100644
--- a/lib/mbuf/rte_mbuf_dyn.c
+++ b/lib/mbuf/rte_mbuf_dyn.c
@@ -2,6 +2,7 @@
  * Copyright 2019 6WIND S.A.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -585,7 +586,7 @@ void rte_mbuf_dyn_dump(FILE *out)
static const struct rte_mbuf_dynfield field_desc = {
.name = RTE_MBUF_DYNFIELD_TIMESTAMP_NAME,
.size = sizeof(rte_mbuf_timestamp_t),
-   .align = __alignof__(rte_mbuf_timestamp_t),
+   .align = alignof(rte_mbuf_timestamp_t),
};
struct rte_mbuf_dynflag flag_desc = {};
int offset;
-- 
1.8.3.1

[PATCH 4/9] eventdev: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/eventdev/rte_eventdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 94628a6..d494f8f 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -2,6 +2,7 @@
  * Copyright(c) 2016 Cavium, Inc
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1405,7 +1406,7 @@ int rte_event_dev_selftest(uint8_t dev_id)
static const struct rte_mbuf_dynfield test_seqn_dynfield_desc = {
.name = "rte_event_pmd_selftest_seqn_dynfield",
.size = sizeof(rte_event_pmd_selftest_seqn_t),
-   .align = __alignof__(rte_event_pmd_selftest_seqn_t),
+   .align = alignof(rte_event_pmd_selftest_seqn_t),
};
struct rte_eventdev *dev = &rte_eventdevs[dev_id];
 
-- 
1.8.3.1

[PATCH 3/9] ethdev: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/ethdev/ethdev_driver.c | 3 ++-
 lib/ethdev/rte_flow.c  | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
index bd917a1..4d45fbd 100644
--- a/lib/ethdev/ethdev_driver.c
+++ b/lib/ethdev/ethdev_driver.c
@@ -2,6 +2,7 @@
  * Copyright(c) 2022 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -633,7 +634,7 @@ struct rte_eth_dev *
static const struct rte_mbuf_dynfield field_desc = {
.name = RTE_MBUF_DYNFIELD_IP_REASSEMBLY_NAME,
.size = sizeof(rte_eth_ip_reassembly_dynfield_t),
-   .align = __alignof__(rte_eth_ip_reassembly_dynfield_t),
+   .align = alignof(rte_eth_ip_reassembly_dynfield_t),
};
static const struct rte_mbuf_dynflag ip_reassembly_dynflag = {
.name = RTE_MBUF_DYNFLAG_IP_REASSEMBLY_INCOMPLETE_NAME,
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index f49d1d3..2cd30d6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -3,6 +3,7 @@
  * Copyright 2016 Mellanox Technologies, Ltd
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -281,7 +282,7 @@ struct rte_flow_desc_data {
static const struct rte_mbuf_dynfield desc_offs = {
.name = RTE_MBUF_DYNFIELD_METADATA_NAME,
.size = sizeof(uint32_t),
-   .align = __alignof__(uint32_t),
+   .align = alignof(uint32_t),
};
static const struct rte_mbuf_dynflag desc_flag = {
.name = RTE_MBUF_DYNFLAG_METADATA_NAME,
-- 
1.8.3.1

[PATCH 6/9] node: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/node/node_private.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/node/node_private.h b/lib/node/node_private.h
index 845fdaa..92acb9b 100644
--- a/lib/node/node_private.h
+++ b/lib/node/node_private.h
@@ -5,6 +5,8 @@
 #ifndef __NODE_PRIVATE_H__
 #define __NODE_PRIVATE_H__
 
+#include 
+
 #include 
 #include 
 #include 
@@ -42,7 +44,7 @@ struct node_mbuf_priv1 {
 static const struct rte_mbuf_dynfield node_mbuf_priv1_dynfield_desc = {
.name = "rte_node_dynfield_priv1",
.size = sizeof(struct node_mbuf_priv1),
-   .align = __alignof__(struct node_mbuf_priv1),
+   .align = alignof(struct node_mbuf_priv1),
 };
 extern int node_mbuf_priv1_dynfield_offset;
 
-- 
1.8.3.1

[PATCH 5/9] stack: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(e) with C11 alignof(typeof(e)) to improve
portability between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/stack/rte_stack.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/stack/rte_stack.c b/lib/stack/rte_stack.c
index 1dab6d6..7261281 100644
--- a/lib/stack/rte_stack.c
+++ b/lib/stack/rte_stack.c
@@ -2,6 +2,7 @@
  * Copyright(c) 2019 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -90,7 +91,7 @@ struct rte_stack *
rte_mcfg_tailq_write_lock();
 
mz = rte_memzone_reserve_aligned(mz_name, sz, socket_id,
-0, __alignof__(*s));
+0, alignof(typeof(*s)));
if (mz == NULL) {
STACK_LOG_ERR("Cannot reserve stack memzone!");
rte_mcfg_tailq_write_unlock();
-- 
1.8.3.1

[PATCH 7/9] pdcp: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/pdcp/rte_pdcp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/pdcp/rte_pdcp.c b/lib/pdcp/rte_pdcp.c
index 1c6d246..1c076fb 100644
--- a/lib/pdcp/rte_pdcp.c
+++ b/lib/pdcp/rte_pdcp.c
@@ -2,6 +2,8 @@
  * Copyright(C) 2023 Marvell.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -32,7 +34,7 @@ struct entity_layout {
const struct rte_mbuf_dynfield dynfield_desc = {
.name = RTE_PDCP_DYNFIELD_NAME,
.size = sizeof(rte_pdcp_dynfield_t),
-   .align = __alignof__(rte_pdcp_dynfield_t),
+   .align = alignof(rte_pdcp_dynfield_t),
};
 
if (rte_pdcp_dynfield_offset != -1)
-- 
1.8.3.1

[PATCH 8/9] reorder: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/reorder/rte_reorder.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
index ff81544..c080b2c 100644
--- a/lib/reorder/rte_reorder.c
+++ b/lib/reorder/rte_reorder.c
@@ -2,6 +2,7 @@
  * Copyright(c) 2010-2014 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -72,7 +73,7 @@ struct rte_reorder_buffer *
static const struct rte_mbuf_dynfield reorder_seqn_dynfield_desc = {
.name = RTE_REORDER_SEQN_DYNFIELD_NAME,
.size = sizeof(rte_reorder_seqn_t),
-   .align = __alignof__(rte_reorder_seqn_t),
+   .align = alignof(rte_reorder_seqn_t),
};
 
if (b == NULL) {
-- 
1.8.3.1

[PATCH 9/9] security: use C11 alignof

[Tyler Retzlaff]

Replace use of __alignof__(T) with C11 alignof(T) to improve portability
between toolchains.

Signed-off-by: Tyler Retzlaff 
---
 lib/security/rte_security.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index b082a29..e5c862f 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -4,6 +4,7 @@
  * Copyright (c) 2020 Samsung Electronics Co., Ltd All Rights Reserved
  */
 
+#include 
 #include 
 #include 
 
@@ -38,7 +39,7 @@
static const struct rte_mbuf_dynfield dynfield_desc = {
.name = RTE_SECURITY_DYNFIELD_NAME,
.size = sizeof(rte_security_dynfield_t),
-   .align = __alignof__(rte_security_dynfield_t),
+   .align = alignof(rte_security_dynfield_t),
};
rte_security_dynfield_offset =
rte_mbuf_dynfield_register(&dynfield_desc);
@@ -51,7 +52,7 @@
static const struct rte_mbuf_dynfield dynfield_desc = {
.name = RTE_SECURITY_OOP_DYNFIELD_NAME,
.size = sizeof(rte_security_oop_dynfield_t),
-   .align = __alignof__(rte_security_oop_dynfield_t),
+   .align = alignof(rte_security_oop_dynfield_t),
};
 
rte_security_oop_dynfield_offset =
-- 
1.8.3.1

RE: [EXT] [PATCH 8/9] reorder: use C11 alignof

[Volodymyr Fialko]

> -Original Message-
> From: Tyler Retzlaff 
> Sent: Thursday, January 25, 2024 12:18 AM
> To: dev@dpdk.org
> Cc: Akhil Goyal ; Andrew Rybchenko 
> ;
> Anoob Joseph ; Ferruh Yigit ; 
> Honnappa Nagarahalli
> ; Jerin Jacob ; Konstantin 
> Ananyev
> ; Nithin Kumar Dabilpuram 
> ; Ori Kam
> ; Pavan Nikhilesh Bhagavatula ; 
> Thomas Monjalon
> ; Volodymyr Fialko ; Tyler Retzlaff
> 
> Subject: [EXT] [PATCH 8/9] reorder: use C11 alignof
> 
> External Email
> 
> --
> Replace use of __alignof__(T) with C11 alignof(T) to improve portability 
> between toolchains.
> 
> Signed-off-by: Tyler Retzlaff 
> ---
>  lib/reorder/rte_reorder.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

__alignof__ is supported by GCC from C99, but since DPDK 23.11 C11 compiler is 
required anyway, It should be fine to switch.

Acked-by: Volodymyr Fialko 

/Volodymyr

Re: [PATCH v2 3/8] rawdev: fix calloc parameters

[fengchengwen]

Reviewed-by: Chengwen Feng 

Thanks

On 2024/1/25 2:54, Ferruh Yigit wrote:
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.0 20240108 (experimental)
> 
> [2]
> Compiling C object .../lib/librte_rawdev.a.p/rawdev_rte_rawdev.c.o
> ../lib/rawdev/rte_rawdev.c: In function ‘handle_dev_dump’:
> ../lib/rawdev/rte_rawdev.c:659:29:
>   error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument
>   [-Werror=calloc-transposed-args]
>   659 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: e915d404eb72 ("rawdev: support telemetry dump rawdev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---
> Cc: fengcheng...@huawei.com
> ---
>  lib/rawdev/rte_rawdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/rawdev/rte_rawdev.c b/lib/rawdev/rte_rawdev.c
> index 474bdc95407f..4f8897b63947 100644
> --- a/lib/rawdev/rte_rawdev.c
> +++ b/lib/rawdev/rte_rawdev.c
> @@ -656,7 +656,7 @@ handle_dev_dump(const char *cmd __rte_unused,
>   if (!rte_rawdev_pmd_is_valid_dev(dev_id))
>   return -EINVAL;
>  
> - buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
> + buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
>   if (buf == NULL)
>   return -ENOMEM;
>  
> 

Re: [PATCH v2 4/8] eventdev: fix calloc parameters

[fengchengwen]

Reviewed-by: Chengwen Feng 

Thanks

On 2024/1/25 2:54, Ferruh Yigit wrote:
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object lib/librte_eventdev.a.p/eventdev_rte_eventdev.c.o
> ../lib/eventdev/rte_eventdev.c: In function ‘handle_dev_dump’:
> ../lib/eventdev/rte_eventdev.c:2005:29:
>   warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument [-Wcalloc-transposed-args]
>  2005 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: a3b7b476d723 ("eventdev: support telemetry dump eventdev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---
> Cc: fengcheng...@huawei.com
> ---
>  lib/eventdev/rte_eventdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index 157752868d5b..1c865e993fec 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -2002,7 +2002,7 @@ handle_dev_dump(const char *cmd __rte_unused,
>  
>   RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
>  
> - buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
> + buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
>   if (buf == NULL)
>   return -ENOMEM;
>  
> 

Re: [PATCH v2 5/8] dmadev: fix calloc parameters

[fengchengwen]

Reviewed-by: Chengwen Feng 

Thanks

On 2024/1/25 2:54, Ferruh Yigit wrote:
> gcc [1] generates warning [2] about calloc usage, because calloc
> parameter order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.1 20240124 (experimental)
> 
> [2]
> Compiling C object lib/librte_dmadev.a.p/dmadev_rte_dmadev.c.o
> ../lib/dmadev/rte_dmadev.c: In function ‘dmadev_handle_dev_dump’:
> ../lib/dmadev/rte_dmadev.c:1033:29:
>   warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument [-Wcalloc-transposed-args]
>  1033 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: 94043b04212a ("dmadev: support telemetry dump dmadev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 
> ---
> Cc: fengcheng...@huawei.com
> ---
>  lib/dmadev/rte_dmadev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 5953a77bd6f9..c4e909270058 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -1030,7 +1030,7 @@ dmadev_handle_dev_dump(const char *cmd __rte_unused,
>   if (*end_param != '\0')
>   RTE_DMA_LOG(WARNING, "Extra parameters passed to dmadev 
> telemetry command, ignoring");
>  
> - buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
> + buf = calloc(RTE_TEL_MAX_SINGLE_STRING_LEN, sizeof(char));
>   if (buf == NULL)
>   return -ENOMEM;
>  
> 

[PATCH] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX WQEs

[longli]

From: Long Li 

Instead of allocating mbufs one by one during RX, use
rte_pktmbuf_alloc_bulk() to allocate them in a batch.

Signed-off-by: Long Li 
---
 drivers/net/mana/rx.c | 67 +++
 1 file changed, 43 insertions(+), 24 deletions(-)

diff --git a/drivers/net/mana/rx.c b/drivers/net/mana/rx.c
index acad5e26cd..400a4e52f4 100644
--- a/drivers/net/mana/rx.c
+++ b/drivers/net/mana/rx.c
@@ -2,6 +2,7 @@
  * Copyright 2022 Microsoft Corporation
  */
 #include 
+#include 
 
 #include 
 #include 
@@ -59,9 +60,8 @@ mana_rq_ring_doorbell(struct mana_rxq *rxq)
 }
 
 static int
-mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
+mana_post_rx_wqe(struct mana_rxq *rxq, struct rte_mbuf *mbuf)
 {
-   struct rte_mbuf *mbuf = NULL;
struct gdma_sgl_element sgl[1];
struct gdma_work_request request;
uint32_t wqe_size_in_bu;
@@ -69,12 +69,6 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
int ret;
struct mana_mr_cache *mr;
 
-   mbuf = rte_pktmbuf_alloc(rxq->mp);
-   if (!mbuf) {
-   rxq->stats.nombuf++;
-   return -ENOMEM;
-   }
-
mr = mana_alloc_pmd_mr(&rxq->mr_btree, priv, mbuf);
if (!mr) {
DP_LOG(ERR, "failed to register RX MR");
@@ -121,19 +115,31 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
  * Post work requests for a Rx queue.
  */
 static int
-mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
+mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count)
 {
int ret;
uint32_t i;
+   struct rte_mbuf **mbufs;
+
+   mbufs = rte_calloc("mana_rx_mbufs", count, sizeof(struct rte_mbuf *), 
0);
+   if (!mbufs)
+   return -ENOMEM;
+
+   ret = rte_pktmbuf_alloc_bulk(rxq->mp, mbufs, count);
+   if (ret) {
+   DP_LOG(ERR, "failed to allocate mbufs for RX");
+   rxq->stats.nombuf += count;
+   goto fail;
+   }
 
 #ifdef RTE_ARCH_32
rxq->wqe_cnt_to_short_db = 0;
 #endif
-   for (i = 0; i < rxq->num_desc; i++) {
-   ret = mana_alloc_and_post_rx_wqe(rxq);
+   for (i = 0; i < count; i++) {
+   ret = mana_post_rx_wqe(rxq, mbufs[i]);
if (ret) {
DP_LOG(ERR, "failed to post RX ret = %d", ret);
-   return ret;
+   goto fail;
}
 
 #ifdef RTE_ARCH_32
@@ -146,6 +152,8 @@ mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
 
mana_rq_ring_doorbell(rxq);
 
+fail:
+   rte_free(mbufs);
return ret;
 }
 
@@ -404,7 +412,9 @@ mana_start_rx_queues(struct rte_eth_dev *dev)
}
 
for (i = 0; i < priv->num_queues; i++) {
-   ret = mana_alloc_and_post_rx_wqes(dev->data->rx_queues[i]);
+   struct mana_rxq *rxq = dev->data->rx_queues[i];
+
+   ret = mana_alloc_and_post_rx_wqes(rxq, rxq->num_desc);
if (ret)
goto fail;
}
@@ -423,7 +433,7 @@ uint16_t
 mana_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, uint16_t pkts_n)
 {
uint16_t pkt_received = 0;
-   uint16_t wqe_posted = 0;
+   uint16_t wqe_consumed = 0;
struct mana_rxq *rxq = dpdk_rxq;
struct mana_priv *priv = rxq->priv;
struct rte_mbuf *mbuf;
@@ -535,18 +545,23 @@ mana_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
 
rxq->gdma_rq.tail += desc->wqe_size_in_bu;
 
-   /* Consume this request and post another request */
-   ret = mana_alloc_and_post_rx_wqe(rxq);
-   if (ret) {
-   DP_LOG(ERR, "failed to post rx wqe ret=%d", ret);
-   break;
-   }
-
-   wqe_posted++;
+   /* Record the number of the RX WQE we need to post to replenish
+* consumed RX requests
+*/
+   wqe_consumed++;
if (pkt_received == pkts_n)
break;
 
 #ifdef RTE_ARCH_32
+   /* Always post WQE as soon as it's consumed for short DB */
+   ret = mana_alloc_and_post_rx_wqes(rxq, wqe_consumed);
+   if (ret) {
+   DRV_LOG(ERR, "failed to post %d WQEs, ret %d",
+   wqe_consumed, ret);
+   return pkt_received;
+   }
+   wqe_consumed = 0;
+
/* Ring short doorbell if approaching the wqe increment
 * limit.
 */
@@ -569,8 +584,12 @@ mana_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
goto repoll;
}
 
-   if (wqe_posted)
-   mana_rq_ring_doorbell(rxq);
+   if (wqe_consumed) {
+   ret = mana_alloc_and_post_rx_wqes(rxq, wqe_consumed);
+   if (ret)
+   DRV_LOG(ERR, "failed to post %d WQEs, ret %d",
+  

Re: [PATCH] lib: remove duplicate prefix in logs

[fengchengwen]

For dmadev part
Reviewed-by: Chengwen Feng 

Thanks

On 2024/1/24 20:04, David Marchand wrote:
> RTE_LOG() macros prefixe the log messages based on the logtype.
> This results in logs like:
> 
> TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> TMTY: TELEMETRY: Socket creation and binding ok
> TMTY: TELEMETRY: Telemetry initialized ok
> 
> Remove redundancy in some libraries following their conversion to
> RTE_LOG/RTE_LOG_LINE.
> 
> Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
> 
> Reported-by: Thomas Monjalon 
> Signed-off-by: David Marchand 
> ---
>  lib/dmadev/rte_dmadev.c   | 3 +--
>  lib/gpudev/gpudev.c   | 3 +--
>  lib/graph/graph_private.h | 2 +-
>  lib/node/node_private.h   | 2 +-
>  lib/telemetry/telemetry.c | 4 ++--
>  lib/vhost/vhost.h | 6 +++---
>  6 files changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 5953a77bd6..dbaa14f262 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -35,8 +35,7 @@ RTE_LOG_REGISTER_DEFAULT(rte_dma_logtype, INFO);
>  #define RTE_LOGTYPE_DMA rte_dma_logtype
>  
>  #define RTE_DMA_LOG(level, ...) \
> - RTE_LOG_LINE(level, DMA, RTE_FMT("dma: " RTE_FMT_HEAD(__VA_ARGS__ ,), \
> - RTE_FMT_TAIL(__VA_ARGS__ ,)))
> + RTE_LOG_LINE(level, DMA, "" __VA_ARGS__)
>  
>  int
>  rte_dma_dev_max(size_t dev_max)

...

[PATCH] vdpa/mlx5: fix queue enable drain CQ

[Yajun Wu]

For the case: `ethtool -L eth0 combined xxx` in VM, VQ will disable
and enable without calling device close. In such case, need add
drain CQ before reuse/reset event QP.

Fixes: 24969c7b62 ("vdpa/mlx5: reuse event queues")
Cc: sta...@dpdk.org

Signed-off-by: Yajun Wu 
Acked-by: Matan Azrad 
---
 drivers/vdpa/mlx5/mlx5_vdpa_event.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/vdpa/mlx5/mlx5_vdpa_event.c 
b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
index 9557c1042e..32430614d5 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
@@ -244,22 +244,30 @@ mlx5_vdpa_queues_complete(struct mlx5_vdpa_priv *priv)
return max;
 }
 
+static void
+mlx5_vdpa_drain_cq_one(struct mlx5_vdpa_priv *priv,
+   struct mlx5_vdpa_virtq *virtq)
+{
+   struct mlx5_vdpa_cq *cq = &virtq->eqp.cq;
+
+   mlx5_vdpa_queue_complete(cq);
+   if (cq->cq_obj.cq) {
+   cq->cq_obj.cqes[0].wqe_counter = rte_cpu_to_be_16(UINT16_MAX);
+   virtq->eqp.qp_pi = 0;
+   if (!cq->armed)
+   mlx5_vdpa_cq_arm(priv, cq);
+   }
+}
+
 void
 mlx5_vdpa_drain_cq(struct mlx5_vdpa_priv *priv)
 {
+   struct mlx5_vdpa_virtq *virtq;
unsigned int i;
 
for (i = 0; i < priv->caps.max_num_virtio_queues; i++) {
-   struct mlx5_vdpa_cq *cq = &priv->virtqs[i].eqp.cq;
-
-   mlx5_vdpa_queue_complete(cq);
-   if (cq->cq_obj.cq) {
-   cq->cq_obj.cqes[0].wqe_counter =
-   rte_cpu_to_be_16(UINT16_MAX);
-   priv->virtqs[i].eqp.qp_pi = 0;
-   if (!cq->armed)
-   mlx5_vdpa_cq_arm(priv, cq);
-   }
+   virtq = &priv->virtqs[i];
+   mlx5_vdpa_drain_cq_one(priv, virtq);
}
 }
 
@@ -632,6 +640,7 @@ mlx5_vdpa_event_qp_prepare(struct mlx5_vdpa_priv *priv, 
uint16_t desc_n,
if (eqp->cq.cq_obj.cq != NULL && log_desc_n == eqp->cq.log_desc_n) {
/* Reuse existing resources. */
eqp->cq.callfd = callfd;
+   mlx5_vdpa_drain_cq_one(priv, virtq);
/* FW will set event qp to error state in q destroy. */
if (reset && !mlx5_vdpa_qps2rst2rts(eqp))
rte_write32(rte_cpu_to_be_32(RTE_BIT32(log_desc_n)),
-- 
2.27.0

RE: [PATCH v2 3/8] rawdev: fix calloc parameters

[Hemant Agrawal]

> gcc [1] generates warning [2] about calloc usage, because calloc parameter
> order is wrong, fixing it by replacing parameters.
> 
> [1]
> gcc (GCC) 14.0.0 20240108 (experimental)
> 
> [2]
> Compiling C object .../lib/librte_rawdev.a.p/rawdev_rte_rawdev.c.o
> ../lib/rawdev/rte_rawdev.c: In function ‘handle_dev_dump’:
> ../lib/rawdev/rte_rawdev.c:659:29:
>   error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier
>   argument and not in the later argument
>   [-Werror=calloc-transposed-args]
>   659 | buf = calloc(sizeof(char), RTE_TEL_MAX_SINGLE_STRING_LEN);
>   | ^~~~
> 
> Fixes: e915d404eb72 ("rawdev: support telemetry dump rawdev")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ferruh Yigit 

Reviewed-by:  Hemant Agrawal 


smime.p7s
Description: S/MIME cryptographic signature

[PATCH v1] doc: update guideline for fix commit messages

[Sivaramakrishnan Venkat]

Maintainers remove the Cc author line when merging the patch.
So, the guidelines is updated with a suggestion for the placement
of Cc lines in a commit message for easy merging.

Signed-off-by: Sivaramakrishnan Venkat 
---
 doc/guides/contributing/patches.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index e286d9e6d5..e109365599 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -275,6 +275,12 @@ Here are some guidelines for the body of a commit message:
 
  Signed-off-by: Alex Smith 
 
+* .. Note::
+
+ Maintainers remove the "Cc: aut...@example.com" line when merging the 
patch.
+ To help the maintainer, the submitter may move this line to the notes 
section
+ of the commit, after the ``---`` separator.
+
 * When fixing an error or warning it is useful to add the error message and 
instructions on how to reproduce it.
 
 * Use correct capitalization, punctuation and spelling.
-- 
2.25.1

Re: [PATCH 02/12] argparse: add argparse library

[fengchengwen]

Hi Thomas,

On 2024/1/24 21:24, Thomas Monjalon wrote:
> 22/01/2024 04:57, Chengwen Feng:
>> Introduce argparse library (which was inspired by the thread [1]). This
>> commit provides public API and doc.
>>
>> [1] 
>> https://patchwork.dpdk.org/project/dpdk/patch/20231105054539.22303-2-fengcheng...@huawei.com/
> 
> I'm not sure how this helps with the initial problem
> when using kvargs with key-only.
> I think you should continue fixing kvargs API and usage.

This argparse couldn't direct help to fix kvargs with key-only.

I propose a patchset [1] to fix kvargs with key-only, waiting for more 
discussion.

[1] 
https://patchwork.dpdk.org/project/dpdk/cover/20231106073125.55280-1-fengcheng...@huawei.com/

> 
> About a generic argparse library, I imagine it could simplify DPDK internal 
> parsing.
> I have doubts about making it a public library as it is not really a DPDK 
> goal.
> The DMA example looks better with argparse so I imagine we want it.
> 
> I think this library would have a bigger value

In addition to service [argc, argv] parsing, This library also provide API 
which parse specific type.

For example, user could invoke:
  int value, ret;
  ret = rte_argparse_parse_type(str, RTE_ARGPARSE_ARG_VALUE_INT, &value);

to parse int from a input str.

This API then could used by other library/drivers.

> if we integrate some specific syntax parsing
> like coremask/corelist as done in another patchset:
> https://patches.dpdk.org/project/dpdk/list/?series=30582

Yes, I think it could integrate syntax parsing which providing from above 
patchset, just:

Define two arg-value type and specify their value storage type requirements:
  /** The argument's value is uint16_t xxx[RTE_MAX_LCORE] type. */
  RTE_ARGPARSE_ARG_VALUE_COREMASK,
  /** The argument's value is uint16_t xxx[RTE_MAX_LCORE] type. */
  RTE_ARGPARSE_ARG_VALUE_CORELIST,

Other library/driver could then invoke:
  uint16_t lcores[RTE_MAX_LCORE];
  int ret;
  ret = rte_argparse_parse_type(str, RTE_ARGPARSE_ARG_VALUE_COREMASK, lcores);
  or
  ret = rte_argparse_parse_type(str, RTE_ARGPARSE_ARG_VALUE_CORELIST, lcores)

Thanks

> 
> 
> 
> .
> 

RE: [EXT] [PATCH 7/9] pdcp: use C11 alignof

[Anoob Joseph]

> 
> External Email
> 
> --
> Replace use of __alignof__(T) with C11 alignof(T) to improve portability
> between toolchains.
> 
> Signed-off-by: Tyler Retzlaff 

Acked-by: Anoob Joseph