Re: [PATCH 3/3] dma/idxd: fix non-AVX builds with older compilers

[Thomas Monjalon]

> > When building without AVX2 support using an older compiler e.g. gcc 4.8 on
> > Centos/RHEL 7, we get build errors due to the use of AVX2 intrinsics.
> > This is because the compiler does not support
> > "__attribute__((target(AVX2)))" function attribute. Disable build of this
> > driver such edge cases.
> > 
> > Generic builds using recent compilers, and all builds with a minimum 
> > baseline
> > of AVX2 are unaffected by this change.
> > 
> > Fixes: aa802b10237c ("dma/idxd: fix AVX2 in non-datapath functions")
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> Tested-by: Yu Jiang 
> 
> Tested env as below:
> OS: CentOS7.9/kernel: 3.10.0-1160.62.1.el7.x86_64
> Compiler: gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

Series applied, thanks.

Re: [PATCH v2 1/2] examples/l3fwd: add include for macro definition

[Thomas Monjalon]

15/06/2022 19:10, Bruce Richardson:
> The header files "l3fwd_em.h" and "l3fwd_em_sequential.h" use the
> "__rte_always_inline" macro but don't directly include "rte_common.h" to
> get the definition of it. This inclusion is not necessary for
> compilation, but the lack of it can confuse some indexers - such as
> those in eclipse, which reports the lines:
> 
> "static __rte_always_inline uint16_t"
> 
> as possible definitions of a variable called "uint16_t". This confusion
> leads to uint16_t being flagged as an unknown type in all other parts of
> the project being indexed, e.g. across all of DPDK code.
> 
> Adding in the include of rte_common.h makes it clear to the indexer that
> those lines are  part of a function definition, and that allows eclipse
> to correctly recognise uint16_t as a type from stdint.h
> 
> Signed-off-by: Bruce Richardson 

Applied, thanks.

Re: [PATCH] rte_rib6: fix references to rte_rib

[Thomas Monjalon]

> > The comments in rte_rib6 were cut-and-pasted from rte_rib
> > and because of that some references to rte_rib_node were
> > not updated.
> >
> > Signed-off-by: Stephen Hemminger 
> Acked-by: Vladimir Medvedkin 

Applied, thanks.

Re: [PATCH] raw/ifpga: avoid potential integer overflow

[Thomas Monjalon]

> > Expression "tx_chunks * ctx->dma_buf_size" in dma_fpga_to_fpga() is 
> > evaluated
> > using 32-bit arithmetic, which would overflow  potentially. Change 
> > tx_chunks to
> > type "uint64_t" to avoid such issue.
> > 
> > Coverity issue: 379203
> > Fixes: 7d63899a5c19 ("raw/ifpga: add N3000 AFU driver")
> > 
> > Signed-off-by: Wei Huang 
> 
> It looks good for me.
> 
> Acked-by: Tianfei Zhang 

Applied, thanks.

Re: [PATCH] raw/ifpga/base: check pointer before dereference

[Thomas Monjalon]

> > Do null-checking on hw->adapter in fme_pmci_init() before dereference it.
> > 
> > Coverity issue: 379202
> > Fixes: ca6eb0f7c836 ("raw/ifpga/base: add PMCI base driver")
> > 
> > Signed-off-by: Wei Huang 
> 
> It looks good for me.
> 
> Acked-by: Tianfei Zhang 

Applied, thanks.

RE: ask for TXA_FLUSH_THRESHOLD change

[Jaeeun Ham]

Hi,

Packets seem to be silently discarded in the RX NIC while waiting in the 
buffer, and it does not happen when I use only one worker core.
I think multiple worker cores packet processing would have this problem to 
handle heavy traffic in parallel.

I want to increase buffer size to solve this as below, then is it right to 
change only modify the number from 4 to 8?
I am trying to gather DPDK and PMD driver log such as "--log-level="7" 
--log-level="pmd.net,7". Could you recommend how to set the log-level string to 
confirm silent packet drop?

dpdk-stable-20.11.1/lib/librte_eventdev/rte_event_eth_rx_adapter.c

#define BATCH_SIZE  32
#define BLOCK_CNT_THRESHOLD 10
#define ETH_EVENT_BUFFER_SIZE   (4*BATCH_SIZE)  // e.g. (8*BATCH_SIZE)

#define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
#define ETH_RX_ADAPTER_MEM_NAME_LEN 32

#define RSS_KEY_SIZE40
/* value written to intr thread pipe to signal thread exit */
#define ETH_BRIDGE_INTR_THREAD_EXIT 1
/* Sentinel value to detect initialized file handle */
#define INIT_FD -1

BR/Jaeeun

From: Jaeeun Ham
Sent: Wednesday, June 22, 2022 11:14 AM
To: Jayatheerthan, Jay ; dev@dpdk.org
Cc: Jerin Jacob 
Subject: RE: ask for TXA_FLUSH_THRESHOLD change

Hi,

Could you guide me on how to eliminate or reduce tx drop/retry?
TXA_FLUSH_THRESHOLD helped somewhat but it was not cleared packet tx drop.

[ TX adapter stats ]
tx_retry: 17499893
tx_packets: 7501716
tx_dropped: 5132458

BR/Jaeeun

From: Jayatheerthan, Jay 
mailto:jay.jayatheert...@intel.com>>
Sent: Thursday, June 16, 2022 3:40 PM
To: Jaeeun Ham mailto:jaeeun@ericsson.com>>; 
dev@dpdk.org
Cc: Jerin Jacob mailto:jer...@marvell.com>>
Subject: RE: ask for TXA_FLUSH_THRESHOLD change

Hi Jaeeun,
See my responses inline below.

-Jay


From: Jaeeun Ham mailto:jaeeun@ericsson.com>>
Sent: Monday, June 13, 2022 5:51 AM
To: dev@dpdk.org
Cc: Jerin Jacob mailto:jer...@marvell.com>>; Jayatheerthan, 
Jay mailto:jay.jayatheert...@intel.com>>
Subject: ask for TXA_FLUSH_THRESHOLD change

Hi,

There were latency delay when I increase dpdk(20.11.1) core. (one worker core 
was okay.)
When I decrease the TXA_FLUSH_THRESHOLD value(1024 to 32), it was okay

It's TXA_FLUSH_THRESHOLD at lib/librte_eventdev/rte_event_eth_tx_adapter.c. // 
https://git.dpdk.org/dpdk-stable/tree/lib/librte_eventdev/rte_event_eth_tx_adapter.c?h=20.11#n15
When TXA_FLUSH_THRESHOLD value was changed from 1024 to 32, the latency test 
result was fine on 10 cores for low traffic(DL:20Mbps/UL:17kbps).
I think that this can make call for rte_eth_tx_buffer_flush() more frequently.
But, I'm not sure whether this approach can cause worse performance or not.
Do you have any opinion about this?

[Jay] Yes, it will cause rte_eth_tx_buffer_flush() to be called more often. It 
can lead to lesser batching benefit. Typical performance vs. latency trade-off 
decision apply here.


Similar RDK RTE_BRIDGE_ETH_TX_FLUSH_THOLD is patched on DUSG3 from 1024 to 
smaller value since DPDK 18.11.2:
I'm not aware of any side-effect, I think it is needed to have low enough 
latency even at low traffic rates.  For more details see Intel FP 
22288.

[Jay] Currently, TXA_FLUSH_THRESHOLD is not a configurable attr.

TXA_MAX_NB_TX(128) looks the same as 
CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE(16384), then is it also should be tuned?

[Jay] They both are different attributes. TXA_MAX_NB_TX refers to max number of 
queues in Tx adapter. CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE refers to event 
buffer size in Rx BD.


--- dpdk-3pp-swu-18.11/dpdk-stable-18.11.2/config/common_base.orig  2020-01-29 
15:05:10.0 +0100
+++ dpdk-3pp-swu-18.11/dpdk-stable-18.11.2/config/common_base   2020-01-29 
15:11:10.0 +0100
@@ -566,9 +566,9 @@
CONFIG_RTE_LIBRTE_BRIDGE_ETH_MAX_CP_ENQ_RETRIES=100
CONFIG_RTE_MAX_BRIDGE_ETH_INSTANCE=4
CONFIG_RTE_BRIDGE_ETH_INTR_RING_SIZE=32
-CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE=128
+CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE=16384
CONFIG_RTE_LIBRTE_BRIDGE_ETH_DEBUG=n
-CONFIG_RTE_BRIDGE_ETH_TX_FLUSH_THOLD=1024
+CONFIG_RTE_BRIDGE_ETH_TX_FLUSH_THOLD=32

--- dpdk-3pp-swu-dusg3-20.11.3/dpdk-stable-20.11.3/config/rte_config.h   
2021-08-05 23:46:52.051051000 +0200
+++ dpdk-3pp-swu-dusg3-20.11.3/dpdk-stable-20.11.3/config/rte_config.h   
2021-08-06 00:50:07.310766255 +0200
@@ -175,8 +175,8 @@
#define RTE_LIBRTE_BRIDGE_ETH_MAX_CP_ENQ_RETRIES 100
#define RTE_MAX_BRIDGE_ETH_INSTANCE 4
#define RTE_BRIDGE_ETH_INTR_RING_SIZE 32
-#define RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE 128
-#define RTE_BRIDGE_ETH_TX_FLUSH_THOLD 1024
+#define RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE 16384
+#define RTE_BRIDGE_ETH_TX_FLUSH_THOLD 10

Re: [PATCH v3] kni: update kernel API to receive packets

[Thomas Monjalon]

21/04/2022 10:59, Gagandeep Singh:
> API 'netif_rx_ni()' has been removed in kernel with commit:
> baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any 
> context.")
> 
> The API netif_rx() can be used for any context to receive packets
> from device drivers.
> 
> This patch replaces the API netif_rx_ni() with netif_rx() for
> kernel version 5.18 and above.
> 
> Signed-off-by: Gagandeep Singh 

A similar patch has been merged recently:
https://git.dpdk.org/dpdk/commit/?id=c98600d4bed6d15599

Re: [PATCH] test/hash: avoid out of bound access

[Thomas Monjalon]

04/06/2022 10:37, Heinrich Schuchardt:
> rwc_non_lf_results->multi_rw, rwc_lf_results->multi_rw, and
> rwc_perf_results->multi_rw are accessed at indexes
> [0..NUM_TEST-1][0..1][0..NUMTEST-1]. Currently the first index
> overflows the array size in struct rwc_perf.
> 
> Fixes: c7eb0972e74b ("test/test/test_hash_readwrite_lf.c")
> Cc: Dharmik Thakkar 
> Cc: sta...@dpdk.org 
> Signed-off-by: Heinrich Schuchardt 

Applied, thanks.

Re: [PATCH 1/1] test/pmd_perf: handling of unknown connection speed

[Thomas Monjalon]

11/05/2022 18:33, Heinrich Schuchardt:
> When running DPDK in QEMU it cannot determine the connection speed.
> pmd_perf_autotest treats this as if the connection speed where
> UNIT32_MAX Mbps:
> 
> RTE>>pmd_perf_autotest
> Start PMD RXTX cycles cost test.
> Allocated mbuf pool on socket 0
> CONFIG RXD=1024 TXD=1024
> Performance test runs on lcore 1 socket 0
> Port 0 Address:52:54:00:12:34:57
> Port 1 Address:52:54:00:12:34:58
> Checking link statuses...
> Port 0 Link up at Unknown FDX Autoneg
> Port 1 Link up at Unknown FDX Autoneg
> IPv4 pktlen 46
> UDP pktlen 26
> Generate 4096 packets @socket 0
> inject 2048 packet to port 0
> inject 2048 packet to port 1
> Total packets inject to prime ports = 4096
> Each port will do 6391320379464 packets per second
> Test will stop after at least 25565281517856 packets received
> 
> This will not allow the test to terminate in a reasonable timespan.
> Just assume 10 Gbps in this case instead:
> 
> ...
> Test will stop after at least 59523808 packets received
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  app/test/test_pmd_perf.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
> index 25611bfe9b..ee08c8aade 100644
> --- a/app/test/test_pmd_perf.c
> +++ b/app/test/test_pmd_perf.c
> @@ -486,10 +486,17 @@ main_loop(__rte_unused void *args)
>   }
>   printf("Total packets inject to prime ports = %u\n", idx);
>  
> - packets_per_second = (link_mbps * 1000 * 1000) /
> - ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> - printf("Each port will do %"PRIu64" packets per second\n",
> -packets_per_second);
> + if (link_mbps != RTE_ETH_SPEED_NUM_UNKNOWN) {
> + packets_per_second = (link_mbps * 1000 * 1000) /
> + ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> + printf("Each port will do %"PRIu64" packets per second\n",
> +packets_per_second);
> + total_packets = RTE_TEST_DURATION * conf->nb_ports * 
> packets_per_second;

This is redundant with below.

> + } else {
> + /* We don't know the speed. Pretend it is 10G */
> + packets_per_second = ((uint64_t)RTE_ETH_SPEED_NUM_10G * 1000 * 
> 1000) /
> + ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> + }
>  
>   total_packets = RTE_TEST_DURATION * conf->nb_ports * packets_per_second;

Why not just inserting this:

if (link_mbps == RTE_ETH_SPEED_NUM_UNKNOWN)
link_mbps = RTE_ETH_SPEED_NUM_10G;

Re: [PATCH v2] app/procinfo: show all non-owned ports

[Thomas Monjalon]

25/05/2022 09:14, Morten Brørup:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, 25 May 2022 08.04
> > 
> > On Tue, 24 May 2022 22:46:05 -0700
> > Subendu Santra  wrote:
> > 
> > > Show all non-owned ports when no port mask is specified
> > >
> > > show-port option without the mask option, displays only the last
> > > non-owned port. Show all the non-owned ports instead.

I think it is easier to understand if using past tense
for the previous behaviour. I reword it like this:

The show-port option, without the mask option,
was showing only the last non-owned port.
Show all the non-owned ports instead.


> > > Fixes: 1dd6cffb6571 ("app/procinfo: provide way to request info on
> > owned
> > > ports")
> > > Cc: step...@networkplumber.org

+   Cc: sta...@dpdk.org

> > >
> > > Signed-off-by: Subendu Santra 
> > > ---
> > >  app/proc-info/main.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/app/proc-info/main.c b/app/proc-info/main.c
> > > index 56070a3317..2be24b584e 100644
> > > --- a/app/proc-info/main.c
> > > +++ b/app/proc-info/main.c
> > > @@ -1504,10 +1504,10 @@ main(int argc, char **argv)
> > >   if (nb_ports == 0)
> > >   rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n");
> > >
> > > - /* If no port mask was specified, then show non-owned ports */
> > > + /* If no port mask was specified, then show all non-owned ports
> > */
> > >   if (enabled_port_mask == 0) {
> > >   RTE_ETH_FOREACH_DEV(i)
> > > - enabled_port_mask = 1ul << i;
> > > + enabled_port_mask |= (1ul << i);
> > 
> > Ok, looks good. parens on that line are unnecessary

parens removed

> > 
> > Note: this still will have issues with >32 ports on 32 bit platforms.
> 
> The default max_ethports value in meson_options.txt is 32, so the probability 
> is low.
> 
> > But other tools probably have same problem.
> 
> It was decided many years ago to extend the port_id type from uint8_t to 
> uint16_t, mainly to support a high number of virtual ports. So it is not good 
> that the applications have not been updated accordingly.
> 
> However, as Stephen also mentions, this is not unique to this tool, so we'll 
> just ignore it.
> 
> > 
> > Acked-by: Stephen Hemminger 
> 
> Acked-by: Morten Brørup 

Applied with small changes, thanks.

Re: [PATCH 0/4] eal: remove some experimental tags

[Thomas Monjalon]

16/02/2022 20:39, Stephen Hemminger:
> These are all functions that have been in DPDK for two
> years or more and should no longer be experimental.
> 
> Stephen Hemminger (4):
>   rte_log: take of some experimental tags
>   lcore: change rte_lcore_to_cpu_id and rte_lcore_cpuset as not
> experimental
>   eal: make some intr functions not experimental
>   eal: mark rte_delay_us_sleep as not experimental

Applied, thanks.

Re: [PATCH v4] app/procinfo: add device private info dump

[Thomas Monjalon]

06/06/2022 16:39, Dongdong Liu:
> From: "Min Hu (Connor)" 
> 
> This patch adds support for dump the device private info from a running
> application. It can help developers locate the problem.
> 
> Signed-off-by: Min Hu (Connor) 
> Signed-off-by: Dongdong Liu 
> Acked-by: Reshma Pattan 

Applied, thanks.

[...]
>  /**< Enable show port. */
>  static uint32_t enable_shw_port;
> +/**< Enable show port private info. */
> +static uint32_t enable_shw_port_priv;

That's very strange this file is using some (wrong) doxygen syntax.
I'll fix this one when applying.
A cleanup may be needed for other comments in the file.

>  /**< Enable show tm. */
>  static uint32_t enable_shw_tm;
>  /**< Enable show crypto. */

Re: [PATCH 0/3] support dump ethdev info

[Thomas Monjalon]

Hi Reshma, please could you have a look at these patches?

We need to update the email address of Maryam as well.

Thanks

27/05/2022 03:42, Min Hu (Connor):
> Min Hu (Connor) (3):
>   app/procinfo: add version dump
>   app/procinfo: add RSS RETA dump
>   app/procinfo: add module info dump

Re: [dpdk-stable] [PATCH] app/regex: avoid division by zero

[Thomas Monjalon]

24/05/2021 14:09, Min Hu (Connor):
> Hi, Thierry,
>   This bug has been fixed in my earlier patch, please refer to:
> https://patches.dpdk.org/project/dpdk/patch/1618839289-33224-5-git-send-email-humi...@huawei.com/

Your patch is doing
+   if (!nb_jobs) {
+   job_len = data_len / nb_jobs;

It looks wrong.
I am for taking Thierry's patch.

> 在 2021/5/24 16:57, Thierry Herbelot 写道:
> > Check that nb_jobs is not zero before using it for a division.
> > 
> > Fixes: f5cffb7eb7fb6 ("app/regex: read data file once at startup")
> > Cc: sta...@dpdk.org
> > Cc: Ori Kam 
> > 
> > Signed-off-by: Thierry Herbelot 
> > ---
> >   app/test-regex/main.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/app/test-regex/main.c b/app/test-regex/main.c
> > index 8e665df73ce0..8f48cab11924 100644
> > --- a/app/test-regex/main.c
> > +++ b/app/test-regex/main.c
> > @@ -714,6 +714,8 @@ main(int argc, char **argv)
> > rte_exit(EXIT_FAILURE, "Number of QPs must be greater than 
> > 0\n");
> > if (nb_lcores == 0)
> > rte_exit(EXIT_FAILURE, "Number of lcores must be greater than 
> > 0\n");
> > +   if (nb_jobs == 0)
> > +   rte_exit(EXIT_FAILURE, "Number of jobs must be greater than 
> > 0\n");
> > if (distribute_qps_to_lcores(nb_lcores, nb_qps, &qps_per_lcore) < 0)
> > rte_exit(EXIT_FAILURE, "Failed to distribute queues to 
> > lcores!\n");
> > ret = init_port(&nb_max_payload, rules_file,

Re: [dpdk-dev] [PATCH 05/10] app/test: add null pointer check of memory allocation

[Thomas Monjalon]

19/04/2021 15:34, Min Hu (Connor):
> From: HongBo Zheng 
> 
> The rte_zmalloc is called in test_crc_calc without null pointer
> check. This patch adds null pointer checks on return value of
> rte_zmalloc.
> 
> Fixes: 9c77b848b1c1 ("test: add CRC computation")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: HongBo Zheng 
> Signed-off-by: Min Hu (Connor) 

Applied only this patch, thanks.

Re: [PATCH v3 1/2] examples/l3fwd: common packet group functionality

[Konstantin Ananyev]

23/06/2022 10:38, Rahul Bhansali пишет:

This will make the packet grouping function common, so
that other examples can utilize as per need.

For each architecture sse/neon/altivec, port group
headers will be created under examples/common/.

Signed-off-by: Rahul Bhansali 
---
Changes in v3: Created common port-group headers for
architectures sse/neon/altivec as suggested by Konstantin.

Changes in v2: New patch to address review comment.




Tested-by: Konstantin Ananyev 
Acked-by: Konstantin Ananyev 





--
2.25.1

Re: [PATCH] net/bnxt: reduce barriers in NEON vector Rx

[Ajit Khaparde]

On Sun, Jun 12, 2022 at 11:22 PM Ruifeng Wang  wrote:
>
> To read descriptors in expected order, barriers are inserted after each
> descriptor read. The excessive use of barriers is unnecessary and could
> cause performance drop.
>
> Removed barriers between descriptor reads. And changed counting of valid
> packets so as to handle discontinuous valid packets. Because out of
> order read could lead to valid descriptors that fetched being
> discontinuous.
>
> In VPP L3 routing test, 6% performance gain was observed. The test was
> done on a platform with ThunderX2 CPU and Broadcom PS225 NIC.
>
> Signed-off-by: Ruifeng Wang 
Reviewed-by: Ajit Khaparde 

Patch applied to dpdk-next-net-brcm. Thanks

>
> ---
>  drivers/net/bnxt/bnxt_rxtx_vec_neon.c | 47 ++-
>  1 file changed, 25 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c 
> b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
> index 32f8e59b3a..6a4ece681b 100644
> --- a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
> +++ b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
> @@ -235,34 +235,32 @@ recv_burst_vec_neon(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>  * IO barriers are used to ensure consistent state.
>  */
> rxcmp1[3] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 7]);
> -   rte_io_rmb();
> +   rxcmp1[2] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 5]);
> +   rxcmp1[1] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 3]);
> +   rxcmp1[0] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 1]);
> +
> +   /* Use acquire fence to order loads of descriptor words. */
> +   rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
> /* Reload lower 64b of descriptors to make it ordered after 
> info3_v. */
> rxcmp1[3] = vreinterpretq_u32_u64(vld1q_lane_u64
> ((void *)&cpr->cp_desc_ring[cons + 7],
> vreinterpretq_u64_u32(rxcmp1[3]), 0));
> -   rxcmp[3] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 6]);
> -
> -   rxcmp1[2] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 5]);
> -   rte_io_rmb();
> rxcmp1[2] = vreinterpretq_u32_u64(vld1q_lane_u64
> ((void *)&cpr->cp_desc_ring[cons + 5],
> vreinterpretq_u64_u32(rxcmp1[2]), 0));
> -   rxcmp[2] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 4]);
> -
> -   t1 = vreinterpretq_u64_u32(vzip2q_u32(rxcmp1[2], rxcmp1[3]));
> -
> -   rxcmp1[1] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 3]);
> -   rte_io_rmb();
> rxcmp1[1] = vreinterpretq_u32_u64(vld1q_lane_u64
> ((void *)&cpr->cp_desc_ring[cons + 3],
> vreinterpretq_u64_u32(rxcmp1[1]), 0));
> -   rxcmp[1] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 2]);
> -
> -   rxcmp1[0] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 1]);
> -   rte_io_rmb();
> rxcmp1[0] = vreinterpretq_u32_u64(vld1q_lane_u64
> ((void *)&cpr->cp_desc_ring[cons + 1],
> vreinterpretq_u64_u32(rxcmp1[0]), 0));
> +
> +   rxcmp[3] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 6]);
> +   rxcmp[2] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 4]);
> +
> +   t1 = vreinterpretq_u64_u32(vzip2q_u32(rxcmp1[2], rxcmp1[3]));
> +
> +   rxcmp[1] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 2]);
> rxcmp[0] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 0]);
>
> t0 = vreinterpretq_u64_u32(vzip2q_u32(rxcmp1[0], rxcmp1[1]));
> @@ -278,16 +276,21 @@ recv_burst_vec_neon(void *rx_queue, struct rte_mbuf 
> **rx_pkts, uint16_t nb_pkts)
>  * bits and count the number of set bits in order to determine
>  * the number of valid descriptors.
>  */
> -   valid = 
> vget_lane_u64(vreinterpret_u64_u16(vqmovn_u32(info3_v)),
> - 0);
> +   valid = vget_lane_u64(vreinterpret_u64_s16(vshr_n_s16
> +   (vreinterpret_s16_u16(vshl_n_u16
> +   (vqmovn_u32(info3_v), 15)), 15)), 0);
> +
> /*
>  * At this point, 'valid' is a 64-bit value containing four
> -* 16-bit fields, each of which is either 0x0001 or 0x.
> -* Compute number of valid descriptors from the index of
> -* the highest non-zero field.
> +* 16-bit fields, each of which is either 0x or 0x.
> +* Count the number of consecutive 1s from LSB in order to
> +* determine the number of valid descriptors.
>

Re: [dpdk-dev] [PATCH 0/8] bnxt PMD fixes

[Ajit Khaparde]

On Wed, Jun 15, 2022 at 7:57 AM Kalesh A P
 wrote:
>
> From: Kalesh AP 
>
> This patchset contains bug fixes in bnxt PMD.

Patchset applied to dpdk-next-net-brcm. Thanks

>
> Ajit Khaparde (1):
>   net/bnxt: fix switch domain allocation
>
> Damodharam Ammepalli (3):
>   net/bnxt: allow Tx only or Rx only configs in PMD
>   net/bnxt: disallow MTU change when device is started
>   net/bnxt: cleanups in MTU set callback
>
> Kalesh AP (2):
>   net/bnxt: reduce the verbosity of a log
>   net/bnxt: fix setting forced speed
>
> Somnath Kotur (2):
>   net/bnxt: remove assert for zero data len in Tx path
>   net/bnxt: fix the check for autoneg enablement in the PHY FW
>
>  drivers/net/bnxt/bnxt_ethdev.c | 95 
> ++
>  drivers/net/bnxt/bnxt_hwrm.c   | 45 +---
>  drivers/net/bnxt/bnxt_hwrm.h   |  3 ++
>  drivers/net/bnxt/bnxt_rxq.c|  9 +---
>  drivers/net/bnxt/bnxt_txr.c| 29 +++--
>  5 files changed, 101 insertions(+), 80 deletions(-)
>
> --
> 2.10.1
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] examples/l2fwd: add check of Rx packets count

[Thomas Monjalon]

Please could we have some tests on other hardware with this improvement?


25/05/2022 11:13, Rahul Bhansali:
> An additional check is added to avoid extra processing if
> receive packets are 0.
> 
> Performance impact: with Marvell OCTEON TX2 platform, observed an
> improvement by ~14%.
> 
> Signed-off-by: Rahul Bhansali 
> ---
>   nb_rx = rte_eth_rx_burst(portid, 0,
>pkts_burst, MAX_PKT_BURST);
>  
> + if (unlikely(nb_rx == 0))
> + continue;
> +

Re: [PATCH] ethtool: remove a redundant call to rte_eth_dev_stop()

[Thomas Monjalon]

27/05/2022 08:42, Usman Tanveer:
> There is a call to rte_eth_dev_stop() in rte_ethtool_net_open()
> due to which user gets misleading message upon first open/start call.
> It says that the
> device is already stopped, which should not be the case. This patch
> removes rte_eth_dev_stop() from rte_ethtool_net_open().

Why was it there?
Any opinion? Is it safe to remove?

>  int
>  rte_ethtool_net_open(uint16_t port_id)
>  {
> - int ret;
> -
> - ret = rte_eth_dev_stop(port_id);
> - if (ret != 0)
> - return ret;
> -
>   return rte_eth_dev_start(port_id);
>  }

Re: [PATCH] examples/link_status_interrupt: fix stats refresh rate

[Thomas Monjalon]

30/05/2022 11:37, Raja Zidane:
> TIMER_MILLISECOND is defined as the number of cpu cycles per millisecond,
> current definition is correct for cores with frequency of 2GHZ, for cores
> with different frequency, it caused different periods between refresh,
> (i.e. the definition is about 14ms on ARM cores).
> 
> Use dpdk API to get CPU frequency, to define TIMER_MILLISECOND.
> 
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Raja Zidane 
> Acked-by: Matan Azrad 
> ---
> --- a/examples/link_status_interrupt/main.c
> +++ b/examples/link_status_interrupt/main.c
>  /* A tsc-based timer responsible for triggering statistics printout */
> -#define TIMER_MILLISECOND 200ULL /* around 1ms at 2 Ghz */
> +#define TIMER_MILLISECOND (rte_get_tsc_hz() / 1000)

It is preferred to use rte_get_timer_hz().

>  #define MAX_TIMER_PERIOD 86400 /* 1 day max */
> -static int64_t timer_period = 10 * TIMER_MILLISECOND * 1000; /* default 
> period is 10 seconds */
> +#define DEFAULT_TIMER_PERIOD 10UL /* default period is 10 seconds */
> +static int64_t timer_period;
[...]
> + timer_period = DEFAULT_TIMER_PERIOD;

After a quick look, it seems we are missing the operation
* TIMER_MILLISECOND * 1000
Isn't it?

Re: [PATCH] examples/distributor: fix syntax on single core rx and distributor

[Thomas Monjalon]

21/06/2022 10:44, Hunt, David:
> On 20/06/2022 18:10, Ferruh Yigit wrote:
> > On 6/20/2022 5:31 PM, Abdullah Ömer Yamaç wrote:
> >> This patch fixes the syntax error when using the single-core
> >> for both rx and distributor functions.
> >>
> >> Fixes: 4a7f40c0ff9a ("examples/distributor: add dedicated core")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Abdullah Ömer Yamaç 
> >
> > Acked-by: Ferruh Yigit 
> >
> > Can we convert compile time macro to dynamic configuration to prevent 
> > build errors like this?
> 
> +1 for the dynamic config. Maybe a "-c" on the command line for "combine 
> rx and dist threads"?
> 
> Tested-by: David Hunt 

Applied this fix, thanks.
Improvement with dynamic option can come later.

Re: [PATCH 22.07] doc: make doc roadmap common for Linux/BSD GSGs

[Thomas Monjalon]

14/06/2022 16:12, Mcnamara, John:
> From: Bruce Richardson 
> > Both the Linux and FreeBSD GSG docs had a "Documentation Roadmap"
> > section as part of the introduction page, and this contained the same
> > information, with only the reference to the GSGs themselves being
> > different. This text can be consolidated into a single text file which is
> > included by both GSG intro sections - using relative links for the self
> > reference.
> 
> Good idea.
> 
> Acked-by: John McNamara 

We already have a file doc/guides/linux_gsg/eal_args.include.rst
I'll keep the format .include.rst for such file.

Applied with this update, thanks.

Re: [PATCH 1/1] test/pmd_perf: handling of unknown connection speed

[Ajit Khaparde]

On Sun, Jun 26, 2022 at 8:15 AM Thomas Monjalon  wrote:
>
> 11/05/2022 18:33, Heinrich Schuchardt:
> > When running DPDK in QEMU it cannot determine the connection speed.
> > pmd_perf_autotest treats this as if the connection speed where
> > UNIT32_MAX Mbps:
> >
> > RTE>>pmd_perf_autotest
> > Start PMD RXTX cycles cost test.
> > Allocated mbuf pool on socket 0
> > CONFIG RXD=1024 TXD=1024
> > Performance test runs on lcore 1 socket 0
> > Port 0 Address:52:54:00:12:34:57
> > Port 1 Address:52:54:00:12:34:58
> > Checking link statuses...
> > Port 0 Link up at Unknown FDX Autoneg
> > Port 1 Link up at Unknown FDX Autoneg
> > IPv4 pktlen 46
> > UDP pktlen 26
> > Generate 4096 packets @socket 0
> > inject 2048 packet to port 0
> > inject 2048 packet to port 1
> > Total packets inject to prime ports = 4096
> > Each port will do 6391320379464 packets per second
> > Test will stop after at least 25565281517856 packets received
> >
> > This will not allow the test to terminate in a reasonable timespan.
> > Just assume 10 Gbps in this case instead:
> >
> > ...
> > Test will stop after at least 59523808 packets received
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  app/test/test_pmd_perf.c | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
> > index 25611bfe9b..ee08c8aade 100644
> > --- a/app/test/test_pmd_perf.c
> > +++ b/app/test/test_pmd_perf.c
> > @@ -486,10 +486,17 @@ main_loop(__rte_unused void *args)
> >   }
> >   printf("Total packets inject to prime ports = %u\n", idx);
> >
> > - packets_per_second = (link_mbps * 1000 * 1000) /
> > - ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> > - printf("Each port will do %"PRIu64" packets per second\n",
> > -packets_per_second);
> > + if (link_mbps != RTE_ETH_SPEED_NUM_UNKNOWN) {
> > + packets_per_second = (link_mbps * 1000 * 1000) /
> > + ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> > + printf("Each port will do %"PRIu64" packets per second\n",
> > +packets_per_second);
> > + total_packets = RTE_TEST_DURATION * conf->nb_ports * 
> > packets_per_second;
>
> This is redundant with below.
>
> > + } else {
> > + /* We don't know the speed. Pretend it is 10G */
> > + packets_per_second = ((uint64_t)RTE_ETH_SPEED_NUM_10G * 1000 
> > * 1000) /
> > + ((PACKET_SIZE + FRAME_GAP + MAC_PREAMBLE) * CHAR_BIT);
> > + }
> >
> >   total_packets = RTE_TEST_DURATION * conf->nb_ports * 
> > packets_per_second;
>
> Why not just inserting this:
>
> if (link_mbps == RTE_ETH_SPEED_NUM_UNKNOWN)
> link_mbps = RTE_ETH_SPEED_NUM_10G;
+1
I think this is better.

>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v4 0/5] Improve documentation for running as non-root

[Thomas Monjalon]

> Dmitry Kozlyuk (5):
>   usertools: add option to select hugetlbfs directory
>   usertools: add options to change mount point owner
>   doc: give specific instructions for running as non-root
>   doc: update instructions for running as non-root for MLX5
>   doc: add note about running virtio-legacy as non-root

Applied, thanks.

Re: [dpdk-dev] [PATCH 0/8] bnxt PMD fixes

[Thomas Monjalon]

26/06/2022 22:45, Ajit Khaparde:
> On Wed, Jun 15, 2022 at 7:57 AM Kalesh A P
>  wrote:
> >
> > From: Kalesh AP 
> >
> > This patchset contains bug fixes in bnxt PMD.
> 
> Patchset applied to dpdk-next-net-brcm. Thanks

It is very late for -rc2, but it has found its way at last minute.

release candidate 22.07-rc2

[Thomas Monjalon]

A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v22.07-rc2

There are 317 new patches in this snapshot.

Release notes:
https://doc.dpdk.org/guides/rel_notes/release_22_07.html

There were a lot of updates in drivers.
The driver features should be frozen now.

Please test and report issues on bugs.dpdk.org.
Do not forget to review examples and documentation updates.

DPDK 22.07-rc3 is expected in one week (targetting end of June).

Thank you everyone

[PATCH] doc: add release notes for async vhost dequeue data-path

[Cheng Jiang]

Add release notes for asynchronous vhost dequeue data-path. Emphasize
that split virtqueue and packed virtqueue are both supported in
asynchronous vhost dequeue data-path

Signed-off-by: Cheng Jiang 
---
 doc/guides/rel_notes/release_22_07.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_22_07.rst 
b/doc/guides/rel_notes/release_22_07.rst
index e743031f61..2594ddcec1 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -102,7 +102,8 @@ New Features
 * **Added vhost async dequeue API to receive packets from guest.**
 
   Added vhost async dequeue API which can leverage DMA devices to
-  accelerate receiving packets from guest.
+  accelerate receiving packets from guest. Split virtqueue and packed
+  virtqueue are both supported.
 
 * **Added vhost API to get the device type of a vDPA device.**
 
-- 
2.35.1

[PATCH v2] doc: add release notes for async vhost dequeue data-path

[Cheng Jiang]

Add release notes for asynchronous vhost dequeue data-path. Emphasize
that split virtqueue and packed virtqueue are both supported in
asynchronous vhost dequeue data-path.

Signed-off-by: Cheng Jiang 
---
v2: fixed a full stop missing in the commit message.

 doc/guides/rel_notes/release_22_07.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_22_07.rst 
b/doc/guides/rel_notes/release_22_07.rst
index e743031f61..2594ddcec1 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -102,7 +102,8 @@ New Features
 * **Added vhost async dequeue API to receive packets from guest.**

   Added vhost async dequeue API which can leverage DMA devices to
-  accelerate receiving packets from guest.
+  accelerate receiving packets from guest. Split virtqueue and packed
+  virtqueue are both supported.

 * **Added vhost API to get the device type of a vDPA device.**

--
2.35.1

Re: [dpdk-dev] [PATCH 0/8] bnxt PMD fixes

[Ajit Khaparde]

On Sun, Jun 26, 2022 at 7:08 PM Thomas Monjalon  wrote:
>
> 26/06/2022 22:45, Ajit Khaparde:
> > On Wed, Jun 15, 2022 at 7:57 AM Kalesh A P
> >  wrote:
> > >
> > > From: Kalesh AP 
> > >
> > > This patchset contains bug fixes in bnxt PMD.
> >
> > Patchset applied to dpdk-next-net-brcm. Thanks
>
> It is very late for -rc2, but it has found its way at last minute.
Thanks Thomas.

>
>


smime.p7s
Description: S/MIME Cryptographic Signature

RE: [PATCH] app/testpmd: fix secondary process cannot dump packet

[Zhang, Yuying]

Hi Peng,

> -Original Message-
> From: Zhang, Peng1X 
> Sent: Friday, June 24, 2022 2:15 AM
> To: dev@dpdk.org
> Cc: Singh, Aman Deep ; Zhang, Yuying
> ; Zhang, Peng1X ;
> sta...@dpdk.org
> Subject: [PATCH] app/testpmd: fix secondary process cannot dump packet
> 
> From: Peng Zhang 
> 
> The origin design is whether testpmd is primary or not, if state of receive
> queue is stop, then packets will not be dumped for show.
> While to secondary process, receive queue will not be set up, and state will
> still be stop even if testpmd is started. So packets of stated secondary
> process cannot be dumped for show.

Current description is confusing. Please refine the commit log to define the 
issue clearly.

> 
> The current design is to secondary process state of queue will be set to start
> after testpmd is started. Then packets of started secondary process can be
> dumped for show.
> 
> Fixes: a550baf24af9 ("app/testpmd: support multi-process")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Peng Zhang 
> ---
>  app/test-pmd/testpmd.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 205d98ee3d..93ba7e7c9b 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -3007,6 +3007,18 @@ start_port(portid_t pid)
>   if (setup_hairpin_queues(pi, p_pi, cnt_pi) != 0)
>   return -1;
>   }
> +
> + if (port->need_reconfig_queues > 0 && !is_proc_primary()) {
> + struct rte_eth_rxconf *rx_conf;
> + for (qi = 0; qi < nb_rxq; qi++) {
> + rx_conf = &(port->rxq[qi].conf);
> + ports[pi].rxq[qi].state =
> + rx_conf->rx_deferred_start ?
> + RTE_ETH_QUEUE_STATE_STOPPED :
> + RTE_ETH_QUEUE_STATE_STARTED;
> + }
> + }
> +
>   configure_rxtx_dump_callbacks(verbose_level);
>   if (clear_ptypes) {
>   diag = rte_eth_dev_set_ptypes(pi,
> RTE_PTYPE_UNKNOWN,
> --
> 2.25.1

[PATCH v2 1/1] doc: announce addition of new ipsec event subtypes

[Vamsi Attunuru]

New event subtypes need to be added for notifying expiry events
upon reaching IPsec SA soft packet expiry and hard packet/byte
expiry limits. This would be added in DPDK 22.11.

Signed-off-by: Vamsi Attunuru 
Acked-by: Akhil Goyal 
---
More details on new event subtype proposal discussion are in below email thread.
https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-gak...@marvell.com/

v2: rephrase title and git log.
---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c53d..83da1c62ac 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -107,6 +107,11 @@ Deprecation Notices
   alternative is implemented.
   The legacy actions should be removed in DPDK 22.11.
 
+* ethdev: The enum ``rte_eth_event_ipsec_subtype`` would be extended to add
+  new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,
+  ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and
+  ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.
+
 * cryptodev: Hide structures ``rte_cryptodev_sym_session`` and
   ``rte_cryptodev_asym_session`` to remove unnecessary indirection between
   session and the private data of session. An opaque pointer can be exposed
-- 
2.25.1

[PATCH v2] net/vhost: fix deadlock on vring state change

[Yuan Wang]

If vring state changes after pmd starts working, the locked vring
notifies pmd, thus calling update_queuing_status(), the latter
will wait for pmd to finish accessing vring, while pmd is also
waiting for vring to be unlocked, thus causing deadlock.

Actually, update_queuing_status() only needs to wait while
destroy/stopping the device, but not in other cases.

This patch adds a flag for whether or not to wait to fix this issue.

Fixes: 1ce3c7fe149f ("net/vhost: emulate device start/stop behavior")
Cc: sta...@dpdk.org

Signed-off-by: Yuan Wang 
---
V2: rewrite the commit log.
---
 drivers/net/vhost/rte_eth_vhost.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index d75d256040..7e512d94bf 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -741,7 +741,7 @@ eth_vhost_install_intr(struct rte_eth_dev *dev)
 }
 
 static void
-update_queuing_status(struct rte_eth_dev *dev)
+update_queuing_status(struct rte_eth_dev *dev, bool wait_queuing)
 {
struct pmd_internal *internal = dev->data->dev_private;
struct vhost_queue *vq;
@@ -767,7 +767,7 @@ update_queuing_status(struct rte_eth_dev *dev)
rte_atomic32_set(&vq->allow_queuing, 1);
else
rte_atomic32_set(&vq->allow_queuing, 0);
-   while (rte_atomic32_read(&vq->while_queuing))
+   while (wait_queuing && rte_atomic32_read(&vq->while_queuing))
rte_pause();
}
 
@@ -779,7 +779,7 @@ update_queuing_status(struct rte_eth_dev *dev)
rte_atomic32_set(&vq->allow_queuing, 1);
else
rte_atomic32_set(&vq->allow_queuing, 0);
-   while (rte_atomic32_read(&vq->while_queuing))
+   while (wait_queuing && rte_atomic32_read(&vq->while_queuing))
rte_pause();
}
 }
@@ -868,7 +868,7 @@ new_device(int vid)
vhost_dev_csum_configure(eth_dev);
 
rte_atomic32_set(&internal->dev_attached, 1);
-   update_queuing_status(eth_dev);
+   update_queuing_status(eth_dev, false);
 
VHOST_LOG(INFO, "Vhost device %d created\n", vid);
 
@@ -898,7 +898,7 @@ destroy_device(int vid)
internal = eth_dev->data->dev_private;
 
rte_atomic32_set(&internal->dev_attached, 0);
-   update_queuing_status(eth_dev);
+   update_queuing_status(eth_dev, true);
 
eth_dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
 
@@ -1008,7 +1008,7 @@ vring_state_changed(int vid, uint16_t vring, int enable)
state->max_vring = RTE_MAX(vring, state->max_vring);
rte_spinlock_unlock(&state->lock);
 
-   update_queuing_status(eth_dev);
+   update_queuing_status(eth_dev, false);
 
VHOST_LOG(INFO, "vring%u is %s\n",
vring, enable ? "enabled" : "disabled");
@@ -1197,7 +1197,7 @@ eth_dev_start(struct rte_eth_dev *eth_dev)
}
 
rte_atomic32_set(&internal->started, 1);
-   update_queuing_status(eth_dev);
+   update_queuing_status(eth_dev, false);
 
return 0;
 }
@@ -1209,7 +1209,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
 
dev->data->dev_started = 0;
rte_atomic32_set(&internal->started, 0);
-   update_queuing_status(dev);
+   update_queuing_status(dev, true);
 
return 0;
 }
-- 
2.25.1

RE: [EXT] [PATCH 1/2] test/crypto: fix zuc test vector IV format

[Tejasree Kondoj]

Acked-by: Tejasree Kondoj 

> -Original Message-
> From: Ciara Power 
> Sent: Thursday, June 23, 2022 8:13 PM
> To: Akhil Goyal ; Fan Zhang
> 
> Cc: dev@dpdk.org; kai...@intel.com; pablo.de.lara.gua...@intel.com;
> Tejasree Kondoj ; Ciara Power
> ; arkadiuszx.kusz...@intel.com; sta...@dpdk.org
> Subject: [EXT] [PATCH 1/2] test/crypto: fix zuc test vector IV format
> 
> External Email
> 
> --
> Some authentication and cipher IV formats were not following the spec [1].
> 
> For ZUC128 cipher IV, an 8 byte block is repeated, with the last 3 bytes of
> each being 0x0.
> IV[4] and IV[12] must have the last 2 bits set to 0.
> 
> Auth IVs must also have repeated bytes with the last 3 bytes containing 0x0
> in each 8 byte block.
> IV[4] and IV[12] must have the last 3 bits set to 0.
> IV[8] and IV[14] may have a flipped bit based on direction.
> 
> [1] https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.gsma.com_security_wp-2Dcontent_uploads_2019_05_EEA3-
> 5FEIA3-5Fspecification-5Fv1-
> 5F8.pdf&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=NjpqGUAf6Xc0ZLzxCvv
> 4idf8zRFeSJHioNlG1Wif1Gs&m=fBghjXYEElUgAXJtsiS2rol3rtkR155ftFsgE-
> jC6QA9kkKONba0SENdDyRjwcvv&s=LEfRBY1bfwSrbkxNfU44OMqyX2RrbqH6l
> GcxOA5U-pc&e=
> 
> Fixes: a81a81850fb1 ("test/crypto: add ZUC test cases for QAT")
> Fixes: b1c1df46878d ("test/crypto: add ZUC test cases for auth-cipher")
> Cc: arkadiuszx.kusz...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ciara Power 
> ---
>  app/test/test_cryptodev_zuc_test_vectors.h | 54 +++---
>  1 file changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_zuc_test_vectors.h
> b/app/test/test_cryptodev_zuc_test_vectors.h
> index 5d1d264579..299d7649fe 100644
> --- a/app/test/test_cryptodev_zuc_test_vectors.h
> +++ b/app/test/test_cryptodev_zuc_test_vectors.h
> @@ -558,13 +558,13 @@ static struct wireless_test_data
> zuc_test_case_cipher_200b_auth_200b = {
>   },
>   .auth_iv = {
>   .data = {
> - 0xFA, 0x55, 0x6B, 0x26, 0x1C, 0x00, 0x00, 0x00,
> - 0xFA, 0x55, 0x6B, 0x26, 0x1C, 0x00, 0x00, 0x00
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00,
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
>   .digest = {
> - .data = {0x01, 0xFE, 0x5E, 0x38},
> + .data = {0x2F, 0x45, 0x7D, 0x7B},
>   .len  = 4
>   },
>   .validAuthLenInBits = {
> @@ -631,13 +631,13 @@ static struct wireless_test_data
> zuc_test_case_cipher_800b_auth_120b = {
>   },
>   .auth_iv = {
>   .data = {
> - 0xFA, 0x55, 0x6B, 0x26, 0x1C, 0x00, 0x00, 0x00,
> - 0xFA, 0x55, 0x6B, 0x26, 0x1C, 0x00, 0x00, 0x00
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00,
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
>   .digest = {
> - .data = {0x9D, 0x42, 0x1C, 0xEA},
> + .data = {0xCA, 0xBB, 0x8D, 0x94},
>   .len  = 4
>   },
>   .validAuthLenInBits = {
> @@ -1166,15 +1166,15 @@ struct wireless_test_data
> zuc_auth_cipher_test_case_1 = {
>   },
>   .cipher_iv = {
>   .data = {
> - 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> + 0x66, 0x03, 0x54, 0x92, 0x78, 0x00, 0x00, 0x00,
> + 0x66, 0x03, 0x54, 0x92, 0x78, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
>   .auth_iv = {
>   .data = {
> - 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00,
> + 0xFA, 0x55, 0x6B, 0x26, 0x18, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
> @@ -1201,22 +1201,22 @@ struct wireless_test_data
> zuc_auth_cipher_test_case_1 = {
>   },
>   .ciphertext = {
>   .data = {
> - 0x5A, 0x5A, 0xDB, 0x3D, 0xD5, 0xB7, 0xB9, 0x58,
> - 0xA5, 0xD3, 0xE3, 0xF9, 0x18, 0x73, 0xB4, 0x74,
> - 0x05, 0xF0, 0xE9, 0xB6, 0x5D, 0x9A, 0xE3, 0xFA,
> - 0x5D, 0xFD, 0x24, 0x51, 0xAD, 0x73, 0xCA, 0x64,
> - 0x91, 0xD5, 0xB3, 0x94, 0x10, 0x91, 0x89, 0xEA,
> - 0x73, 0x6F, 0xB0, 0x2A, 0x0A, 0x63, 0x0F, 0x8D,
> - 0x64, 0x87, 0xA3, 0x14, 0x6B, 0x93, 0x31, 0x0F,
> - 0x14, 0xAD, 0xEA, 0x62, 0x80, 0x3F, 0x44, 0xDD,
> - 0x4E, 0x30, 0xFA, 0xC8, 0x0E, 0x5F, 0x46, 0xE7,
> - 0x60, 0xEC, 0xDF, 0x8

RE: [EXT] [PATCH 2/2] test/crypto: fix snow3g test vector IV format

[Tejasree Kondoj]

Acked-by: Tejasree Kondoj 

> -Original Message-
> From: Ciara Power 
> Sent: Thursday, June 23, 2022 8:13 PM
> To: Akhil Goyal ; Fan Zhang
> 
> Cc: dev@dpdk.org; kai...@intel.com; pablo.de.lara.gua...@intel.com;
> Tejasree Kondoj ; Ciara Power
> ; deepak.k.j...@intel.com;
> lukaszx.krakow...@intel.com; sta...@dpdk.org
> Subject: [EXT] [PATCH 2/2] test/crypto: fix snow3g test vector IV format
> 
> External Email
> 
> --
> Some of the cipher and authentication IVs did not follow the spec for
> SNOW3G algorithm [1].
> 
> Cipher IVs must have the last 3 bytes of each 8 byte block as 0x0.
> IV[4] and IV[12] must have the last 2 bits set to 0.
> Each 8 byte block is repeated.
> 
> Auth IVs must also have a repeated 8 byte block.
> IV[8] and IV[14] may have a flipped bit based on direction.
> 
> [1] https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.gsma.com_aboutus_wp-
> 2Dcontent_uploads_2014_12_uea2uia2d1v21.pdf&d=DwIDAg&c=nKjWec2b6
> R0mOyPaz7xtfQ&r=NjpqGUAf6Xc0ZLzxCvv4idf8zRFeSJHioNlG1Wif1Gs&m=W5
> E7AmIF8Aa_ttMpK850Xe-TbrKbdKU8KakdVPTXBxeQyxGLAD_VoFfwdjc_1hn-
> &s=YkfBB-_8R5LDn_vBmEhRNUKeIom1lSMXP3ujAU8V72k&e=
> 
> Fixes: 8bdf665fe6c0 ("app/test: add SNOW 3G")
> Fixes: 24342ade2c9d ("test/crypto: check SNOW3G when digest is
> encrypted")
> Fixes: 02ed7b3871d6 ("test/crypto: add SNOW3G test cases for auth-cipher")
> Fixes: 11c5485bb276 ("test/crypto: add scatter-gather tests for IP and OOP")
> Cc: deepak.k.j...@intel.com
> Cc: lukaszx.krakow...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ciara Power 
> ---
>  app/test/test_cryptodev_snow3g_test_vectors.h | 142 +-
>  1 file changed, 71 insertions(+), 71 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_snow3g_test_vectors.h
> b/app/test/test_cryptodev_snow3g_test_vectors.h
> index bbe05662be..b49a07bcf2 100644
> --- a/app/test/test_cryptodev_snow3g_test_vectors.h
> +++ b/app/test/test_cryptodev_snow3g_test_vectors.h
> @@ -138,11 +138,11 @@ struct snow3g_test_data snow3g_test_case_2 = {
>   .len = 16
>   },
>   .cipher_iv = {
> -.data = {
> + .data = {
>   0xE2, 0x8B, 0xCF, 0x7B, 0xC0, 0x00, 0x00, 0x00,
>   0xE2, 0x8B, 0xCF, 0x7B, 0xC0, 0x00, 0x00, 0x00
>   },
> -.len = 16
> + .len = 16
>   },
>   .plaintext = {
>   .data = {
> @@ -359,8 +359,8 @@ struct snow3g_test_data
> snow3g_auth_cipher_test_case_1 = {
>   },
>   .cipher_iv = {
>   .data = {
> - 0x14, 0x79, 0x3E, 0x41, 0x03, 0x97, 0xE8, 0xFD,
> - 0x94, 0x79, 0x3E, 0x41, 0x03, 0x97, 0x68, 0xFD
> + 0x72, 0xA4, 0xF2, 0x0F, 0x48, 0x00, 0x00, 0x00,
> + 0x72, 0xA4, 0xF2, 0x0F, 0x48, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
> @@ -383,13 +383,13 @@ struct snow3g_test_data
> snow3g_auth_cipher_test_case_1 = {
>   .len = 384
>   },
>   .ciphertext = {
> -.data = {
> - 0x95, 0x2E, 0x5A, 0xE1, 0x50, 0xB8, 0x59, 0x2A,
> - 0x9B, 0xA0, 0x38, 0xA9, 0x8E, 0x2F, 0xED, 0xAB,
> - 0xFD, 0xC8, 0x3B, 0x47, 0x46, 0x0B, 0x50, 0x16,
> - 0xEC, 0x88, 0x45, 0xB6, 0x05, 0xC7, 0x54, 0xF8,
> - 0xBD, 0x91, 0xAA, 0xB6, 0xA4, 0xDC, 0x64, 0xB4,
> - 0xCB, 0xEB, 0x97, 0x06, 0x4C, 0xF7, 0x02, 0x3D
> +   .data = {
> + 0x86, 0x4F, 0x4D, 0xE8, 0x86, 0xE6, 0x3E, 0x66,
> + 0x52, 0x97, 0xC7, 0x62, 0xAE, 0x8E, 0xA2, 0xDB,
> + 0x01, 0xD6, 0x33, 0xA9, 0xA4, 0xCE, 0x02, 0xD5,
> + 0xC2, 0xC5, 0x5F, 0x90, 0xE0, 0x89, 0x48, 0xD4,
> + 0x92, 0xF4, 0xE5, 0x9A, 0xDA, 0x13, 0x76, 0xFF,
> + 0x6E, 0x76, 0x6B, 0x71, 0x62, 0x28, 0xB2, 0xEC
>   },
>   .len = 384
>   },
> @@ -428,15 +428,15 @@ struct snow3g_test_data snow3g_test_case_7 = {
>   },
>   .cipher_iv = {
>   .data = {
> - 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
> - 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
> + 0xE2, 0x8B, 0xCF, 0x7B, 0xC0, 0x00, 0x00, 0x00,
> + 0xE2, 0x8B, 0xCF, 0x7B, 0xC0, 0x00, 0x00, 0x00
>   },
>   .len = 16
>   },
>   .auth_iv = {
>   .data = {
> -  0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
> -  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> + 0x36, 0xAF, 0x61, 0x44, 0x98, 0x38, 0xF0, 0x3A,
> + 0x36, 0xAF, 0x61, 0x44, 0x98, 0x38, 0xF0, 0x3A
>   },
>   .len = 16
>   },
> @@ -457,28 +457,28 @@ struct snow3g_test_data snow3g_test_case_7 = {
> 

RE: ask for TXA_FLUSH_THRESHOLD change

[Jayatheerthan, Jay]

Hi,
>From DPDK 21.11, the Rx adapter event buffer size is configurable through API 
>during creation time. Please refer to 
>rte_event_eth_rx_adapter_create_with_params() API in the below link:
https://doc.dpdk.org/api/rte__event__eth__rx__adapter_8h.html

You could refer to EAL docs on how to use log-level option based on the PMD you 
are using.

-Jay



From: Jaeeun Ham 
Sent: Saturday, June 25, 2022 8:49 AM
To: Jayatheerthan, Jay ; dev@dpdk.org
Cc: Jerin Jacob 
Subject: RE: ask for TXA_FLUSH_THRESHOLD change

Hi,

Packets seem to be silently discarded in the RX NIC while waiting in the 
buffer, and it does not happen when I use only one worker core.
I think multiple worker cores packet processing would have this problem to 
handle heavy traffic in parallel.

I want to increase buffer size to solve this as below, then is it right to 
change only modify the number from 4 to 8?
I am trying to gather DPDK and PMD driver log such as "--log-level="7" 
--log-level="pmd.net,7". Could you recommend how to set the log-level string to 
confirm silent packet drop?

dpdk-stable-20.11.1/lib/librte_eventdev/rte_event_eth_rx_adapter.c

#define BATCH_SIZE  32
#define BLOCK_CNT_THRESHOLD 10
#define ETH_EVENT_BUFFER_SIZE   (4*BATCH_SIZE)  // e.g. (8*BATCH_SIZE)

#define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
#define ETH_RX_ADAPTER_MEM_NAME_LEN 32

#define RSS_KEY_SIZE40
/* value written to intr thread pipe to signal thread exit */
#define ETH_BRIDGE_INTR_THREAD_EXIT 1
/* Sentinel value to detect initialized file handle */
#define INIT_FD -1

BR/Jaeeun

From: Jaeeun Ham
Sent: Wednesday, June 22, 2022 11:14 AM
To: Jayatheerthan, Jay 
mailto:jay.jayatheert...@intel.com>>; 
dev@dpdk.org
Cc: Jerin Jacob mailto:jer...@marvell.com>>
Subject: RE: ask for TXA_FLUSH_THRESHOLD change

Hi,

Could you guide me on how to eliminate or reduce tx drop/retry?
TXA_FLUSH_THRESHOLD helped somewhat but it was not cleared packet tx drop.

[ TX adapter stats ]
tx_retry: 17499893
tx_packets: 7501716
tx_dropped: 5132458

BR/Jaeeun

From: Jayatheerthan, Jay 
mailto:jay.jayatheert...@intel.com>>
Sent: Thursday, June 16, 2022 3:40 PM
To: Jaeeun Ham mailto:jaeeun@ericsson.com>>; 
dev@dpdk.org
Cc: Jerin Jacob mailto:jer...@marvell.com>>
Subject: RE: ask for TXA_FLUSH_THRESHOLD change

Hi Jaeeun,
See my responses inline below.

-Jay


From: Jaeeun Ham mailto:jaeeun@ericsson.com>>
Sent: Monday, June 13, 2022 5:51 AM
To: dev@dpdk.org
Cc: Jerin Jacob mailto:jer...@marvell.com>>; Jayatheerthan, 
Jay mailto:jay.jayatheert...@intel.com>>
Subject: ask for TXA_FLUSH_THRESHOLD change

Hi,

There were latency delay when I increase dpdk(20.11.1) core. (one worker core 
was okay.)
When I decrease the TXA_FLUSH_THRESHOLD value(1024 to 32), it was okay

It's TXA_FLUSH_THRESHOLD at lib/librte_eventdev/rte_event_eth_tx_adapter.c. // 
https://git.dpdk.org/dpdk-stable/tree/lib/librte_eventdev/rte_event_eth_tx_adapter.c?h=20.11#n15
When TXA_FLUSH_THRESHOLD value was changed from 1024 to 32, the latency test 
result was fine on 10 cores for low traffic(DL:20Mbps/UL:17kbps).
I think that this can make call for rte_eth_tx_buffer_flush() more frequently.
But, I'm not sure whether this approach can cause worse performance or not.
Do you have any opinion about this?

[Jay] Yes, it will cause rte_eth_tx_buffer_flush() to be called more often. It 
can lead to lesser batching benefit. Typical performance vs. latency trade-off 
decision apply here.


Similar RDK RTE_BRIDGE_ETH_TX_FLUSH_THOLD is patched on DUSG3 from 1024 to 
smaller value since DPDK 18.11.2:
I'm not aware of any side-effect, I think it is needed to have low enough 
latency even at low traffic rates.  For more details see Intel FP 
22288.

[Jay] Currently, TXA_FLUSH_THRESHOLD is not a configurable attr.

TXA_MAX_NB_TX(128) looks the same as 
CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE(16384), then is it also should be tuned?

[Jay] They both are different attributes. TXA_MAX_NB_TX refers to max number of 
queues in Tx adapter. CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE refers to event 
buffer size in Rx BD.


--- dpdk-3pp-swu-18.11/dpdk-stable-18.11.2/config/common_base.orig  2020-01-29 
15:05:10.0 +0100
+++ dpdk-3pp-swu-18.11/dpdk-stable-18.11.2/config/common_base   2020-01-29 
15:11:10.0 +0100
@@ -566,9 +566,9 @@
CONFIG_RTE_LIBRTE_BRIDGE_ETH_MAX_CP_ENQ_RETRIES=100
CONFIG_RTE_MAX_BRIDGE_ETH_INSTANCE=4
CONFIG_RTE_BRIDGE_ETH_INTR_RING_SIZE=32
-CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE=128
+CONFIG_RTE_BRIDGE_ETH_EVENT_BUFFER_SIZE=16384
CONFIG_RTE_LIBRTE_BRIDGE_ETH_DEBUG=n
-CONFIG_RTE_BRIDGE_ETH_TX_FLUSH_