[PATCH v2] eal: add notes to SMP memory barrier APIs

[Ruifeng Wang]

The rte_smp_xx() APIs are deprecated. But it is not mentioned
in the function header.
Added notes in function header for clarification.

Signed-off-by: Ruifeng Wang 
---
v2: Made the notes more specific.

 lib/eal/include/generic/rte_atomic.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h 
b/lib/eal/include/generic/rte_atomic.h
index 58df843c54..35e0041ce6 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -55,6 +55,11 @@ static inline void rte_rmb(void);
  * Guarantees that the LOAD and STORE operations that precede the
  * rte_smp_mb() call are globally visible across the lcores
  * before the LOAD and STORE operations that follows it.
+ *
+ * @note
+ *  This function is deprecated. It provides fence synchronization
+ *  primitive but doesn't take memory order parameter.
+ *  rte_atomic_thread_fence() should be used instead.
  */
 static inline void rte_smp_mb(void);
 
@@ -64,6 +69,11 @@ static inline void rte_smp_mb(void);
  * Guarantees that the STORE operations that precede the
  * rte_smp_wmb() call are globally visible across the lcores
  * before the STORE operations that follows it.
+ *
+ * @note
+ *  This function is deprecated. It provides fence synchronization
+ *  primitive but doesn't take memory order parameter.
+ *  rte_atomic_thread_fence() should be used instead.
  */
 static inline void rte_smp_wmb(void);
 
@@ -73,6 +83,11 @@ static inline void rte_smp_wmb(void);
  * Guarantees that the LOAD operations that precede the
  * rte_smp_rmb() call are globally visible across the lcores
  * before the LOAD operations that follows it.
+ *
+ * @note
+ *  This function is deprecated. It provides fence synchronization
+ *  primitive but doesn't take memory order parameter.
+ *  rte_atomic_thread_fence() should be used instead.
  */
 static inline void rte_smp_rmb(void);
 ///@}
@@ -122,6 +137,10 @@ static inline void rte_io_rmb(void);
 
 /**
  * Synchronization fence between threads based on the specified memory order.
+ *
+ * @param memorder
+ *   The memory order defined by compiler atomic builtin at:
+ *   https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
  */
 static inline void rte_atomic_thread_fence(int memorder);
 
-- 
2.25.1

Re: [PATCH] regex/cn9k: remove rule compiler

[Thomas Monjalon]

25/06/2023 22:57, Stephen Hemminger:
> On Wed, 21 Jun 2023 21:03:00 +0530
> Jerin Jacob  wrote:
> 
> > On Wed, Jun 21, 2023 at 7:36 PM Thomas Monjalon  wrote:
> > >
> > > Nobody knows how to build the feature.
> > > When the dependency "rxp_compiler" is found,
> > > the header file is not available:
> > >
> > > drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error:
> > > rxp-compiler.h: No such file or directory
> > >
> > > It seems that it depends on a proprietay library.  
> > 
> > Yes. it depended on proprietary library owned by NVIDIA now. Not sure
> > Marvell has rights to publish it "freely available".
> > In order to avoid forking this library, better option to make this
> > library as public. Also, it looks like the library itself won't have
> > proper installation procedures that is the
> > reason for conflict as documented here in
> > https://bugs.dpdk.org/show_bug.cgi?id=1232.
> 
> Interesting. Then what about the GPU support which currently requires
> proprietary NVIDIA CUDA library

CUDA can be downloaded.
It is even packaged in many Linux distributions.

[PATCH] app/test-pipeline: relax RSS hash requirement

[Feifei Wang]

For some drivers which can not support the configured RSS hash functions,
the thread reports 'invalid rss_hf' when doing device configure.

For example, i40e driver can not support 'RTE_ETH_RSS_IPV4',
'RTE_ETH_RSS_IPV6' and 'RTE_ETH_RSS_NONFRAG_IPV6_OTHER', thus it can not
run successfully in test-pipeline with XL710 NIC and reports the issue:
-
Ethdev port_id=0 invalid rss_hf: 0xa38c, valid value: 0x7ef8
PANIC in app_init_ports():
Cannot init NIC port 0 (-22)
-

To fix this, referring to l3fwd operation, adjust the 'rss_hf' based on
device capability and just report a warning.

Signed-off-by: Feifei Wang 
Reviewed-by: Ruifeng Wang 
Reviewed-by: Trevor Tao 
---
 app/test-pipeline/init.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index d146c44be0..84a1734519 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -188,21 +188,41 @@ static void
 app_init_ports(void)
 {
uint32_t i;
+   struct rte_eth_dev_info dev_info;
+
 
/* Init NIC ports, then start the ports */
for (i = 0; i < app.n_ports; i++) {
uint16_t port;
int ret;
+   struct rte_eth_conf local_port_conf = port_conf;
 
port = app.ports[i];
RTE_LOG(INFO, USER1, "Initializing NIC port %u ...\n", port);
 
+   ret = rte_eth_dev_info_get(port, &dev_info);
+   if (ret != 0)
+   rte_panic("Error during getting device (port %u) info: 
%s\n",
+   port, rte_strerror(-ret));
+
/* Init port */
+   local_port_conf.rx_adv_conf.rss_conf.rss_hf &=
+   dev_info.flow_type_rss_offloads;
+   if (local_port_conf.rx_adv_conf.rss_conf.rss_hf !=
+   port_conf.rx_adv_conf.rss_conf.rss_hf) {
+   printf("Warning:"
+   "Port %u modified RSS hash function based on 
hardware support,"
+   "requested:%#"PRIx64" configured:%#"PRIx64"\n",
+   port,
+   port_conf.rx_adv_conf.rss_conf.rss_hf,
+   local_port_conf.rx_adv_conf.rss_conf.rss_hf);
+   }
+
ret = rte_eth_dev_configure(
port,
1,
1,
-   &port_conf);
+   &local_port_conf);
if (ret < 0)
rte_panic("Cannot init NIC port %u (%d)\n", port, ret);
 
-- 
2.25.1

[PATCH v1] maintainers: update maintainer for DLB Driver

[Abdullah Sevincer]

Abdullah Sevincer is now maintainer for DLB Driver.

Signed-off-by: Abdullah Sevincer 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fda0b55513..58ef06dd74 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1334,7 +1334,7 @@ M: Pavan Nikhilesh 
 F: drivers/event/octeontx/timvf_*
 
 Intel DLB2
-M: Timothy McDaniel 
+M: Abdullah Sevincer 
 F: drivers/event/dlb2/
 F: doc/guides/eventdevs/dlb2.rst
 
-- 
2.25.1

Re: [PATCH] crypto/openssl: do not build useless workaround

[Didier Pallard]

HI,
not sure to understand how it is possible.
If build  OPENSSL_VERSION_NUMBER <  0x1010L, linker should link binary
with libcrypto.so.1.0.0.
libcrypto.so.1.1 if build for 0x1010L and libcrypto.so.3 for
0x3000L
loader should not allow to link with a library different from the one used
at build time, no?

didier

On Sun, Jun 25, 2023 at 9:22 PM Thomas Monjalon  wrote:

> 18/04/2023 16:56, Didier Pallard:
> > This workaround was needed before version 1.0.1f. Do not build it for
> > versions >= 1.1.
> >
> > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
> > Signed-off-by: Didier Pallard 
> > Cc: sta...@dpdk.org
> [...]
> > +#if OPENSSL_VERSION_NUMBER < 0x1010L
> >   /* Workaround open ssl bug in version less then 1.0.1f */
> >   if (EVP_EncryptUpdate(ctx, empty, &unused, empty, 0) <= 0)
> >   goto process_auth_encryption_gcm_err;
> > +#endif
>
> What happens if we build with OpenSSL 1.1 and run with OpenSSL 1.0?
> Can we have a runtime check?
> Or is it better doing the workaround always as before?
>
>
>

Re: [PATCH v4] app/testpmd: fix primary process not polling all queues

[Jie Hai]

On 2023/6/23 0:40, Ali Alnubani wrote:

-Original Message-
From: Jie Hai 
Sent: Friday, June 9, 2023 12:04 PM
To: Aman Singh ; Yuying Zhang
; Anatoly Burakov ;
Matan Azrad ; Dmitry Kozlyuk

Cc: dev@dpdk.org; liudongdo...@huawei.com; shiyangx...@intel.com;
ferruh.yi...@amd.com
Subject: [PATCH v4] app/testpmd: fix primary process not polling all queues

Here's how the problem arises.
step1: Start the app.
 dpdk-testpmd -a :35:00.0 -l 0-3 -- -i --rxq=10 --txq=10

step2: Perform the following steps and send traffic. As expected,
queue 7 does not send or receive packets, and other queues do.
 port 0 rxq 7 stop
 port 0 txq 7 stop
 set fwd mac
 start

step3: Perform the following steps and send traffic. All queues
are expected to send and receive packets normally, but that's not
the case for queue 7.
 stop
 port stop all
 port start all
 start
 show port xstats all

In fact, only the value of rx_q7_packets for queue 7 is not zero,
which means queue 7 is enabled for the driver but is not involved
in packet receiving and forwarding by software. If we check queue
state by command 'show rxq info 0 7' and 'show txq info 0 7',
we see queue 7 is started as other queues are.
 Rx queue state: started
 Tx queue state: started
The queue 7 is started but cannot forward. That's the problem.

We know that each stream has a read-only "disabled" field that
control if this stream should be used to forward. This field
depends on testpmd local queue state, please see
commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
DPDK framework maintains ethdev queue state that drivers reported,
which indicates the real state of queues.

There are commands that update these two kind queue state such as
'port X rxq|txq start|stop'. But these operations take effect only
in one stop-start round. In the following stop-start round, the
preceding operations do not take effect anymore. However, only
the ethdev queue state is updated, causing the testpmd and ethdev
state information to diverge and causing unexpected side effects
as above problem.

There was a similar problem for the secondary process, please see
commit 5028f207a4fa ("app/testpmd: fix secondary process packet
forwarding").

This patch applies its workaround with some difference to the
primary process. Not all PMDs implement rte_eth_rx_queue_info_get and
rte_eth_tx_queue_info_get, however they may support deferred_start
with primary process. To not break their behavior, retain the original
testpmd local queue state for those PMDs.

Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
Cc: sta...@dpdk.org

Signed-off-by: Jie Hai 
---


Hi Jie,

I see the error below when starting a representor port after reattaching it 
with this patch, is it expected?

$ sudo ./build /app/dpdk-testpmd -n 4  -a :08:00.0,dv_esw_en=1,representor=vf0-1  -a 
auxiliary: -a 00:00.0 --iova-mode="va" -- -i
[..]
testpmd> port stop all
testpmd> port close 0
testpmd> device detach :08:00.0
testpmd> port attach :08:00.0,dv_esw_en=1,representor=0-1
testpmd> port start 1
Configuring Port 1 (socket 0)
Port 1: FA:9E:D8:5F:D7:D8
Invalid Rx queue_id=0
testpmd: Failed to get rx queue info
Invalid Tx queue_id=0
testpmd: Failed to get tx queue info

Regards,
Ali

Hi Ali,
Thanks for your feedback.

When update_queue_state is called, the status of all queues on all ports 
are updated.
The number of queues is nb_rxq|nb_txq which is stored locally by testpmd 
process.

All ports on the same process shares the same nb_rxq|nb_txq.

After detached and attached, the number of queues of port 0 is 0.
And it changes only when the port is reconfigured by testpmd,
which is when port 0 is started.

If we start port 1 first, update_queue_state will update nb_rxq|nb_txq
queues state of port 0, and that's invalid because there's zero queues.

If this patch is not applied, the same problem occurs when the secondary 
process detaches and attaches the port, and then starts the port in the 
multi-process scenario.


I will submit a patch to fix this problem. When port starts, update 
queue state based on the number of queues reported by the driver.


Thanks,
Jie Hai

RE: [EXT] [PATCH v8] app/dma-perf: introduce dma-perf application

[Jiang, Cheng1]

Hi Anoob,

Replies are inline.

Thanks,
Cheng

> -Original Message-
> From: Anoob Joseph 
> Sent: Monday, June 26, 2023 1:42 PM
> To: Jiang, Cheng1 ; tho...@monjalon.net;
> Richardson, Bruce ;
> m...@smartsharesystems.com; Xia, Chenbo ; Amit
> Prakash Shukla ; huangdeng...@huawei.com;
> Laatz, Kevin ; fengcheng...@huawei.com; Jerin
> Jacob Kollanukkaran 
> Cc: dev@dpdk.org; Hu, Jiayu ; Ding, Xuan
> ; Ma, WenwuX ; Wang,
> YuanX ; He, Xingguang ;
> Ling, WeiX 
> Subject: RE: [EXT] [PATCH v8] app/dma-perf: introduce dma-perf application
> 
> Hi Cheng,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -Original Message-
> > From: Jiang, Cheng1 
> > Sent: Saturday, June 24, 2023 5:23 PM
> > To: Anoob Joseph ; tho...@monjalon.net;
> > Richardson, Bruce ;
> > m...@smartsharesystems.com; Xia, Chenbo ; Amit
> > Prakash Shukla ;
> huangdeng...@huawei.com;
> > Laatz, Kevin ; fengcheng...@huawei.com; Jerin
> > Jacob Kollanukkaran 
> > Cc: dev@dpdk.org; Hu, Jiayu ; Ding, Xuan
> > ; Ma, WenwuX ; Wang,
> YuanX
> > ; He, Xingguang ; Ling,
> > WeiX 
> > Subject: RE: [EXT] [PATCH v8] app/dma-perf: introduce dma-perf
> > application
> >
> > Hi Anoob,
> >
> > Replies are inline.
> >
> > Thanks,
> > Cheng
> >
> > > -Original Message-
> > > From: Anoob Joseph 
> > > Sent: Friday, June 23, 2023 2:53 PM
> > > To: Jiang, Cheng1 ; tho...@monjalon.net;
> > > Richardson, Bruce ;
> > > m...@smartsharesystems.com; Xia, Chenbo ;
> Amit
> > > Prakash Shukla ;
> > huangdeng...@huawei.com;
> > > Laatz, Kevin ; fengcheng...@huawei.com; Jerin
> > > Jacob Kollanukkaran 
> > > Cc: dev@dpdk.org; Hu, Jiayu ; Ding, Xuan
> > > ; Ma, WenwuX ; Wang,
> > YuanX
> > > ; He, Xingguang ;
> > Ling,
> > > WeiX 
> > > Subject: RE: [EXT] [PATCH v8] app/dma-perf: introduce dma-perf
> > > application
> > >
> > > Hi Cheng,
> > >
> > > Thanks for the new version. Please see inline.
> > >
> > > Thanks,
> > > Anoob
> > >
> > > > -Original Message-
> > > > From: Cheng Jiang 
> > > > Sent: Tuesday, June 20, 2023 12:24 PM
> > > > To: tho...@monjalon.net; bruce.richard...@intel.com;
> > > > m...@smartsharesystems.com; chenbo@intel.com; Amit Prakash
> > Shukla
> > > > ; Anoob Joseph ;
> > > > huangdeng...@huawei.com; kevin.la...@intel.com;
> > > > fengcheng...@huawei.com; Jerin Jacob Kollanukkaran
> > > > 
> > > > Cc: dev@dpdk.org; jiayu...@intel.com; xuan.d...@intel.com;
> > > > wenwux...@intel.com; yuanx.w...@intel.com;
> > xingguang...@intel.com;
> > > > weix.l...@intel.com; Cheng Jiang 
> > > > Subject: [EXT] [PATCH v8] app/dma-perf: introduce dma-perf
> > > > application
> > > >
> > > > External Email
> > > >
> > > > --
> > > > --
> > > > -- There are many high-performance DMA devices supported in DPDK
> > > > now,
> > > and
> > > > these DMA devices can also be integrated into other modules of
> > > > DPDK as accelerators, such as Vhost. Before integrating DMA into
> > > > applications, developers need to know the performance of these DMA
> > > > devices in various scenarios and the performance of CPUs in the
> > > > same scenario, such as different buffer lengths. Only in this way
> > > > can we know the target performance of the application accelerated
> > > > by using them. This patch introduces a high-performance testing
> > > > tool, which supports comparing the performance of CPU and DMA in
> > > > different scenarios automatically with a pre- set config file.
> > > > Memory Copy performance test
> > > are supported for now.
> > > >
> > > > Signed-off-by: Cheng Jiang 
> > > > Signed-off-by: Jiayu Hu 
> > > > Signed-off-by: Yuan Wang 
> > > > Acked-by: Morten Brørup 
> > > > Acked-by: Chenbo Xia 
> > > > ---
> > > > v8:
> > > >   fixed string copy issue in parse_lcore();
> > > >   improved some data display format;
> > > >   added doc in doc/guides/tools;
> > > >   updated release notes;
> > > >
> > > > v7:
> > > >   fixed some strcpy issues;
> > > >   removed cache setup in calling rte_pktmbuf_pool_create();
> > > >   fixed some typos;
> > > >   added some memory free and null set operations;
> > > >   improved result calculation;
> > > > v6:
> > > >   improved code based on Anoob's comments;
> > > >   fixed some code structure issues;
> > > > v5:
> > > >   fixed some LONG_LINE warnings;
> > > > v4:
> > > >   fixed inaccuracy of the memory footprint display;
> > > > v3:
> > > >   fixed some typos;
> > > > v2:
> > > >   added lcore/dmadev designation;
> > > >   added error case process;
> > > >   removed worker_threads parameter from config.ini;
> > > >   improved the logs;
> > > >   improved config file;
> > > >
> > > >  app/meson.build|   1 +
> > > >  app/test-dma-perf/benchmark.c  | 498 +
> > > >  app/test-dma-perf/config.ini   |  61 +++
> > > >  app/test-dma-perf/main.c   | 594 +
> > > >  app/test-dma-perf/main.h   |  69 +++
> > > >  app/test-dma-p

Re: [PATCH] crypto/openssl: do not build useless workaround

[Thomas Monjalon]

26/06/2023 11:13, Didier Pallard:
> HI,
> not sure to understand how it is possible.
> If build  OPENSSL_VERSION_NUMBER <  0x1010L, linker should link binary
> with libcrypto.so.1.0.0.
> libcrypto.so.1.1 if build for 0x1010L and libcrypto.so.3 for
> 0x3000L
> loader should not allow to link with a library different from the one used
> at build time, no?

You are probably right.
libcrypto.so.1.1 and libcrypto.so.1.0 are incompatible versions?
If we are linking against libcrypto.so.1.1 and you did exactly
a check for lower than libcrypto.so.1.1, then it should be OK.


> On Sun, Jun 25, 2023 at 9:22 PM Thomas Monjalon  wrote:
> 
> > 18/04/2023 16:56, Didier Pallard:
> > > This workaround was needed before version 1.0.1f. Do not build it for
> > > versions >= 1.1.
> > >
> > > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
> > > Signed-off-by: Didier Pallard 
> > > Cc: sta...@dpdk.org
> > [...]
> > > +#if OPENSSL_VERSION_NUMBER < 0x1010L
> > >   /* Workaround open ssl bug in version less then 1.0.1f */
> > >   if (EVP_EncryptUpdate(ctx, empty, &unused, empty, 0) <= 0)
> > >   goto process_auth_encryption_gcm_err;
> > > +#endif
> >
> > What happens if we build with OpenSSL 1.1 and run with OpenSSL 1.0?
> > Can we have a runtime check?
> > Or is it better doing the workaround always as before?

[PATCH v9] app/dma-perf: introduce dma-perf application

[Cheng Jiang]

There are many high-performance DMA devices supported in DPDK now, and
these DMA devices can also be integrated into other modules of DPDK as
accelerators, such as Vhost. Before integrating DMA into applications,
developers need to know the performance of these DMA devices in various
scenarios and the performance of CPUs in the same scenario, such as
different buffer lengths. Only in this way can we know the target
performance of the application accelerated by using them. This patch
introduces a high-performance testing tool, which supports comparing the
performance of CPU and DMA in different scenarios automatically with a
pre-set config file. Memory Copy performance test are supported for now.

Signed-off-by: Cheng Jiang 
Signed-off-by: Jiayu Hu 
Signed-off-by: Yuan Wang 
Acked-by: Morten Brørup 
Acked-by: Chenbo Xia 
---
v9:
  improved error handling;
  improved lcore_params structure;
  improved mbuf api calling;
  improved exit process;
  fixed some typos;
  added scenario summary data display;
  removed unnecessary include;
v8:
  fixed string copy issue in parse_lcore();
  improved some data display format;
  added doc in doc/guides/tools;
  updated release notes;
v7:
  fixed some strcpy issues;
  removed cache setup in calling rte_pktmbuf_pool_create();
  fixed some typos;
  added some memory free and null set operations;
  improved result calculation;
v6:
  improved code based on Anoob's comments;
  fixed some code structure issues;
v5:
  fixed some LONG_LINE warnings;
v4:
  fixed inaccuracy of the memory footprint display;
v3:
  fixed some typos;
v2:
  added lcore/dmadev designation;
  added error case process;
  removed worker_threads parameter from config.ini;
  improved the logs;
  improved config file;

 app/meson.build|   1 +
 app/test-dma-perf/benchmark.c  | 508 
 app/test-dma-perf/config.ini   |  61 +++
 app/test-dma-perf/main.c   | 616 +
 app/test-dma-perf/main.h   |  64 +++
 app/test-dma-perf/meson.build  |  17 +
 doc/guides/rel_notes/release_23_07.rst |   6 +
 doc/guides/tools/dmaperf.rst   | 103 +
 doc/guides/tools/index.rst |   1 +
 9 files changed, 1377 insertions(+)
 create mode 100644 app/test-dma-perf/benchmark.c
 create mode 100644 app/test-dma-perf/config.ini
 create mode 100644 app/test-dma-perf/main.c
 create mode 100644 app/test-dma-perf/main.h
 create mode 100644 app/test-dma-perf/meson.build
 create mode 100644 doc/guides/tools/dmaperf.rst

diff --git a/app/meson.build b/app/meson.build
index 74d2420f67..4fc1a83eba 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -19,6 +19,7 @@ apps = [
 'test-cmdline',
 'test-compress-perf',
 'test-crypto-perf',
+'test-dma-perf',
 'test-eventdev',
 'test-fib',
 'test-flow-perf',
diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
new file mode 100644
index 00..0601e0d171
--- /dev/null
+++ b/app/test-dma-perf/benchmark.c
@@ -0,0 +1,508 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "main.h"
+
+#define MAX_DMA_CPL_NB 255
+
+#define TEST_WAIT_U_SECOND 1
+#define POLL_MAX 1000
+
+#define CSV_LINE_DMA_FMT "Scenario %u,%u,%s,%u,%u,%u,%u,%.2lf,%" PRIu64 
",%.3lf,%.3lf\n"
+#define CSV_LINE_CPU_FMT "Scenario %u,%u,NA,NA,NA,%u,%u,%.2lf,%" PRIu64 
",%.3lf,%.3lf\n"
+
+#define CSV_TOTAL_LINE_FMT "Scenario %u Summary, , , , , 
,%u,%.2lf,%u,%.3lf,%.3lf\n"
+
+struct worker_info {
+   bool ready_flag;
+   bool start_flag;
+   bool stop_flag;
+   uint32_t total_cpl;
+   uint32_t test_cpl;
+};
+
+struct lcore_params {
+   uint8_t scenario_id;
+   unsigned int lcore_id;
+   char *dma_name;
+   uint16_t worker_id;
+   uint16_t dev_id;
+   uint32_t nr_buf;
+   uint16_t kick_batch;
+   uint32_t buf_size;
+   uint16_t test_secs;
+   struct rte_mbuf **srcs;
+   struct rte_mbuf **dsts;
+   volatile struct worker_info worker_info;
+};
+
+static struct rte_mempool *src_pool;
+static struct rte_mempool *dst_pool;
+
+static struct lcore_params *lcores[MAX_WORKER_NB];
+
+#define PRINT_ERR(...) print_err(__func__, __LINE__, __VA_ARGS__)
+
+static inline int
+__rte_format_printf(3, 4)
+print_err(const char *func, int lineno, const char *format, ...)
+{
+   va_list ap;
+   int ret;
+
+   ret = fprintf(stderr, "In %s:%d - ", func, lineno);
+   va_start(ap, format);
+   ret += vfprintf(stderr, format, ap);
+   va_end(ap);
+
+   return ret;
+}
+
+static inline void
+calc_result(uint32_t buf_size, uint32_t nr_buf, uint16_t nb_workers, uint16_t 
test_secs,
+   uint32_t total_cnt, float *memory, uint32_t 
*ave_cycle,
+   float *bandwidth, float

Re: DPDK22 issue: Unable to set more than 4 queues in Azure

[Nageswara Rao]

Yes, we are using vdev_netvsc. Native netvsc PMD we are observing issues in
enabling multiple queues.
Though we have 6 DPDK cores, unable to configure more than 4 queues.

On Mon, Jun 26, 2023 at 12:18 AM Stephen Hemminger <
step...@networkplumber.org> wrote:

> On Thu, 22 Jun 2023 22:06:10 +0530
> Nageswara Rao  wrote:
>
> > Hi All,
> >
> > We are observing the following issue with DPDK22.11. We didn’t find any
> > upstream patches for this issue on the DPDK github. Is there any known
> > issue, please let us know.
> >
> >
> >
> > *Issue:*
> >
> > On Azure platform, we are unable to configure more than 4 queues. When we
> > try to configure more than 4 queues its failing with “EAL: Cannot send
> more
> > than 8 FDs” error.
> >
> > Here I am pasting the working and failing testpmd logs.
> >
> > Please note that this issue is not observed in DPDK 21.11.
> >
>
> You should be using the native netvsc PMD, not the
> vdev_netvsc,failsafe,tap kludge.
>
> I don't work on Azure any more but I suspect the issue is that the default
> in the kernel for TAP is for the number of queues == number of cores.
>
> You aren't going to see any real benefit from having more queues than
> the number of DPDK cores.
>
>

[PATCH] devtools: fix mailmap check for parentheses

[Thomas Monjalon]

When checking names having parentheses, the grep matching was failing.
It is fixed by escaping the open parenthesis.

Also, the mailmap path was relative to the root directory.
The path is made absolute.

Fixes: e83d41f0694d ("mailmap: add list of contributors")
Fixes: 83812de4f2f3 ("devtools: move mailmap check after patch applied")
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
 devtools/check-git-log.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
index af751e49ab..89544a2cc5 100755
--- a/devtools/check-git-log.sh
+++ b/devtools/check-git-log.sh
@@ -264,8 +264,10 @@ names=$(git log --format='From: %an <%ae>%n%b' --reverse 
$range |
sed -rn 's,.*: (.*<.*@.*>),\1,p' |
sort -u)
 bad=$(for contributor in $names ; do
+   contributor=${contributor//(/\\(}
! grep -qE "^$contributor($| <)" $selfdir/../.mailmap || continue
-   if grep -q "^${contributor%% <*} <" .mailmap ; then
+   name=${contributor%% <*}
+   if grep -q "^$name <" $selfdir/../.mailmap ; then
printf "\t$contributor is not the primary email address\n"
else
printf "\t$contributor is unknown in .mailmap\n"
-- 
2.41.0

Re: [PATCH] crypto/openssl: do not build useless workaround

[Didier Pallard]

On Mon, Jun 26, 2023 at 12:04 PM Thomas Monjalon 
wrote:

> 26/06/2023 11:13, Didier Pallard:
> > HI,
> > not sure to understand how it is possible.
> > If build  OPENSSL_VERSION_NUMBER <  0x1010L, linker should link
> binary
> > with libcrypto.so.1.0.0.
> > libcrypto.so.1.1 if build for 0x1010L and libcrypto.so.3 for
> > 0x3000L
> > loader should not allow to link with a library different from the one
> used
> > at build time, no?
>
> You are probably right.
> libcrypto.so.1.1 and libcrypto.so.1.0 are incompatible versions?
>
I think so. Can someone else confirm?


> If we are linking against libcrypto.so.1.1 and you did exactly
> a check for lower than libcrypto.so.1.1, then it should be OK.
>
>
> > On Sun, Jun 25, 2023 at 9:22 PM Thomas Monjalon 
> wrote:
> >
> > > 18/04/2023 16:56, Didier Pallard:
> > > > This workaround was needed before version 1.0.1f. Do not build it for
> > > > versions >= 1.1.
> > > >
> > > > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL
> library")
> > > > Signed-off-by: Didier Pallard 
> > > > Cc: sta...@dpdk.org
> > > [...]
> > > > +#if OPENSSL_VERSION_NUMBER < 0x1010L
> > > >   /* Workaround open ssl bug in version less then 1.0.1f */
> > > >   if (EVP_EncryptUpdate(ctx, empty, &unused, empty, 0) <= 0)
> > > >   goto process_auth_encryption_gcm_err;
> > > > +#endif
> > >
> > > What happens if we build with OpenSSL 1.1 and run with OpenSSL 1.0?
> > > Can we have a runtime check?
> > > Or is it better doing the workaround always as before?
>
>
>
>

[PATCH] bus/cdx: provide driver flag for optional resource mapping

[Abhijit Gangurde]

Provide driver flag which gives an option to map the cdx
device resource before probing the device driver.
Also, make rte_cdx_map_device() API as public to map
device resource separately.

Signed-off-by: Abhijit Gangurde 
---
 drivers/bus/cdx/bus_cdx_driver.h | 26 ++---
 drivers/bus/cdx/cdx.c| 11 ---
 drivers/bus/cdx/rte_bus_cdx.h| 50 
 drivers/bus/cdx/version.map  | 11 +--
 4 files changed, 69 insertions(+), 29 deletions(-)
 create mode 100644 drivers/bus/cdx/rte_bus_cdx.h

diff --git a/drivers/bus/cdx/bus_cdx_driver.h b/drivers/bus/cdx/bus_cdx_driver.h
index fcacdb5896..1571131417 100644
--- a/drivers/bus/cdx/bus_cdx_driver.h
+++ b/drivers/bus/cdx/bus_cdx_driver.h
@@ -37,6 +37,9 @@ struct rte_cdx_bus;
 static const char DRV_EXP_TAG(name, cdx_tbl_export)[] __rte_used = \
 RTE_STR(table)
 
+/** Device needs resource mapping */
+#define RTE_CDX_DRV_NEED_MAPPING 0x0001
+
 /**
  * A structure describing an ID for a CDX driver. Each driver provides a
  * table of these IDs for each device that it supports.
@@ -107,29 +110,6 @@ struct rte_cdx_driver {
uint32_t drv_flags; /**< Flags RTE_CDX_DRV_*. */
 };
 
-/**
- * Map the CDX device resources in user space virtual memory address.
- *
- * @param dev
- *   A pointer to a rte_cdx_device structure describing the device
- *   to use.
- *
- * @return
- *   0 on success, <0 on error.
- */
-__rte_internal
-int rte_cdx_map_device(struct rte_cdx_device *dev);
-
-/**
- * Unmap this device.
- *
- * @param dev
- *   A pointer to a rte_cdx_device structure describing the device
- *   to use.
- */
-__rte_internal
-void rte_cdx_unmap_device(struct rte_cdx_device *dev);
-
 /**
  * Register a CDX driver.
  *
diff --git a/drivers/bus/cdx/cdx.c b/drivers/bus/cdx/cdx.c
index 28bbf92ed5..47dc4eabe7 100644
--- a/drivers/bus/cdx/cdx.c
+++ b/drivers/bus/cdx/cdx.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -380,10 +381,12 @@ cdx_probe_one_driver(struct rte_cdx_driver *dr,
CDX_BUS_DEBUG("  probe device %s using driver: %s", dev_name,
dr->driver.name);
 
-   ret = cdx_vfio_map_resource(dev);
-   if (ret != 0) {
-   CDX_BUS_ERR("CDX map device failed: %d", ret);
-   goto error_map_device;
+   if (dr->drv_flags & RTE_CDX_DRV_NEED_MAPPING) {
+   ret = cdx_vfio_map_resource(dev);
+   if (ret != 0) {
+   CDX_BUS_ERR("CDX map device failed: %d", ret);
+   goto error_map_device;
+   }
}
 
/* call the driver probe() function */
diff --git a/drivers/bus/cdx/rte_bus_cdx.h b/drivers/bus/cdx/rte_bus_cdx.h
new file mode 100644
index 00..b9280b5f7f
--- /dev/null
+++ b/drivers/bus/cdx/rte_bus_cdx.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (C) 2023, Advanced Micro Devices, Inc.
+ */
+
+#ifndef _RTE_BUS_CDX_H_
+#define _RTE_BUS_CDX_H_
+
+/**
+ * @file
+ * CDX device & driver interface
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Forward declarations */
+struct rte_cdx_device;
+
+/**
+ * Map the CDX device resources in user space virtual memory address
+ *
+ * Note that driver should not call this function when flag
+ * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
+ * you when it's on.
+ *
+ * @param dev
+ *   A pointer to a rte_cdx_device structure describing the device
+ *   to use
+ *
+ * @return
+ *   0 on success, negative on error and positive if no driver
+ *   is found for the device.
+ */
+int rte_cdx_map_device(struct rte_cdx_device *dev);
+
+/**
+ * Unmap this device
+ *
+ * @param dev
+ *   A pointer to a rte_cdx_device structure describing the device
+ *   to use
+ */
+void rte_cdx_unmap_device(struct rte_cdx_device *dev);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_BUS_CDX_H_ */
diff --git a/drivers/bus/cdx/version.map b/drivers/bus/cdx/version.map
index 0a15d39ae8..cc7b1f821b 100644
--- a/drivers/bus/cdx/version.map
+++ b/drivers/bus/cdx/version.map
@@ -1,9 +1,16 @@
-INTERNAL {
+DPDK_23 {
global:
 
rte_cdx_map_device;
-   rte_cdx_register;
rte_cdx_unmap_device;
+
+   local: *;
+};
+
+INTERNAL {
+   global:
+
+   rte_cdx_register;
rte_cdx_unregister;
rte_cdx_vfio_intr_disable;
rte_cdx_vfio_intr_enable;
-- 
2.25.1

[PATCH] app/testpmd: add trace dump command

[Viacheslav Ovsiienko]

The "dump_trace" CLI command is added to trigger
saving the trace dumps to the trace directory.

The tracing data are saved according to the EAL configuration
(explicit --trace-dir EAL command line parameter alters
the target folder to save). The result dump folder gets the name
like rte--MM-DD-xx-HH-MM-SS format.

This command is useful to get the trace date without exiting
testpmd application and to get the multiple dumps to observe
the situation in dynamics.

Signed-off-by: Viacheslav Ovsiienko 
---
 app/test-pmd/cmdline.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c6690887d3..70b598c64e 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8372,6 +8372,8 @@ static void cmd_dump_parsed(void *parsed_result,
rte_lcore_dump(stdout);
else if (!strcmp(res->dump, "dump_log_types"))
rte_log_dump(stdout);
+   else if (!strcmp(res->dump, "dump_trace"))
+   rte_trace_save();
 }
 
 static cmdline_parse_token_string_t cmd_dump_dump =
@@ -8384,7 +8386,8 @@ static cmdline_parse_token_string_t cmd_dump_dump =
"dump_mempool#"
"dump_devargs#"
"dump_lcores#"
-   "dump_log_types");
+   "dump_log_types#"
+   "dump_trace");
 
 static cmdline_parse_inst_t cmd_dump = {
.f = cmd_dump_parsed,  /* function to call */
-- 
2.18.1

[PATCH v3] app/testpmd: add trace dump command

[Viacheslav Ovsiienko]

The "dump_trace" CLI command is added to trigger
saving the trace dumps to the trace directory.

The tracing data are saved according to the EAL configuration
(explicit --trace-dir EAL command line parameter alters
the target folder to save). The result dump folder gets the name
like rte--MM-DD-xx-HH-MM-SS format.

This command is useful to get the trace date without exiting
testpmd application and to get the multiple dumps to observe
the situation in dynamics.

Signed-off-by: Viacheslav Ovsiienko 
---
 app/test-pmd/cmdline.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c6690887d3..70b598c64e 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8372,6 +8372,8 @@ static void cmd_dump_parsed(void *parsed_result,
rte_lcore_dump(stdout);
else if (!strcmp(res->dump, "dump_log_types"))
rte_log_dump(stdout);
+   else if (!strcmp(res->dump, "dump_trace"))
+   rte_trace_save();
 }
 
 static cmdline_parse_token_string_t cmd_dump_dump =
@@ -8384,7 +8386,8 @@ static cmdline_parse_token_string_t cmd_dump_dump =
"dump_mempool#"
"dump_devargs#"
"dump_lcores#"
-   "dump_log_types");
+   "dump_log_types#"
+   "dump_trace");
 
 static cmdline_parse_inst_t cmd_dump = {
.f = cmd_dump_parsed,  /* function to call */
-- 
2.18.1

[PATCH v3] common/qat: fix detach QAT crypto compress build

[Vikash Poddar]

qat_qp.c is a common file for QAT crypto and
compress. Moved compress function from common
file to compress QAT file qat_comp.c

Bugzilla ID: 1237
Fixes: 2ca75c65af4c ("common/qat: build drivers from common folder")
Cc: bruce.richard...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Vikash Poddar 
---
v3:
Fixed commit message
v2:
Fixed coding style issue
---
 drivers/common/qat/meson.build  |   8 --
 drivers/common/qat/qat_qp.c | 187 
 drivers/common/qat/qat_qp.h |  20 +++-
 drivers/compress/qat/qat_comp.c | 182 +++
 drivers/compress/qat/qat_comp.h |   3 +
 5 files changed, 201 insertions(+), 199 deletions(-)

diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build
index b84e5b3c6c..95b52b78c3 100644
--- a/drivers/common/qat/meson.build
+++ b/drivers/common/qat/meson.build
@@ -54,14 +54,6 @@ if libipsecmb.found() and libcrypto_3.found()
 endif
 endif
 
-# The driver should not build if both compression and crypto are disabled
-#FIXME common code depends on compression files so check only compress!
-if not qat_compress # and not qat_crypto
-build = false
-reason = '' # rely on reason for compress/crypto above
-subdir_done()
-endif
-
 deps += ['bus_pci', 'cryptodev', 'net', 'compressdev']
 sources += files(
 'qat_common.c',
diff --git a/drivers/common/qat/qat_qp.c b/drivers/common/qat/qat_qp.c
index 348a1d574d..197e8bac75 100644
--- a/drivers/common/qat/qat_qp.c
+++ b/drivers/common/qat/qat_qp.c
@@ -490,20 +490,6 @@ adf_configure_queues(struct qat_qp *qp, enum 
qat_device_gen qat_dev_gen)
return 0;
 }
 
-static inline void
-txq_write_tail(enum qat_device_gen qat_dev_gen,
-   struct qat_qp *qp, struct qat_queue *q)
-{
-   struct qat_qp_hw_spec_funcs *ops =
-   qat_qp_hw_spec[qat_dev_gen];
-
-   /*
-* Pointer check should be done during
-* initialization
-*/
-   ops->qat_qp_csr_write_tail(qp, q);
-}
-
 static inline void
 qat_qp_csr_write_head(enum qat_device_gen qat_dev_gen, struct qat_qp *qp,
struct qat_queue *q, uint32_t new_head)
@@ -672,179 +658,6 @@ qat_enqueue_op_burst(void *qp, qat_op_build_request_t 
op_build_request,
return nb_ops_sent;
 }
 
-/* Use this for compression only - but keep consistent with above common
- * function as much as possible.
- */
-uint16_t
-qat_enqueue_comp_op_burst(void *qp, void **ops, uint16_t nb_ops)
-{
-   register struct qat_queue *queue;
-   struct qat_qp *tmp_qp = (struct qat_qp *)qp;
-   register uint32_t nb_ops_sent = 0;
-   register int nb_desc_to_build;
-   uint16_t nb_ops_possible = nb_ops;
-   register uint8_t *base_addr;
-   register uint32_t tail;
-
-   int descriptors_built, total_descriptors_built = 0;
-   int nb_remaining_descriptors;
-   int overflow = 0;
-
-   if (unlikely(nb_ops == 0))
-   return 0;
-
-   /* read params used a lot in main loop into registers */
-   queue = &(tmp_qp->tx_q);
-   base_addr = (uint8_t *)queue->base_addr;
-   tail = queue->tail;
-
-   /* Find how many can actually fit on the ring */
-   {
-   /* dequeued can only be written by one thread, but it may not
-* be this thread. As it's 4-byte aligned it will be read
-* atomically here by any Intel CPU.
-* enqueued can wrap before dequeued, but cannot
-* lap it as var size of enq/deq (uint32_t) > var size of
-* max_inflights (uint16_t). In reality inflights is never
-* even as big as max uint16_t, as it's <= ADF_MAX_DESC.
-* On wrapping, the calculation still returns the correct
-* positive value as all three vars are unsigned.
-*/
-   uint32_t inflights =
-   tmp_qp->enqueued - tmp_qp->dequeued;
-
-   /* Find how many can actually fit on the ring */
-   overflow = (inflights + nb_ops) - tmp_qp->max_inflights;
-   if (overflow > 0) {
-   nb_ops_possible = nb_ops - overflow;
-   if (nb_ops_possible == 0)
-   return 0;
-   }
-
-   /* QAT has plenty of work queued already, so don't waste cycles
-* enqueueing, wait til the application has gathered a bigger
-* burst or some completed ops have been dequeued
-*/
-   if (tmp_qp->min_enq_burst_threshold && inflights >
-   QAT_QP_MIN_INFL_THRESHOLD && nb_ops_possible <
-   tmp_qp->min_enq_burst_threshold) {
-   tmp_qp->stats.threshold_hit_count++;
-   return 0;
-   }
-   }
-
-   /* At this point nb_ops_possible is assuming a 1:1 mapping
-* between ops and descriptors.

[PATCH v4] app/testpmd: add trace dump command

[Viacheslav Ovsiienko]

The "dump_trace" CLI command is added to trigger
saving the trace dumps to the trace directory.

The tracing data are saved according to the EAL configuration
(explicit --trace-dir EAL command line parameter alters
the target folder to save). The result dump folder gets the name
like rte--MM-DD-xx-HH-MM-SS format.

This command is useful to get the trace date without exiting
testpmd application and to get the multiple dumps to observe
the situation in dynamics.

Signed-off-by: Viacheslav Ovsiienko 

--

v1: https://inbox.dpdk.org/dev/20230609152847.32496-2-viachesl...@nvidia.com
v2: https://inbox.dpdk.org/dev/20230613165845.19109-2-viachesl...@nvidia.com
- changed to save_trace command
- Windows compilation check added

v3: https://inbox.dpdk.org/dev/20230626110734.14126-1-viachesl...@nvidia.com
- reverted to "dump_trace" command

v4: - added missed header file include
- missed #ifdef added for Windows compilation (no trace support
  for Windows)
---
 app/test-pmd/cmdline.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5da38b0bb4..b82763c65d 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -39,6 +39,7 @@
 #include 
 #endif
 #include 
+#include 
 
 #include 
 #include 
@@ -8371,10 +8372,17 @@ static void cmd_dump_parsed(void *parsed_result,
rte_lcore_dump(stdout);
else if (!strcmp(res->dump, "dump_log_types"))
rte_log_dump(stdout);
+#ifndef RTE_EXEC_ENV_WINDOWS
+   else if (!strcmp(res->dump, "dump_trace"))
+   rte_trace_save();
+#endif 
 }
 
 static cmdline_parse_token_string_t cmd_dump_dump =
TOKEN_STRING_INITIALIZER(struct cmd_dump_result, dump,
+#ifndef RTE_EXEC_ENV_WINDOWS
+   "dump_trace#"
+#endif
"dump_physmem#"
"dump_memzone#"
"dump_socket_mem#"
-- 
2.18.1

[PATCH] config/arm: add HiSilicon hip10

[Dongdong Liu]

Adding support for HiSilicon hip10 platform.

Signed-off-by: Dongdong Liu 
---
 config/arm/arm64_hip10_linux_gcc | 16 
 config/arm/meson.build   | 19 +++
 2 files changed, 35 insertions(+)
 create mode 100644 config/arm/arm64_hip10_linux_gcc

diff --git a/config/arm/arm64_hip10_linux_gcc b/config/arm/arm64_hip10_linux_gcc
new file mode 100644
index 00..2943e4abbf
--- /dev/null
+++ b/config/arm/arm64_hip10_linux_gcc
@@ -0,0 +1,16 @@
+[binaries]
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-g++']
+ar = 'aarch64-linux-gnu-gcc-ar'
+strip = 'aarch64-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+pcap-config = ''
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv8-a'
+endian = 'little'
+
+[properties]
+platform = 'hip10'
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 535c8b4946..58e84abf2e 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -206,6 +206,16 @@ implementer_hisilicon = {
 ['RTE_MAX_LCORE', 1280],
 ['RTE_MAX_NUMA_NODES', 16]
 ]
+},
+'0xd03': {
+'march': 'armv8.5-a',
+'march_features': ['crypto', 'sve'],
+'flags': [
+['RTE_MACHINE', '"hip10"'],
+['RTE_ARM_FEATURE_ATOMICS', true],
+['RTE_MAX_LCORE', 1280],
+['RTE_MAX_NUMA_NODES', 16]
+]
 }
 }
 }
@@ -389,6 +399,13 @@ soc_kunpeng930 = {
 'numa': true
 }
 
+soc_hip10 = {
+'description': 'HiSilicon HIP10',
+'implementer': '0x48',
+'part_number': '0xd03',
+'numa': true
+}
+
 soc_n1sdp = {
 'description': 'Arm Neoverse N1SDP',
 'implementer': '0x41',
@@ -472,6 +489,7 @@ ft2000plus:  Phytium FT-2000+
 tys2500: Phytium TengYun S2500
 graviton2:   AWS Graviton2
 graviton3:   AWS Graviton3
+hip10:   HiSilicon HIP10
 kunpeng920:  HiSilicon Kunpeng 920
 kunpeng930:  HiSilicon Kunpeng 930
 n1sdp:   Arm Neoverse N1SDP
@@ -499,6 +517,7 @@ socs = {
 'tys2500': soc_tys2500,
 'graviton2': soc_graviton2,
 'graviton3': soc_graviton3,
+'hip10': soc_hip10,
 'kunpeng920': soc_kunpeng920,
 'kunpeng930': soc_kunpeng930,
 'n1sdp': soc_n1sdp,
-- 
2.22.0

[PATCH 2/2] net/hns3: add FDIR VLAN match mode runtime config

[Dongdong Liu]

From: Huisong Li 

The VLAN number in FDIR meta data is used to enable that hardware
bases on VLAN number to strictly match the input flow. And it is
enabled by default.

For the following two rules:
rule0:
  pattern: eth type is 0x0806
  actions: queue index 3
rule1:
  pattern: eth type is 0x0806 / vlan vid is 20
  actions: queue index 4
If enable VLAN number, only the ARP packets with VLAN 20 are directed
to queue 4, and the ARP packets with other VLAN ID cannot be directed
to the specified queue. If app want to all ARP (VLAN or no VLAN)
packets to be directed to the specified queue, app has to set many
rules for VLAN packet. In this case, if driver doesn't enable VLAN
number, app just need to set one rule (rule0).

So this patch adds a "fdir_vlan_match_mode" runtime config which only
can be 'strict' or 'nostrict'. And driver still uses 'strict' mode as
the default mode. Please select 'nostrict' mode if you request all same
ethertype packets with and without VLAN to a specified queue.

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 doc/guides/nics/hns3.rst   | 20 +++
 drivers/net/hns3/hns3_common.c | 35 ++
 drivers/net/hns3/hns3_common.h |  2 ++
 drivers/net/hns3/hns3_fdir.c   | 10 +++---
 drivers/net/hns3/hns3_fdir.h   |  8 
 5 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/doc/guides/nics/hns3.rst b/doc/guides/nics/hns3.rst
index 5373ec5a8f..af7265ae51 100644
--- a/doc/guides/nics/hns3.rst
+++ b/doc/guides/nics/hns3.rst
@@ -140,6 +140,26 @@ Runtime Configuration
For example::
-a :7d:00.0,mbx_time_limit_ms=600
 
+- ``fdir_vlan_match_mode`` (default `strict`)
+   Used to select VLAN match mode. This runtime config can be `strict`
+   or `nostrict` and is only valid for PF drives.
+   If driver works on `strict` mode (default mode), hardware does strictly
+   match the input flow base on VLAN number.
+   For the following scenarios with two rules:
+ rule0:
+   pattern: eth type is 0x0806
+   actions: queue index 3
+ rule1:
+   pattern: eth type is 0x0806 / vlan vid is 20
+   actions: queue index 4
+   If application select `strict` mode, only the ARP packets with VLAN
+   20 are directed to queue 4, and the ARP packets with other VLAN ID
+   cannot be directed to the specified queue. If application want to all
+   ARP packets with or without VLAN to be directed to the specified queue,
+   application can select `nostrict` mode and just need to set rule0.
+
+   For example::
+   -a :7d:00.0,fdir_vlan_match_mode=nostrict
 
 Driver compilation and testing
 --
diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index f077ef5057..a11ea686fd 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -238,6 +238,34 @@ hns3_parse_mbx_time_limit(const char *key, const char 
*value, void *extra_args)
return 0;
 }
 
+static int
+hns3_parse_vlan_match_mode(const char *key, const char *value, void *args)
+{
+   uint8_t mode;
+
+   RTE_SET_USED(key);
+
+   if (value == NULL) {
+   PMD_INIT_LOG(WARNING, "no value for key:\"%s\"", key);
+   return -1;
+   }
+
+   if (strcmp(value, "strict") == 0) {
+   mode = HNS3_FDIR_VLAN_STRICT_MATCH;
+   } else if (strcmp(value, "nostrict") == 0) {
+   mode = HNS3_FDIR_VLAN_NOSTRICT_MATCH;
+   } else {
+   PMD_INIT_LOG(WARNING, "invalid value:\"%s\" for key:\"%s\", "
+   "value must be 'strict' or 'nostrict'",
+   value, key);
+   return -1;
+   }
+
+   *(uint8_t *)args = mode;
+
+   return 0;
+}
+
 void
 hns3_parse_devargs(struct rte_eth_dev *dev)
 {
@@ -254,6 +282,8 @@ hns3_parse_devargs(struct rte_eth_dev *dev)
hns->tx_func_hint = HNS3_IO_FUNC_HINT_NONE;
hns->dev_caps_mask = 0;
hns->mbx_time_limit_ms = HNS3_MBX_DEF_TIME_LIMIT_MS;
+   if (!hns->is_vf)
+   hns->pf.fdir.vlan_match_mode = HNS3_FDIR_VLAN_STRICT_MATCH;
 
if (dev->device->devargs == NULL)
return;
@@ -270,6 +300,11 @@ hns3_parse_devargs(struct rte_eth_dev *dev)
   &hns3_parse_dev_caps_mask, &dev_caps_mask);
(void)rte_kvargs_process(kvlist, HNS3_DEVARG_MBX_TIME_LIMIT_MS,
   &hns3_parse_mbx_time_limit, &mbx_time_limit_ms);
+   if (!hns->is_vf)
+   (void)rte_kvargs_process(kvlist,
+HNS3_DEVARG_FDIR_VALN_MATCH_MODE,
+&hns3_parse_vlan_match_mode,
+&hns->pf.fdir.vlan_match_mode);
 
rte_kvargs_free(kvlist);
 
diff --git a/drivers/net/hns3/hns3_common.h b/drivers/net/hns3/hns3_common.h
index 8eaeda26e7..cf9593bd0c 100644
--- a/drivers/net/hns3/hns3_common.h
+++ b/drivers/net/hns3/hns3_common

[PATCH 1/2] net/hns3: delete duplicate macro definition

[Dongdong Liu]

From: Huisong Li 

This patch delete some duplicate macro definitions.

Fixes: a4c7152d0581 ("net/hns3: extract common code to its own file")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_ethdev.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index c58094d87b..c85a6912ad 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -873,13 +873,6 @@ struct hns3_adapter {
struct hns3_ptype_table ptype_tbl __rte_cache_aligned;
 };
 
-#define HNS3_DEVARG_RX_FUNC_HINT   "rx_func_hint"
-#define HNS3_DEVARG_TX_FUNC_HINT   "tx_func_hint"
-
-#define HNS3_DEVARG_DEV_CAPS_MASK  "dev_caps_mask"
-
-#define HNS3_DEVARG_MBX_TIME_LIMIT_MS  "mbx_time_limit_ms"
-
 enum hns3_dev_cap {
HNS3_DEV_SUPPORT_DCB_B,
HNS3_DEV_SUPPORT_COPPER_B,
-- 
2.22.0

[PATCH 0/2] net/hns3: add FDIR VLAN match mode runtime config

[Dongdong Liu]

This patchset contains two patches:
The first one is to delete duplicate macro definition for hns3.
The second one is to add FDIR VLAN match mode runtime config for hns3.

Huisong Li (2):
  net/hns3: delete duplicate macro definition
  net/hns3: add FDIR VLAN match mode runtime config

 doc/guides/nics/hns3.rst   | 20 +++
 drivers/net/hns3/hns3_common.c | 35 ++
 drivers/net/hns3/hns3_common.h |  2 ++
 drivers/net/hns3/hns3_ethdev.h |  7 ---
 drivers/net/hns3/hns3_fdir.c   | 10 +++---
 drivers/net/hns3/hns3_fdir.h   |  8 
 6 files changed, 72 insertions(+), 10 deletions(-)

--
2.22.0

RE: [PATCH v4 0/3] Replace obsolote test cases.

[Power, Ciara]

> -Original Message-
> From: Kusztal, ArkadiuszX 
> Sent: Tuesday 20 June 2023 11:33
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Ji, Kai ; Power, Ciara
> ; Kusztal, ArkadiuszX 
> Subject: [PATCH v4 0/3] Replace obsolote test cases.
> 
> This patchset removes obsolete test cases for RSA, MOD EXP, MOD INV.
> Doing that, new way of handling ut_setup and ut_teardown was proposed.
> Now both behave like constructor/desctuctor in the unit tests.
> It frees particular alghorithm functions from any kind of responsibility to 
> free
> resources for the new functions.
> 
> v2:
> - fixed build problem with non compile-time constant
> v3:
> - rebased
> - left old pwct tests intact
> v4:
> - fixed mailmap mismatch
> - rebased
> 
> Arkadiusz Kusztal (3):
>   app/test: remove obsolete test function
>   app/test: add modexp and modinv functions
>   app/test: add rsa none padding tests
> 
>  app/test/test_cryptodev_asym.c | 775 +---
>  app/test/test_cryptodev_mod_test_vectors.h | 814 +
> app/test/test_cryptodev_rsa_test_vectors.h | 322 
>  3 files changed, 510 insertions(+), 1401 deletions(-)
> 
> --
> 2.25.1

Series-acked-by: Ciara Power 

Re: [PATCH v4 23/34] common/sfc_efx/base: match on conntrack mark in action rules

[Thomas Monjalon]

07/06/2023 15:02, Ivan Malov:
> EF100 match-action engine (MAE) has conntrack assistance
> table. A hit in this table can provide a mark value for
> the following lookup stage, which is action rule lookup.
> 
> Provide support for setting match on conntrack mark.

What happened Ivan? This commit message is not right aligned!
We could accept you drop a space before parentheses if it helps :)

DPDK Summit in Dublin - September 12-13

[Thomas Monjalon]

Hello all,

You probably saw already the CfP for our next DPDK Summit.
In case you missed it, here are the main information:

Date: 12-13 September 2023
City: Dublin, Ireland
Venue: Gibson Hotel

You can propose a talk at 
https://linuxfoundation.smapply.io/prog/dpdk_summit_2023_
CfP deadline: end of June

The goal is to meet in-person, discuss hot topics and share some time all 
together.
Please register as soon as you can so we can plan accordingly.

Details should be on https://events.linuxfoundation.org/dpdk-summit/

See you in Dublin!

Re: [dpdk-dev] [PATCH v7] eal: add manual probing option

[Gaëtan Rivet]

On Wed, Jun 14, 2023, at 21:33, Stephen Hemminger wrote:
> On Thu, 23 Jan 2020 10:58:13 +0100
> Gaetan Rivet  wrote:
>
>> Add a new EAL option enabling manual probing in the EAL.
>> This command line option will configure the EAL so that buses
>> will not trigger their probe step on their own.
>> 
>> Applications are then expected to hotplug devices as they see fit.
>> 
>> Devices declared on the command line by the user (using -w and --vdev),
>> will be probed using the hotplug API, in the order they are declared.
>> 
>> This has the effect of offering a way for users to control probe order
>> of their devices, for drivers requiring it.
>> 
>> Signed-off-by: Gaetan Rivet 
>> Acked-by : Vamsi Attunuru 
>> Tested-by: Vamsi Attunuru 
>> Reviewed-by: Jerin Jacob 
>> ---
>> 
>>  haven't heard many opinions on the matter, please shout if you see an issue
>> with this approach.
>> 
>> @Slava: I have tested rather quickly that it does not break anything,
>> and that it works as intended for basic cases.
>> Can you test it further for your use-case and tell me if it works 
>> fine?
>> 
>> Beyond the obvious difference between both probe mode, something to keep in 
>> mind:
>> while using -w on invalid devices would not block (PCI) bus probing, it will 
>> stop manual
>> probing in its track. All devices need to exist and be valid device IDs.
>> 
>> v2: fixed a few typos, map file (and used Travis to validate).
>> 
>> Slava, are you able to test this patch?
>> 
>> v3: properly fixed the map file (inherited 19.08 instead of 19.05).
>> 
>> Added a function to set the probe manual from the application,
>> without having the user do it from the command line.
>> 
>> Stopped spamming Slava about it, Vamsi was actually the one interested 
>> in it!
>> 
>> Standing issue worth chiming in:
>> 
>>   Currently manual-probe will cut off probing from all buses.
>>   It could be interesting to be able to only cut buses supporting hotplug,
>>   given that they are the one able to probe devices afterward.
>> 
>>   No real use-case for this right now, so leaving as-is. Might be worth
>>   considering in the future.
>> 
>> v4: Rebased on master,
>> Moved implementation in common EAL,
>> Used public API within the EAL to set the option,
>> Made the API experimental
>> 
>> v5: added note in the Getting Started Guide.
>> 
>> v6: Rebased on master
>> 
>> see http://mails.dpdk.org/archives/dev/2020-January/154178.html
>> for reference to this version, linking v7 to v5 thread.
>> 
>> v7: Updated author and SoB.
>> 
>>  doc/guides/linux_gsg/eal_args.include.rst  | 13 ++
>>  doc/guides/rel_notes/release_20_02.rst |  9 
>>  lib/librte_eal/common/eal_common_bus.c |  6 +++
>>  lib/librte_eal/common/eal_common_dev.c | 54 ++
>>  lib/librte_eal/common/eal_common_options.c |  8 
>>  lib/librte_eal/common/eal_internal_cfg.h   |  1 +
>>  lib/librte_eal/common/eal_options.h|  2 +
>>  lib/librte_eal/common/eal_private.h|  9 
>>  lib/librte_eal/common/include/rte_eal.h| 36 +++
>>  lib/librte_eal/rte_eal_version.map |  4 ++
>>  10 files changed, 142 insertions(+)
>
> This patch seems to have been held in limbo for 3 years.
>
> For me, it is ok, but concerned that it opens up a whole scenario of possible
> usages that may not be tested, and probably don't work. Testing all the 
> possible
> combinations of probe ordering is a geometric problem.
>
> So if user submits bug then the response would have to be:
>   Manual probing is an experimental option which may not work.

Hello Stephen,

I am not pushing for this series anymore.
I wrote it to help other people, I guess they used another way since.
If someone needs it, I can take a moment to reanimate it.

I'm still using the PCI bus hack to force manual probing, as well as port 
hotplug to control strict ordering. I guess at this point this is the stable 
way of working with DPDK, instead of a proper documented option.

Best regards,
-- 
Gaetan Rivet

Re: [PATCH] regex/cn9k: remove rule compiler

[Stephen Hemminger]

On Mon, 26 Jun 2023 09:16:32 +0200
Thomas Monjalon  wrote:

> 25/06/2023 22:57, Stephen Hemminger:
> > On Wed, 21 Jun 2023 21:03:00 +0530
> > Jerin Jacob  wrote:
> >   
> > > On Wed, Jun 21, 2023 at 7:36 PM Thomas Monjalon  
> > > wrote:  
> > > >
> > > > Nobody knows how to build the feature.
> > > > When the dependency "rxp_compiler" is found,
> > > > the header file is not available:
> > > >
> > > > drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error:
> > > > rxp-compiler.h: No such file or directory
> > > >
> > > > It seems that it depends on a proprietay library.
> > > 
> > > Yes. it depended on proprietary library owned by NVIDIA now. Not sure
> > > Marvell has rights to publish it "freely available".
> > > In order to avoid forking this library, better option to make this
> > > library as public. Also, it looks like the library itself won't have
> > > proper installation procedures that is the
> > > reason for conflict as documented here in
> > > https://bugs.dpdk.org/show_bug.cgi?id=1232.  
> > 
> > Interesting. Then what about the GPU support which currently requires
> > proprietary NVIDIA CUDA library  
> 
> CUDA can be downloaded.
> It is even packaged in many Linux distributions.

Thanks for the clarification.
So the real issue is not that it needs a proprietary library but it is
that the library is not available without special license. CUDA does require
accepting a free license which may be a problem for some people who have
lawyers who read the fine print.

The policy about dependencies should be made more explicit in the documentation.

Re: DPDK22 issue: Unable to set more than 4 queues in Azure

[Stephen Hemminger]

On Mon, 26 Jun 2023 15:53:12 +0530
Nageswara Rao  wrote:

> Yes, we are using vdev_netvsc. Native netvsc PMD we are observing issues in
> enabling multiple queues.
> Though we have 6 DPDK cores, unable to configure more than 4 queues.

Check with Long who now maintains the netvsc driver.

For tap, check the parameters of the kernel side tap device (with ethtool).
Also, it would help to see full debug log at startup.

Re: DPDK22 issue: Unable to set more than 4 queues in Azure

[Nageswara Rao]

Issue is because of tap_mp_req_on_rxtx() sending msg.num_fds more
than RTE_MP_MAX_FD_NUM fds for queues > 4.
Looks like these tap driver changes are added as part of the below patch
http://patches.dpdk.org/project/dpdk/patch/20220121042944.23929-1-kumaraparames...@gmail.com/


On Mon, Jun 26, 2023 at 3:53 PM Nageswara Rao  wrote:

> Yes, we are using vdev_netvsc. Native netvsc PMD we are observing issues
> in enabling multiple queues.
> Though we have 6 DPDK cores, unable to configure more than 4 queues.
>
> On Mon, Jun 26, 2023 at 12:18 AM Stephen Hemminger <
> step...@networkplumber.org> wrote:
>
>> On Thu, 22 Jun 2023 22:06:10 +0530
>> Nageswara Rao  wrote:
>>
>> > Hi All,
>> >
>> > We are observing the following issue with DPDK22.11. We didn’t find any
>> > upstream patches for this issue on the DPDK github. Is there any known
>> > issue, please let us know.
>> >
>> >
>> >
>> > *Issue:*
>> >
>> > On Azure platform, we are unable to configure more than 4 queues. When
>> we
>> > try to configure more than 4 queues its failing with “EAL: Cannot send
>> more
>> > than 8 FDs” error.
>> >
>> > Here I am pasting the working and failing testpmd logs.
>> >
>> > Please note that this issue is not observed in DPDK 21.11.
>> >
>>
>> You should be using the native netvsc PMD, not the
>> vdev_netvsc,failsafe,tap kludge.
>>
>> I don't work on Azure any more but I suspect the issue is that the default
>> in the kernel for TAP is for the number of queues == number of cores.
>>
>> You aren't going to see any real benefit from having more queues than
>> the number of DPDK cores.
>>
>>

Re: [PATCH] regex/cn9k: remove rule compiler

[Thomas Monjalon]

26/06/2023 18:22, Stephen Hemminger:
> On Mon, 26 Jun 2023 09:16:32 +0200
> Thomas Monjalon  wrote:
> 
> > 25/06/2023 22:57, Stephen Hemminger:
> > > On Wed, 21 Jun 2023 21:03:00 +0530
> > > Jerin Jacob  wrote:
> > >   
> > > > On Wed, Jun 21, 2023 at 7:36 PM Thomas Monjalon  
> > > > wrote:  
> > > > >
> > > > > Nobody knows how to build the feature.
> > > > > When the dependency "rxp_compiler" is found,
> > > > > the header file is not available:
> > > > >
> > > > > drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error:
> > > > > rxp-compiler.h: No such file or directory
> > > > >
> > > > > It seems that it depends on a proprietay library.
> > > > 
> > > > Yes. it depended on proprietary library owned by NVIDIA now. Not sure
> > > > Marvell has rights to publish it "freely available".
> > > > In order to avoid forking this library, better option to make this
> > > > library as public. Also, it looks like the library itself won't have
> > > > proper installation procedures that is the
> > > > reason for conflict as documented here in
> > > > https://bugs.dpdk.org/show_bug.cgi?id=1232.  
> > > 
> > > Interesting. Then what about the GPU support which currently requires
> > > proprietary NVIDIA CUDA library  
> > 
> > CUDA can be downloaded.
> > It is even packaged in many Linux distributions.
> 
> Thanks for the clarification.
> So the real issue is not that it needs a proprietary library but it is
> that the library is not available without special license.

No you don't get it.
The problem is that the dependency must be downloadable on Internet.
CUDA is downloadable.
The dependency for Marvell regex is not available on Internet.

> CUDA does require accepting a free license which may be a problem for some 
> people who have
> lawyers who read the fine print.
> 
> The policy about dependencies should be made more explicit in the 
> documentation.

It could be detailed in the contributing guide.

[Bug 1251] PPC64le: 23.07 RC1 build failed for power10 on RHEL 9.0

[bugzilla]

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

David Christensen (d...@linux.vnet.ibm.com) changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from David Christensen (d...@linux.vnet.ibm.com) ---
GCC bugzilla has been opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110411 to track the issue.

Suggested workaround is to enable "-mno-block-ops-vector-pair" for gcc < 11.4
when building for power10 architecture. (GCC 11.4 enables this option by
default when -mcpu=power10.)


Proposed fix:

diff --git a/config/ppc/meson.build b/config/ppc/meson.build
index 1cba44011f..160b203cb1 100644
--- a/config/ppc/meson.build
+++ b/config/ppc/meson.build
@@ -105,6 +105,14 @@ else
 endif
 endif
 machine_args = ['-mcpu=' + cpu_instruction_set, '-mtune=' +
cpu_instruction_set]
+
+# gcc versions < 11.4 may fail to build for power10, see
https://bugs.dpdk.org/show_bug.cgi?id=1251.
+# Explicitly specify a default used in gcc 11.4 and later to workaround the
issue
+if (cpu_instruction_set == 'power10' and cc.get_id() == 'gcc' and
+cc.version().version_compare('<=11.4'))
+machine_args += '-mno-block-ops-vector-pair'
+endif
+
 dpdk_conf.set('RTE_MACHINE', cpu_instruction_set)

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

CFP submission reminder

[Nathan Southern]

Good afternoon DPDK Community,

I would remind everyone again that the deadline for CFP submissions is* this
Friday at 11:59pm Pacific. *If you haven't yet submitted a proposal for a
live or virtual talk in Dublin (Sep. 12-13) and are interested in being
considered for this, please go ahead and submit.

Here is a link to do so:


*https://events.linuxfoundation.org/dpdk-summit/program/cfp/
*

Let us know if you have any questions.

Best,

Nathan

Nathan C. Southern, Project Coordinator

Data Plane Development Kit

The Linux Foundation

248.835.4812 (mobile)

nsouth...@linuxfoundation.org

RE: [PATCH v2] crypto/qat: fix NULL algorithm digest placement

[Kusztal, ArkadiuszX]

> -Original Message-
> From: Ciara Power 
> Sent: Friday, June 23, 2023 3:51 PM
> To: dev@dpdk.org
> Cc: Power, Ciara ; Ji, Kai 
> Subject: [PATCH v2] crypto/qat: fix NULL algorithm digest placement
> 
> QAT HW generates bytes of 0x00 digest, even when a digest of len 0 is
> requested for NULL. This caused test failures when the test vector had digest 
> len
> 0, as the buffer has unexpected changed bytes.
> 
> By placing the digest into the cookie for NULL authentication, the buffer
> remains unchanged as expected, and the digest is placed to the side, as it 
> won't
> be used anyway.
> 
> Fixes: db0e952a5c01 ("crypto/qat: add NULL capability")
> 
> Signed-off-by: Ciara Power 
> ---
> v2: added fixes line as this was a bug
> ---
> --
> 2.25.1

Acked-by: Arek Kusztal 

[PATCH v4 0/5] Logging related patchs

[Stephen Hemminger]

This patch set rebases and extends some earlier work on logging.

Stephen Hemminger (5):
  eal: unify logging code for FreeBsd and Linux
  eal: turn off getopt_long error message during eal_log_level
  eal: skip stdio on console logging
  eal: move logging initialization earlier
  eal: add option to put timestamp on console output

 .../freebsd_gsg/freebsd_eal_parameters.rst| 32 +++
 doc/guides/linux_gsg/linux_eal_parameters.rst |  5 +
 lib/eal/common/eal_common_options.c   |  6 ++
 lib/eal/common/eal_internal_cfg.h |  3 +
 lib/eal/common/eal_options.h  |  2 +
 lib/eal/freebsd/eal.c | 39 +---
 lib/eal/linux/eal.c   | 48 +-
 lib/eal/linux/eal_log.c   | 61 
 lib/eal/linux/meson.build |  1 -
 lib/eal/unix/eal_log.c| 93 +++
 lib/eal/unix/meson.build  |  1 +
 lib/eal/windows/eal.c |  3 +
 12 files changed, 194 insertions(+), 100 deletions(-)
 delete mode 100644 lib/eal/linux/eal_log.c
 create mode 100644 lib/eal/unix/eal_log.c

-- 
2.39.2

[PATCH v4 1/5] eal: unify logging code for FreeBsd and Linux

[Stephen Hemminger]

FreeBSD logging code was not using syslog and did not have
the same options as Linux. Move the log writing code to common
source tree.

Signed-off-by: Stephen Hemminger 
---
 .../freebsd_gsg/freebsd_eal_parameters.rst| 27 +++
 lib/eal/freebsd/eal.c |  7 +
 lib/eal/linux/meson.build |  1 -
 lib/eal/{linux => unix}/eal_log.c |  0
 lib/eal/unix/meson.build  |  1 +
 5 files changed, 35 insertions(+), 1 deletion(-)
 rename lib/eal/{linux => unix}/eal_log.c (100%)

diff --git a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst 
b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
index fba467a2ce92..9270d9fa3bfc 100644
--- a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
+++ b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
@@ -18,3 +18,30 @@ FreeBSD-specific EAL parameters
 ---
 
 There are currently no FreeBSD-specific EAL command-line parameters available.
+
+Other options
+~
+
+*   ``--syslog ``
+
+Set syslog facility. Valid syslog facilities are::
+
+auth
+cron
+daemon
+ftp
+kern
+lpr
+mail
+news
+syslog
+user
+uucp
+local0
+local1
+local2
+local3
+local4
+local5
+local6
+local7
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 7008303e112a..6df6873e3889 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -52,6 +52,7 @@
 #include "eal_hugepages.h"
 #include "eal_options.h"
 #include "eal_memcfg.h"
+#include "eal_log.h"
 #include "eal_trace.h"
 
 #define MEMSIZE_IF_NO_HUGE_PAGE (64ULL * 1024ULL * 1024ULL)
@@ -759,6 +760,12 @@ rte_eal_init(int argc, char **argv)
 #endif
}
 
+   if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
+   rte_eal_init_alert("Cannot init logging.");
+   rte_errno = ENOMEM;
+   return -1;
+   }
+
/* in secondary processes, memory init may allocate additional fbarrays
 * not present in primary processes, so to avoid any potential issues,
 * initialize memzones first.
diff --git a/lib/eal/linux/meson.build b/lib/eal/linux/meson.build
index 5af456db9edb..e99ebed25692 100644
--- a/lib/eal/linux/meson.build
+++ b/lib/eal/linux/meson.build
@@ -11,7 +11,6 @@ sources += files(
 'eal_hugepage_info.c',
 'eal_interrupts.c',
 'eal_lcore.c',
-'eal_log.c',
 'eal_memalloc.c',
 'eal_memory.c',
 'eal_thread.c',
diff --git a/lib/eal/linux/eal_log.c b/lib/eal/unix/eal_log.c
similarity index 100%
rename from lib/eal/linux/eal_log.c
rename to lib/eal/unix/eal_log.c
diff --git a/lib/eal/unix/meson.build b/lib/eal/unix/meson.build
index cc7d67dd321d..37d07594df29 100644
--- a/lib/eal/unix/meson.build
+++ b/lib/eal/unix/meson.build
@@ -6,6 +6,7 @@ sources += files(
 'eal_file.c',
 'eal_filesystem.c',
 'eal_firmware.c',
+'eal_log.c',
 'eal_unix_memory.c',
 'eal_unix_thread.c',
 'eal_unix_timer.c',
-- 
2.39.2

[PATCH v4 2/5] eal: turn off getopt_long error message during eal_log_level

[Stephen Hemminger]

If DPDK application is given a bogus option, the error message
would get printed twice. Once during scan for log level and
again during parsing of arguments.

Example:
# ./build/app/dpdk-testpmd --bogus
./build/app/dpdk-testpmd: unrecognized option '--bogus'
EAL: Detected CPU lcores: 16
EAL: Detected NUMA nodes: 1
./build/app/dpdk-testpmd: unrecognized option '--bogus'

Usage: ./build/app/dpdk-testpmd [options]

Fix by suppressing printing error message on first pass.

Signed-off-by: Keith Wiles 
Signed-off-by: Stephen Hemminger 
---
 lib/eal/freebsd/eal.c | 2 ++
 lib/eal/linux/eal.c   | 2 ++
 lib/eal/windows/eal.c | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 6df6873e3889..70087837da18 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -381,6 +381,7 @@ eal_log_level_parse(int argc, char **argv)
argvopt = argv;
optind = 1;
optreset = 1;
+   opterr = 0;
 
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
@@ -424,6 +425,7 @@ eal_parse_args(int argc, char **argv)
argvopt = argv;
optind = 1;
optreset = 1;
+   opterr = 1;
 
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 145afafde234..60bb130aea15 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -561,6 +561,7 @@ eal_log_level_parse(int argc, char **argv)
 
argvopt = argv;
optind = 1;
+   opterr = 0;
 
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
@@ -638,6 +639,7 @@ eal_parse_args(int argc, char **argv)
 
argvopt = argv;
optind = 1;
+   opterr = 1;
 
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
diff --git a/lib/eal/windows/eal.c b/lib/eal/windows/eal.c
index 2d7a0e9ab27e..0800a9e5c2d2 100644
--- a/lib/eal/windows/eal.c
+++ b/lib/eal/windows/eal.c
@@ -106,6 +106,8 @@ eal_log_level_parse(int argc, char **argv)
struct internal_config *internal_conf =
eal_get_internal_configuration();
 
+   opterr = 0;
+
argvopt = argv;
 
eal_reset_internal_config(internal_conf);
@@ -143,6 +145,7 @@ eal_parse_args(int argc, char **argv)
eal_get_internal_configuration();
 
argvopt = argv;
+   opterr = 1;
 
while ((opt = getopt_long(argc, argvopt, eal_short_options,
eal_long_options, &option_index)) != EOF) {
-- 
2.39.2

[PATCH v4 3/5] eal: skip stdio on console logging

[Stephen Hemminger]

There is no need to use stdio when logging to console.
Using the write system call directly avoids unnecessary copy
to stdio output buffer.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/unix/eal_log.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/eal/unix/eal_log.c b/lib/eal/unix/eal_log.c
index d44416fd6570..baa721021991 100644
--- a/lib/eal/unix/eal_log.c
+++ b/lib/eal/unix/eal_log.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -19,8 +20,7 @@ console_log_write(__rte_unused void *c, const char *buf, 
size_t size)
ssize_t ret;
 
/* write on stderr */
-   ret = fwrite(buf, 1, size, stderr);
-   fflush(stderr);
+   ret = write(STDERR_FILENO, buf, size);
 
/* Syslog error levels are from 0 to 7, so subtract 1 to convert */
syslog(rte_log_cur_msg_loglevel() - 1, "%.*s", (int)size, buf);
-- 
2.39.2

[PATCH v4 4/5] eal: move logging initialization earlier

[Stephen Hemminger]

The log stream should be setup before any messages.
This ensures that any startup problems are captured on the
syslog output, not only shown on the stderr.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/freebsd/eal.c | 40 +++
 lib/eal/linux/eal.c   | 44 +--
 2 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 70087837da18..d3aac3d628a8 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -364,7 +364,7 @@ eal_get_hugepage_mem_size(void)
return (size < SIZE_MAX) ? (size_t)(size) : SIZE_MAX;
 }
 
-/* Parse the arguments for --log-level only */
+/* Parse the arguments for --log-level and --syslog */
 static void
 eal_log_level_parse(int argc, char **argv)
 {
@@ -386,20 +386,18 @@ eal_log_level_parse(int argc, char **argv)
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
 
-   int ret;
-
-   /* getopt is not happy, stop right now */
-   if (opt == '?')
-   break;
-
-   ret = (opt == OPT_LOG_LEVEL_NUM) ?
-   eal_parse_common_option(opt, optarg, internal_conf) : 0;
-
-   /* common parser is not happy */
-   if (ret < 0)
+   switch (opt) {
+   case OPT_SYSLOG_NUM:/* fallthrough */
+   case OPT_LOG_LEVEL_NUM:
+   if (eal_parse_common_option(opt, optarg, internal_conf) 
< 0)
+   goto error;
break;
+   case '?':
+   /* getopt is not happy, stop right now */
+   goto error;
+   }
}
-
+error:
/* restore getopt lib */
optind = old_optind;
optopt = old_optopt;
@@ -437,8 +435,8 @@ eal_parse_args(int argc, char **argv)
goto out;
}
 
-   /* eal_log_level_parse() already handled this option */
-   if (opt == OPT_LOG_LEVEL_NUM)
+   /* eal_log_level_parse() already handled these */
+   if (opt == OPT_LOG_LEVEL_NUM || opt == OPT_SYSLOG_NUM)
continue;
 
ret = eal_parse_common_option(opt, optarg, internal_conf);
@@ -615,6 +613,12 @@ rte_eal_init(int argc, char **argv)
/* set log level as early as possible */
eal_log_level_parse(argc, argv);
 
+   if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
+   rte_eal_init_alert("Cannot init logging.");
+   rte_errno = ENOMEM;
+   return -1;
+   }
+
if (rte_eal_cpu_init() < 0) {
rte_eal_init_alert("Cannot detect lcores.");
rte_errno = ENOTSUP;
@@ -762,12 +766,6 @@ rte_eal_init(int argc, char **argv)
 #endif
}
 
-   if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
-   rte_eal_init_alert("Cannot init logging.");
-   rte_errno = ENOMEM;
-   return -1;
-   }
-
/* in secondary processes, memory init may allocate additional fbarrays
 * not present in primary processes, so to avoid any potential issues,
 * initialize memzones first.
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 60bb130aea15..51c4ec75d57b 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -546,7 +546,7 @@ eal_parse_vfio_vf_token(const char *vf_token)
return -1;
 }
 
-/* Parse the arguments for --log-level only */
+/* Parse the arguments for --log-level and --syslog */
 static void
 eal_log_level_parse(int argc, char **argv)
 {
@@ -566,20 +566,18 @@ eal_log_level_parse(int argc, char **argv)
while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {
 
-   int ret;
-
-   /* getopt is not happy, stop right now */
-   if (opt == '?')
-   break;
-
-   ret = (opt == OPT_LOG_LEVEL_NUM) ?
-   eal_parse_common_option(opt, optarg, internal_conf) : 0;
-
-   /* common parser is not happy */
-   if (ret < 0)
+   switch (opt) {
+   case OPT_SYSLOG_NUM:/* fallthrough */
+   case OPT_LOG_LEVEL_NUM:
+   if (eal_parse_common_option(opt, optarg, internal_conf) 
< 0)
+   goto error;
break;
+   case '?':
+   /* getopt is not happy, stop right now */
+   goto error;
+   }
}
-
+error:
/* restore getopt lib */
optind = old_optind;
optopt = old_optopt;
@@ -651,8 +649,8 @@ eal_parse_args(int argc, char *

[PATCH v4 5/5] eal: add option to put timestamp on console output

[Stephen Hemminger]

When debugging driver or startup issues, it is useful to have
a timestamp on each message printed. The messages in syslog
already have a timestamp, but often syslog is not available
during testing. The timestamp format is chosen to look
like the default Linux dmesg timestamp.

Example:
$ dpdk-testpmd --log-timestamp -- -i
[   0.007615] EAL: Detected CPU lcores: 16
[   0.007657] EAL: Detected NUMA nodes: 1
[   0.007878] EAL: Detected static linkage of DPDK
[   0.009469] EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
[   0.012175] EAL: Selected IOVA mode 'VA'
[   0.120016] testpmd: No probed ethernet devices
Interactive-mode selected
[   0.155959] testpmd: create a new mbuf pool : n=267456, 
size=2176, socket=0
[   0.155990] testpmd: preferred mempool ops selected: ring_mp_mc

Signed-off-by: Stephen Hemminger 
---
 .../freebsd_gsg/freebsd_eal_parameters.rst|  5 +++
 doc/guides/linux_gsg/linux_eal_parameters.rst |  5 +++
 lib/eal/common/eal_common_options.c   |  6 
 lib/eal/common/eal_internal_cfg.h |  3 ++
 lib/eal/common/eal_options.h  |  2 ++
 lib/eal/freebsd/eal.c |  4 ++-
 lib/eal/linux/eal.c   |  4 ++-
 lib/eal/unix/eal_log.c| 36 +--
 8 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst 
b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
index 9270d9fa3bfc..99cff10e963c 100644
--- a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
+++ b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
@@ -45,3 +45,8 @@ Other options
 local5
 local6
 local7
+
+*   ``--log-timestamp``
+
+Add a timestamp of seconds and microseconds to each log message
+written to standard output.
diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst 
b/doc/guides/linux_gsg/linux_eal_parameters.rst
index ea8f38139119..719ca6851625 100644
--- a/doc/guides/linux_gsg/linux_eal_parameters.rst
+++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
@@ -135,3 +135,8 @@ Other options
 local5
 local6
 local7
+
+*   ``--log-timestamp``
+
+Add a timestamp of seconds and microseconds to each log message
+written to standard output.
diff --git a/lib/eal/common/eal_common_options.c 
b/lib/eal/common/eal_common_options.c
index 03059336987d..c6c74cc31e9c 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -76,6 +76,7 @@ eal_long_options[] = {
{OPT_IOVA_MODE, 1, NULL, OPT_IOVA_MODE_NUM},
{OPT_LCORES,1, NULL, OPT_LCORES_NUM   },
{OPT_LOG_LEVEL, 1, NULL, OPT_LOG_LEVEL_NUM},
+   {OPT_LOG_TIMESTAMP, 0, NULL, OPT_LOG_TIMESTAMP_NUM},
{OPT_TRACE, 1, NULL, OPT_TRACE_NUM},
{OPT_TRACE_DIR, 1, NULL, OPT_TRACE_DIR_NUM},
{OPT_TRACE_BUF_SIZE,1, NULL, OPT_TRACE_BUF_SIZE_NUM   },
@@ -1835,6 +1836,10 @@ eal_parse_common_option(int opt, const char *optarg,
}
 
 #ifndef RTE_EXEC_ENV_WINDOWS
+   case OPT_LOG_TIMESTAMP_NUM:
+   conf->log_timestamp = 1;
+   break;
+
case OPT_TRACE_NUM: {
if (eal_trace_args_save(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameters for --"
@@ -2194,6 +2199,7 @@ eal_common_usage(void)
   "  --"OPT_PROC_TYPE" Type of this process 
(primary|secondary|auto)\n"
 #ifndef RTE_EXEC_ENV_WINDOWS
   "  --"OPT_SYSLOG"Set syslog facility\n"
+  "  --"OPT_LOG_TIMESTAMP" Timestamp log output\n"
 #endif
   "  --"OPT_LOG_LEVEL"= Set global log level\n"
   "  --"OPT_LOG_LEVEL"=:\n"
diff --git a/lib/eal/common/eal_internal_cfg.h 
b/lib/eal/common/eal_internal_cfg.h
index 167ec501fa79..1a1a7fdcfa8c 100644
--- a/lib/eal/common/eal_internal_cfg.h
+++ b/lib/eal/common/eal_internal_cfg.h
@@ -84,7 +84,10 @@ struct internal_config {
/**< true if storing all pages within single files (per-page-size,
 * per-node) non-legacy mode only.
 */
+   volatile uint8_t log_timestamp;   /**< add timestamp to console output 
*/
volatile int syslog_facility; /**< facility passed to openlog() */
+   struct timespec log_start_time;   /**< when logging was started */
+
/** default interrupt mode for VFIO */
volatile enum rte_intr_mode vfio_intr_mode;
/** the shared VF token for VFIO-PCI bound PF and VFs devices */
diff --git a/lib/eal/common/eal_options.h b/lib/eal/common/eal_options.h
index 3cc9cb641284..cc9723868e3c 100644
--- a/lib/eal/common/eal_options.h
+++ b/lib/eal/common/eal_options.h
@@ -35,6 +35,8 @@ enum {
OPT_LCORES_NUM,
 #define OPT_LOG_LEVEL "log-level"
OPT_LOG_LEVEL_NUM,
+#define OPT_LOG_TIMESTAMP "log-timestamp"
+   OPT_LO

Re: [PATCH v1] net/mlx5: add test for hot upgrade

[Thomas Monjalon]

16/05/2023 07:41, Rongwei Liu:
> This patch adds testpmd app a runtime function to test the hot
> upgrade API.
> 
> testpmd> mlx5 set flow_engine <0|1> (flag)
> 0 stands for active mode while 1 for standby mode.
> 
> Signed-off-by: Rongwei Liu 
> Acked-by: Viacheslav Ovsiienko 
> ---
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -2057,3 +2057,13 @@ where:
>  * ``sw_queue_id``: queue index in range [64536, 65535].
>This range is the highest 1000 numbers.
>  * ``hw_queue_id``: queue index given by HW in queue creation.
> +
> +Set Flow Engine Mode
> +

The title is made as a sub-section of "port map external Rx queue",
which looks wrong.

> +
> +Set the flow engine to active(0) or standby(1) mode with specific flags::
> +   testpmd> mlx5 set flow_engine <0|1> (flags)

It should be said it is for testing live migration.

Also the flags are not described. Should we pass an integer?

> +
> +This command works for software steering only.
> +Default FDB jump should be disabled if switchdev is enabled.
> +The mode will propagate to all the probed ports.

For the reasons above, I prefer not pulling this patch in the main branch.

[PATCH] doc: announce QAT support on aarch64

[Dharmik Thakkar]

Update release notes with added support for QAT on Ampere Altra.

Signed-off-by: Dharmik Thakkar 
Reviewed-by: Ruifeng Wang 
---
 doc/guides/rel_notes/release_23_07.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index e54a0fdef3a0..695152cd207e 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -55,6 +55,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Intel QuickAssist Technology (QAT) supports on Ampere Altra platform.**
+
+  Tested with ipsec-secgw sample application and cryptodev_qat_autotest.
+
 * **Added AMD CDX bus support.**
 
   CDX bus driver has been added to support AMD CDX bus,
-- 
2.25.1

Re: [RFC 2/5] common/mlx5: introduce tracepoints for mlx5 drivers

[Thomas Monjalon]

13/06/2023 18:01, Jerin Jacob:
> On Tue, Jun 13, 2023 at 9:29 PM Slava Ovsiienko  
> wrote:
> > From: Jerin Jacob 
> > > On Tue, Jun 13, 2023 at 9:20 PM Slava Ovsiienko 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > <..snip..>
> > > > > >
> > > > > > mlx5_os_interrupt_handler_create; # WINDOWS_NO_EXPORT
> > > > > > mlx5_os_interrupt_handler_destroy; # WINDOWS_NO_EXPORT
> > > > > > +
> > > > > > +   __rte_pmd_mlx5_trace_tx_entry;
> > > > > > +   __rte_pmd_mlx5_trace_tx_exit;
> > > > > > +   __rte_pmd_mlx5_trace_tx_wqe;
> > > > > > +   __rte_pmd_mlx5_trace_tx_wait;
> > > > > > +   __rte_pmd_mlx5_trace_tx_push;
> > > > > > +   __rte_pmd_mlx5_trace_tx_complete;
> > > > >
> > > > > No need to expose these symbols. It is getting removed from rest of 
> > > > > DPDK.
> > > > > Application can do rte_trace_lookup() to get this address.
> > > > >
> > > > >
> > > > It is not for application, it is for PMD itself, w/o exposing the 
> > > > symbols build
> > > failed.
> > >
> > > PMD is implementing this trace endpoints, not consuming this trace point.
> > > Right? If so, Why to expose these symbols?
> >
> > As far as understand:
> > The tracepoint routines are defined in dedicated common/mlx5_trace.c file.
> > The tx_burst in mlx5 is implemented as template in header file, and this
> > template is used in multiple .c files under net/mlx5 filder.
> > So, common/mlx5 should expose its symbols to net/mlx5 to allow successful
> > linkage.
> 
> OK. I missed the fact the these are in common code and net driver is
> depened on that.
> So changes makes sense.

It does not make sense to me.
These are tracepoints for the ethdev driver.
Why declaring them in the common library?

Re: [PATCH v2 0/5] net/mlx5: introduce Tx datapath tracing

[Thomas Monjalon]

20/06/2023 14:00, Raslan Darawsheh:
> Hi,
> 
> > -Original Message-
> > From: Viacheslav Ovsiienko 
> > Sent: Tuesday, June 13, 2023 7:59 PM
> > To: dev@dpdk.org
> > Subject: [PATCH v2 0/5] net/mlx5: introduce Tx datapath tracing
> > 
> > The mlx5 provides the send scheduling on specific moment of time,
> > and for the related kind of applications it would be extremely useful
> > to have extra debug information - when and how packets were scheduled
> > and when the actual sending was completed by the NIC hardware (it helps
> > application to track the internal delay issues).
> > 
> > Because the DPDK tx datapath API does not suppose getting any feedback
> > from the driver and the feature looks like to be mlx5 specific, it seems
> > to be reasonable to engage exisiting DPDK datapath tracing capability.
> > 
> > The work cycle is supposed to be:
> >   - compile appplication with enabled tracing
> >   - run application with EAL parameters configuring the tracing in mlx5
> > Tx datapath
> >   - store the dump file with gathered tracing information
> >   - run analyzing scrypt (in Python) to combine related events (packet
> > firing and completion) and see the data in human-readable view
> > 
> > Below is the detailed instruction "how to" with mlx5 NIC to gather
> > all the debug data including the full timings information.
> > 
> > 
> > 1. Build DPDK application with enabled datapath tracing
> > 
> > The meson option should be specified:
> >--enable_trace_fp=true
> > 
> > The c_args shoudl be specified:
> >-DALLOW_EXPERIMENTAL_API
> > 
> > The DPDK configuration examples:
> > 
> >   meson configure --buildtype=debug -Denable_trace_fp=true
> > -Dc_args='-DRTE_LIBRTE_MLX5_DEBUG -DRTE_ENABLE_ASSERT -
> > DALLOW_EXPERIMENTAL_API' build
> > 
> >   meson configure --buildtype=debug -Denable_trace_fp=true
> > -Dc_args='-DRTE_ENABLE_ASSERT -DALLOW_EXPERIMENTAL_API' build
> > 
> >   meson configure --buildtype=release -Denable_trace_fp=true
> > -Dc_args='-DRTE_ENABLE_ASSERT -DALLOW_EXPERIMENTAL_API' build
> > 
> >   meson configure --buildtype=release -Denable_trace_fp=true
> > -Dc_args='-DALLOW_EXPERIMENTAL_API' build
> > 
> > 
> > 2. Configuring the NIC
> > 
> > If the sending completion timings are important the NIC should be configured
> > to provide realtime timestamps, the REAL_TIME_CLOCK_ENABLE NV settings
> > parameter
> > should be configured to TRUE, for example with command (and with following
> > FW/driver reset):
> > 
> >   sudo mlxconfig -d /dev/mst/mt4125_pciconf0 s
> > REAL_TIME_CLOCK_ENABLE=1
> > 
> > 
> > 3. Run DPDK application to gather the traces
> > 
> > EAL parameters controlling trace capability in runtime
> > 
> >   --trace=pmd.net.mlx5.tx - the regular expression enabling the tracepoints
> > with matching names at least "pmd.net.mlx5.tx"
> > must be enabled to gather all events needed
> > to analyze mlx5 Tx datapath and its timings.
> > By default all tracepoints are disabled.
> > 
> >   --trace-dir=/var/log - trace storing directory
> > 
> >   --trace-bufsz=B|K|M - optional, trace data buffer size
> >per thread. The default is 1MB.
> > 
> >   --trace-mode=overwrite|discard  - optional, selects trace data buffer 
> > mode.
> > 
> > 
> > 4. Installing or Building Babeltrace2 Package
> > 
> > The gathered trace data can be analyzed with a developed Python script.
> > To parse the trace, the data script uses the Babeltrace2 library.
> > The package should be either installed or built from source code as
> > shown below:
> > 
> >   git clone https://github.com/efficios/babeltrace.git
> >   cd babeltrace
> >   ./bootstrap
> >   ./configure -help
> >   ./configure --disable-api-doc --disable-man-pages
> >   --disable-python-bindings-doc --enbale-python-plugins
> >   --enable-python-binding
> > 
> > 5. Running the Analyzing Script
> > 
> > The analyzing script is located in the folder: ./drivers/net/mlx5/tools
> > It requires Python3.6, Babeltrace2 packages and it takes the only parameter
> > of trace data file. For example:
> > 
> >./mlx5_trace.py /var/log/rte-2023-01-23-AM-11-52-39
> > 
> > 
> > 6. Interpreting the Script Output Data
> > 
> > All the timings are given in nanoseconds.
> > The list of Tx (and coming Rx) bursts per port/queue is presented in the
> > output.
> > Each list element contains the list of built WQEs with specific opcodes, and
> > each WQE contains the list of the encompassed packets to send.

This information should be in the documentation.

I think we should request a review of the Python script from people familiar 
with tracing
and from people more familiar with Python scripting for user tools.

RE: [PATCH] config/arm: add HiSilicon hip10

[Ruifeng Wang]

> -Original Message-
> From: Dongdong Liu 
> Sent: Monday, June 26, 2023 8:43 PM
> To: dev@dpdk.org; ferruh.yi...@amd.com; tho...@monjalon.net; Ruifeng Wang
> 
> Subject: [PATCH] config/arm: add HiSilicon hip10
> 
> Adding support for HiSilicon hip10 platform.
> 
> Signed-off-by: Dongdong Liu 
> ---
>  config/arm/arm64_hip10_linux_gcc | 16 
>  config/arm/meson.build   | 19 +++
>  2 files changed, 35 insertions(+)
>  create mode 100644 config/arm/arm64_hip10_linux_gcc
> 
Acked-by: Ruifeng Wang