RE: [PATCH] net/mlx5: functions refactor for getting counter's action

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Haifei Luo 
> Sent: Monday, February 21, 2022 10:27 AM
> To: Matan Azrad ; Ori Kam ; Slava
> Ovsiienko ; Shahaf Shuler 
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Raslan Darawsheh 
> Subject: [PATCH] net/mlx5: functions refactor for getting counter's action
> 
> Previously API flow_dv_query_count_ptr is defined to get counter's
> action pointer. This dv function is directly called and the better
> way is by the callback.
> 
> Add one arg in API mlx5_counter_query and the related callback
> counter_query. The added arg is for counter's action pointer.
> 
> Signed-off-by: Haifei Luo 
> Acked-by: Viacheslav Ovsiienko 

Patch rebased and applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH 0/2] fix shared RxQ creation

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Michael Baum 
> Sent: Monday, February 14, 2022 11:00 AM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Slava Ovsiienko 
> Subject: [PATCH 0/2] fix shared RxQ creation
> 
> Fix error flow in RxQ creation and optimize it.
> 
> Michael Baum (2):
>   net/mlx5: fix invalid entry in shared RXQs list
>   net/mlx5: optimize RxQ creation
> 
>  drivers/net/mlx5/mlx5_rx.h  |  3 +--
>  drivers/net/mlx5/mlx5_rxq.c | 40 -
>  2 files changed, 18 insertions(+), 25 deletions(-)
> 
> --
> 2.25.1

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

[PATCH v1] eal/linux: fix memory illegal accesses

[Steve Yang]

'recv()' fills the 'buf', later 'strlcpy()' used to copy from this buffer.
But as coverity warns 'recv()' doesn't guarantee that 'buf' is
null-terminated, but 'strlcpy()' requires it.

Enlarge 'buf' size to 'EAL_UEV_MSG_LEN + 1' and ensure the last one can
be set to 0 when received buffer size is EAL_UEV_MSG_LEN.

CID 375864:  Memory - illegal accesses  (STRING_NULL)
Passing unterminated string "buf" to "dev_uev_parse", which expects
a null-terminated string.

Coverity issue: 375864
Fixes: 0d0f478d0483 ("eal/linux: add uevent parse and process")
Cc: sta...@dpdk.org

Signed-off-by: Steve Yang 
---
 lib/eal/linux/eal_dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/eal/linux/eal_dev.c b/lib/eal/linux/eal_dev.c
index bde55a3d92..851789e85c 100644
--- a/lib/eal/linux/eal_dev.c
+++ b/lib/eal/linux/eal_dev.c
@@ -231,13 +231,13 @@ dev_uev_handler(__rte_unused void *param)
 {
struct rte_dev_event uevent;
int ret;
-   char buf[EAL_UEV_MSG_LEN];
+   char buf[EAL_UEV_MSG_LEN + 1];
struct rte_bus *bus;
struct rte_device *dev;
const char *busname = "";
 
memset(&uevent, 0, sizeof(struct rte_dev_event));
-   memset(buf, 0, EAL_UEV_MSG_LEN);
+   memset(buf, 0, EAL_UEV_MSG_LEN + 1);
 
if (rte_intr_fd_get(intr_handle) < 0)
return;
-- 
2.27.0

[PATCH] net/ice: fix Tx offload path choice

[Kevin Liu]

Testpmd forwards packets in checksum mode that it needs to calculate
the checksum of each layer's protocol.

When setting the hardware calculates the outer UDP checksum and the
software calculates the outer IP checksum, the dev->tx_pkt_burst in
ice_set_tx_function is set to ice_xmit_pkts_vec_avx2.
The inner and outer UDP checksum of the tunnel packet after forwarding
is wrong.The dev->tx_pkt_burst should be set to ice_xmit_pkts.

The patch adds RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM to
ICE_TX_NO_VECTOR_FLAGS,set dev->tx_pkt_burst to ice_xmit_pkts.After
the tunnel packet is forwarded, the inner and outer UDP checksum is
correct.

At the same time, the patch of "net/ice: fix Tx Checksum offload" will
cause interrupt errors in a special case that only inner IP and inner
UDP checksum are set for hardware calculation.The patch is updating
ICE_TX_NO_VECTOR_FLAGS, the problem can be solved, so I will restore the
code modification of that patch.

Fixes: e6b9d6411e91 ("app/testpmd: add SW L4 checksum in multi-segments")
Fixes: 28f9002ab67f ("net/ice: add Tx AVX512 offload path")
Fixes: 295968d17407 ("ethdev: add namespace")
Fixes: 17c7d0f9d6a4 ("net/ice: support basic Rx/Tx")
Cc: sta...@dpdk.org

Signed-off-by: Kevin Liu 
---
 app/test-pmd/csumonly.c   |  6 +--
 drivers/net/ice/ice_rxtx.c| 41 ++-
 drivers/net/ice/ice_rxtx_vec_common.h | 59 +--
 3 files changed, 34 insertions(+), 72 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 02bc3929c7..c235456e58 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -513,7 +513,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
ol_flags |= RTE_MBUF_F_TX_UDP_CKSUM;
} else {
if (info->is_tunnel)
-   l4_off = info->l2_len +
+   l4_off = info->outer_l2_len +
 info->outer_l3_len +
 info->l2_len + info->l3_len;
else
@@ -536,7 +536,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
ol_flags |= RTE_MBUF_F_TX_TCP_CKSUM;
} else {
if (info->is_tunnel)
-   l4_off = info->l2_len + info->outer_l3_len +
+   l4_off = info->outer_l2_len + 
info->outer_l3_len +
 info->l2_len + info->l3_len;
else
l4_off = info->l2_len + info->l3_len;
@@ -625,7 +625,7 @@ process_outer_cksums(void *outer_l3_hdr, struct 
testpmd_offload_info *info,
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
udp_hdr->dgram_cksum = get_udptcp_checksum(m, outer_l3_hdr,
-   info->l2_len + info->outer_l3_len,
+   info->outer_l2_len + info->outer_l3_len,
info->outer_ethertype);
}
 
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 4f218bcd0d..041f4bc91f 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -2501,35 +2501,18 @@ ice_txd_enable_checksum(uint64_t ol_flags,
<< ICE_TX_DESC_LEN_MACLEN_S;
 
/* Enable L3 checksum offloads */
-   /*Tunnel package usage outer len enable L3 checksum offload*/
-   if (ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) {
-   if (ol_flags & RTE_MBUF_F_TX_IP_CKSUM) {
-   *td_cmd |= ICE_TX_DESC_CMD_IIPT_IPV4_CSUM;
-   *td_offset |= (tx_offload.outer_l3_len >> 2) <<
-   ICE_TX_DESC_LEN_IPLEN_S;
-   } else if (ol_flags & RTE_MBUF_F_TX_IPV4) {
-   *td_cmd |= ICE_TX_DESC_CMD_IIPT_IPV4;
-   *td_offset |= (tx_offload.outer_l3_len >> 2) <<
-   ICE_TX_DESC_LEN_IPLEN_S;
-   } else if (ol_flags & RTE_MBUF_F_TX_IPV6) {
-   *td_cmd |= ICE_TX_DESC_CMD_IIPT_IPV6;
-   *td_offset |= (tx_offload.outer_l3_len >> 2) <<
-   ICE_TX_DESC_LEN_IPLEN_S;
-   }
-   } else {
-   if (ol_flags & RTE_MBUF_F_TX_IP_CKSUM) {
-   *td_cmd |= ICE_TX_DESC_CMD_IIPT_IPV4_CSUM;
-   *td_offset |= (tx_offload.l3_len >> 2) <<
-   ICE_TX_DESC_LEN_IPLEN_S;
-   } else if (ol_flags & RTE_MBUF_F_TX_IPV4) {
-   *td_cmd |= ICE_TX_DESC_CMD_IIPT_IPV4;
-   *td_offset |= (tx_offload.l3_len >> 2) <<
-   ICE_TX_DESC_LEN_IPLEN_S;
- 

RE: [PATCH v5] app/eventdev: add crypto producer mode

[Gujjar, Abhinandan S]

> -Original Message-
> From: Shijith Thotton 
> Sent: Tuesday, February 22, 2022 12:34 PM
> To: Van Haaren, Harry ; Gujjar, Abhinandan S
> ; Jerin Jacob ;
> Hemant Agrawal ; Nipun Gupta
> 
> Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
> 
> >> >
> >> > + @Van Haaren, Harry
> >
> >Hi All,
> >
> >I have been away on vacation for the last week - hence the delay in
> >reply on this thread.
> >
> >
> >
> >> > > [1]
> >> > > Steps to reproduce:
> >> > > * Clone https://urldefense.proofpoint.com/v2/url?u=http-
> >3A__dpdk.org_git_next_dpdk-2Dnext-
> >2Deventdev&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=G9w4KsPaQLAC
> BfGCL
> >35PtiRH996yqJDxAZwrWegU2qQ&m=-yaLm_cvg5cKTbBy3OoUs719W-
> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=lZjsn2zecck8IBBQRA7fId7
> BXSYKk
> >U8Tjj10gNQLB6U&e=
> >> > > * Apply [v5] app/eventdev: add crypto producer mode
> >> > >   git-pw --server
> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> Q&r=G
> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >yaLm_cvg5cKTbBy3OoUs719W-
> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> SneOm
> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> > > patch apply 107645
> >> > > * Apply [RFC] app/eventdev: add software crypto adapter support
> >> > >   git-pw --server
> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> Q&r=G
> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >yaLm_cvg5cKTbBy3OoUs719W-
> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> SneOm
> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> > > patch apply 107029
> >> > > * meson x86_build_debug  -Dc_args='-g -O0' -
> Ddisable_drivers="*/cnxk"
> >> > > * ninja -C x86_build_debug
> >> > > * Command to reproduce crash
> >> > >   sudo ./x86_build_debug/app/dpdk-test-eventdev -l 0-8 -s 0xf0
> >> > > --vdev=event_sw0  --vdev="crypto_null" -- --prod_type_cryptodev
> >> > > --crypto_adptr_mode 0 --test=perf_queue --stlist=a --wlcores 1
> >> > > --plcores 2
> >
> >Can confirm that these steps indeed cause segfault as reported.
> >
> >In debugging, it seems like there are *zero* NEW events, and large
> >numbers of RELEASE events are enqueued... if so, this is not compliant to
> the Eventdev API.
> >Can somebody confirm that?
> >
> >The SW PMD is being told there are events to release, but there aren't any.
> >Eventually, this leads to a mismatch in credit allocations, which then
> >causes the IQ-chunks datastructure to corrupt.
> >
> >All in all, I'm not convinced this is a SW PMD issue yet - initial
> >testing points to incorrect event OP NEW/FWD/RELEASE usage. Can we
> >verify that the OPs being sent are correct?
> >
> 
> Looks like an issue in crypto adapter service. The service is starting with
> OP_FORWARD, if RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE is set.
> Abhinandan can confirm.

The service is started with what application is requesting for from the adapter.
The app can request either OP_NEW or FWD mode. Adapter while creating a new 
instance
requests for evendev caps & based on that adapter enqueues events back to evdev
in FWD or NEW mode. All events are triggered by application and adapter is
transparent here. Could you please explain me how this creating an issue?

Regards
Abhinandan

Re: [dpdk-dev] [PATCH v2] net/cnxk: unify file names

[Jerin Jacob]

On Wed, Feb 23, 2022 at 12:01 AM  wrote:
>
> From: Jerin Jacob 
>
> Except for the cn*_rte_flow* files, none of the other
> file has rte in the file name, remove the
> rte to unify the file name across the directory.
>
> Signed-off-by: Jerin Jacob 
> Acked-by: Kiran Kumar K 

Applied to dpdk-next-net-mrvl/for-next-net. Thanks


> ---
>
> v2..v1:
>
> -Missed renaming cn10k_rte* and cn9k_rte* and fixed it
>
>
>  drivers/net/cnxk/cn10k_ethdev.c | 2 +-
>  drivers/net/cnxk/{cn10k_rte_flow.c => cn10k_flow.c} | 4 ++--
>  drivers/net/cnxk/{cn10k_rte_flow.h => cn10k_flow.h} | 0
>  drivers/net/cnxk/cn9k_ethdev.c  | 2 +-
>  drivers/net/cnxk/{cn9k_rte_flow.c => cn9k_flow.c}   | 4 ++--
>  drivers/net/cnxk/{cn9k_rte_flow.h => cn9k_flow.h}   | 0
>  drivers/net/cnxk/{cnxk_rte_flow.c => cnxk_flow.c}   | 2 +-
>  drivers/net/cnxk/{cnxk_rte_flow.h => cnxk_flow.h}   | 0
>  drivers/net/cnxk/meson.build| 6 +++---
>  9 files changed, 10 insertions(+), 10 deletions(-)
>  rename drivers/net/cnxk/{cn10k_rte_flow.c => cn10k_flow.c} (99%)
>  rename drivers/net/cnxk/{cn10k_rte_flow.h => cn10k_flow.h} (100%)
>  rename drivers/net/cnxk/{cn9k_rte_flow.c => cn9k_flow.c} (97%)
>  rename drivers/net/cnxk/{cn9k_rte_flow.h => cn9k_flow.h} (100%)
>  rename drivers/net/cnxk/{cnxk_rte_flow.c => cnxk_flow.c} (99%)
>  rename drivers/net/cnxk/{cnxk_rte_flow.h => cnxk_flow.h} (100%)
>
> diff --git a/drivers/net/cnxk/cn10k_ethdev.c b/drivers/net/cnxk/cn10k_ethdev.c
> index 9bb08e1824..f3003dd3df 100644
> --- a/drivers/net/cnxk/cn10k_ethdev.c
> +++ b/drivers/net/cnxk/cn10k_ethdev.c
> @@ -2,7 +2,7 @@
>   * Copyright(C) 2021 Marvell.
>   */
>  #include "cn10k_ethdev.h"
> -#include "cn10k_rte_flow.h"
> +#include "cn10k_flow.h"
>  #include "cn10k_rx.h"
>  #include "cn10k_tx.h"
>
> diff --git a/drivers/net/cnxk/cn10k_rte_flow.c b/drivers/net/cnxk/cn10k_flow.c
> similarity index 99%
> rename from drivers/net/cnxk/cn10k_rte_flow.c
> rename to drivers/net/cnxk/cn10k_flow.c
> index 529fb0e4b7..63281d41a4 100644
> --- a/drivers/net/cnxk/cn10k_rte_flow.c
> +++ b/drivers/net/cnxk/cn10k_flow.c
> @@ -1,8 +1,8 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2020 Marvell.
>   */
> -#include 
> -#include "cn10k_rte_flow.h"
> +#include 
> +#include "cn10k_flow.h"
>  #include "cn10k_ethdev.h"
>  #include "cn10k_rx.h"
>
> diff --git a/drivers/net/cnxk/cn10k_rte_flow.h b/drivers/net/cnxk/cn10k_flow.h
> similarity index 100%
> rename from drivers/net/cnxk/cn10k_rte_flow.h
> rename to drivers/net/cnxk/cn10k_flow.h
> diff --git a/drivers/net/cnxk/cn9k_ethdev.c b/drivers/net/cnxk/cn9k_ethdev.c
> index 01e3850561..a890829065 100644
> --- a/drivers/net/cnxk/cn9k_ethdev.c
> +++ b/drivers/net/cnxk/cn9k_ethdev.c
> @@ -2,7 +2,7 @@
>   * Copyright(C) 2021 Marvell.
>   */
>  #include "cn9k_ethdev.h"
> -#include "cn9k_rte_flow.h"
> +#include "cn9k_flow.h"
>  #include "cn9k_rx.h"
>  #include "cn9k_tx.h"
>
> diff --git a/drivers/net/cnxk/cn9k_rte_flow.c b/drivers/net/cnxk/cn9k_flow.c
> similarity index 97%
> rename from drivers/net/cnxk/cn9k_rte_flow.c
> rename to drivers/net/cnxk/cn9k_flow.c
> index b94d29e547..d67580bf27 100644
> --- a/drivers/net/cnxk/cn9k_rte_flow.c
> +++ b/drivers/net/cnxk/cn9k_flow.c
> @@ -1,9 +1,9 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2020 Marvell.
>   */
> -#include 
> +#include 
>  #include "cn9k_ethdev.h"
> -#include "cn9k_rte_flow.h"
> +#include "cn9k_flow.h"
>  #include "cn9k_rx.h"
>
>  struct rte_flow *
> diff --git a/drivers/net/cnxk/cn9k_rte_flow.h b/drivers/net/cnxk/cn9k_flow.h
> similarity index 100%
> rename from drivers/net/cnxk/cn9k_rte_flow.h
> rename to drivers/net/cnxk/cn9k_flow.h
> diff --git a/drivers/net/cnxk/cnxk_rte_flow.c b/drivers/net/cnxk/cnxk_flow.c
> similarity index 99%
> rename from drivers/net/cnxk/cnxk_rte_flow.c
> rename to drivers/net/cnxk/cnxk_flow.c
> index b08d7c34fa..8763ca63d6 100644
> --- a/drivers/net/cnxk/cnxk_rte_flow.c
> +++ b/drivers/net/cnxk/cnxk_flow.c
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2021 Marvell.
>   */
> -#include 
> +#include 
>
>  const struct cnxk_rte_flow_term_info term[] = {
> [RTE_FLOW_ITEM_TYPE_ETH] = {ROC_NPC_ITEM_TYPE_ETH,
> diff --git a/drivers/net/cnxk/cnxk_rte_flow.h b/drivers/net/cnxk/cnxk_flow.h
> similarity index 100%
> rename from drivers/net/cnxk/cnxk_rte_flow.h
> rename to drivers/net/cnxk/cnxk_flow.h
> diff --git a/drivers/net/cnxk/meson.build b/drivers/net/cnxk/meson.build
> index 83af1f4d0c..016a79b2a8 100644
> --- a/drivers/net/cnxk/meson.build
> +++ b/drivers/net/cnxk/meson.build
> @@ -19,7 +19,7 @@ sources = files(
>  'cnxk_link.c',
>  'cnxk_lookup.c',
>  'cnxk_ptp.c',
> -'cnxk_rte_flow.c',
> +'cnxk_flow.c',
>  'cnxk_stats.c',
>  'cnxk_tm.c',
>  )
> @@ -28,7 +28,7 @@ sources = files(
>  sources += files(
>  'cn9k_ethdev.c',
>  'cn9k_ethdev_sec.c',
> -'

RE: [EXT] [dpdk-dev v12 0/9] drivers/qat: QAT symmetric crypto datapatch rework

[Akhil Goyal]

> v11 - v12:
> - fixed a compile issue
> 
> v10:
> - rebase to the lastest for-main
> - fix of build rerror when RTE_LOG_DEBUG enabled
> 
> v9:
> - commit messages reword
> - fix of unused function error
> 
> v8:
> - rebase to 22.03-rc1
> 
> v7:
> - fix of pointer cast compile error in x86
> 
> v6:
> - fix of pointer cast error in x86
> - rebase to the lastest for-main
> 
> v5:
> - rebase to the latest for-main
> - patchset reconstruct
> 
> v4:
> - patchset break down and reconstruct
> 
> v3:
> - sperate a single patch 6 to two different patches
> 
> v2:
> - review comments addressed
> 
Applied to dpdk-next-crypto

RE: [EXT] [PATCH v3 0/5] crypto/qat: add asymmetric crypto algorithms

[Akhil Goyal]

> This patchset adds following asymmetric crypto algorithms to Intel QuickAssist
> Technology driver:
> - ECDSA
> - ECPM
> 
> Code also was refactored to be more readable and easier scalable.
> 
> v2:
> - add actual implementation
> v3:
> - rebase against newest changes
> 
> Depends-on: patch-107793 ("crypto: fix misspelled key in qt format")
> Depends-on: series-21741 ("drivers/qat: QAT symmetric crypto datapatch
> rework")
> 
Applied to dpdk-next-crypto

RE: [EXT] [PATCH] examples/ipsec-secgw: add check for unprotected port mask

[Akhil Goyal]

> > Usage of unprotected port mask without any configured SA inbound, will
> cause
> > use of uninitialized SA context, so disallow such configuration.
> >
> > Signed-off-by: Volodymyr Fialko 
> >
> > ---
> >  examples/ipsec-secgw/ipsec-secgw.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> 
> Acked-by: Anoob Joseph 

Applied to dpdk-next-crypto
Thanks.

Re: [PATCH v3 1/2] examples/l3fwd: use single set of variables throughout the code

[Kevin Traynor]

Hi Honnappa,

On 23/02/2022 06:13, Honnappa Nagarahalli wrote:

Question for stable maintainers.

DTS WG would like this patch to be merged in 21.11 and 20.11 stable releases 
even though it is not a bug fix. This allows for a single DTS version to be 
used with both those stable releases and master.

Do you have any objections?



No objection for 21.11. It is example code and just a minor addition 
that is not changing defaults. Please add the stable tag in the commit 
message on merge (or next rev) so it will be found by our scripts.


thanks,
Kevin.


Thank you,
Honnappa



-Original Message-
From: Honnappa Nagarahalli 
Sent: Wednesday, February 23, 2022 12:10 AM
To: dev@dpdk.org; Honnappa Nagarahalli ;
lijuan...@intel.com; juraj.lin...@pantheon.tech; ohily...@iol.unh.edu;
david.march...@redhat.com; tho...@monjalon.net; jer...@marvell.com;
bruce.richard...@intel.com; step...@networkplumber.org;
bl...@debian.org; ktray...@redhat.com; christian.ehrha...@canonical.com;
xuemi...@nvidia.com
Cc: Kathleen Capella ; nd ;
Ruifeng Wang 
Subject: [PATCH v3 1/2] examples/l3fwd: use single set of variables throughout
the code

nb_rxd and nb_txd are used in polling mode and event mode of operation.
nb_rxd and nb_txd are already global in polling mode but are not visible to
event mode code. Make them visible to all parts of the application.

Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Kathleen Capella 
Reviewed-by: Ruifeng Wang 
Acked-by: Bruce Richardson 
---
DTS test cases require changing the RX and TX queue depths.
Currently, this is achieved by patching the DPDK code. This patch set provides a
mechanism to configure the queue depths while launching the application. With
this change DTS test cases do not need to modify the DPDK code.

v2 - Single parse function, additional validation on input (Stephen)

v2 - Fixed typo (Ruifeng) and adjusted the commit msg (Kathleen).

  examples/l3fwd/l3fwd.h   | 4 
  examples/l3fwd/l3fwd_event.c | 2 --
  examples/l3fwd/main.c| 5 ++---
  3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h index
38ca19133c..4ccdb28b4a 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -81,6 +81,10 @@ struct lcore_conf {

  extern volatile bool force_quit;

+/* RX and TX queue depths */
+extern uint16_t nb_rxd;
+extern uint16_t nb_txd;
+
  /* ethernet addresses of ports */
  extern uint64_t dest_eth_addr[RTE_MAX_ETHPORTS];  extern struct
rte_ether_addr ports_eth_addr[RTE_MAX_ETHPORTS]; diff --git
a/examples/l3fwd/l3fwd_event.c b/examples/l3fwd/l3fwd_event.c index
dd9eafa9b9..7a401290f8 100644
--- a/examples/l3fwd/l3fwd_event.c
+++ b/examples/l3fwd/l3fwd_event.c
@@ -43,8 +43,6 @@ l3fwd_eth_dev_port_setup(struct rte_eth_conf
*port_conf)  {
struct l3fwd_event_resources *evt_rsrc = l3fwd_get_eventdev_rsrc();
uint16_t nb_ports = rte_eth_dev_count_avail();
-   uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT;
-   uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
unsigned int nb_lcores = rte_lcore_count();
struct rte_eth_conf local_port_conf;
struct rte_eth_dev_info dev_info;
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index
eb68ffc5aa..acd186ab7d 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -53,9 +53,8 @@

  #define MAX_LCORE_PARAMS 1024

-/* Static global variables used within this file. */ -static uint16_t nb_rxd =
RTE_TEST_RX_DESC_DEFAULT; -static uint16_t nb_txd =
RTE_TEST_TX_DESC_DEFAULT;
+uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT; uint16_t nb_txd =
+RTE_TEST_TX_DESC_DEFAULT;

  /**< Ports set in promiscuous mode off by default. */  static int
promiscuous_on;
--
2.25.1

RE: [EXT] [PATCH v2] doc: update FIPS docs

[Akhil Goyal]

> Added missing step for converting SHA request files to correct
> format. Replaced AES_GCM with GCM to follow the correct
> naming format.
> 
> Fixes: 3d0fad56b74 ("examples/fips_validation: add crypto FIPS application")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Jakub Poczatek 
> Acked-by: Fan Zhang 
Applied to dpdk-next-crypto

[PATCH] net/cnxk: fix compilation issue for gcc12

[Rakesh Kudurumalla]

resolve compilation error caused due to gcc 12 version
error: storing the address of local variable message in *error.message

Fixes: 26b034f78ca7 ("net/cnxk: support to validate meter policy")

Cc: sta...@dpdk.org

Signed-off-by: Rakesh Kudurumalla 
Change-Id: Ia4cf18471ae33691c34229ab537f208389e0f780
---
 drivers/net/cnxk/cnxk_ethdev_mtr.c | 59 ++
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/net/cnxk/cnxk_ethdev_mtr.c 
b/drivers/net/cnxk/cnxk_ethdev_mtr.c
index cc783e5f86..c8183aa12d 100644
--- a/drivers/net/cnxk/cnxk_ethdev_mtr.c
+++ b/drivers/net/cnxk/cnxk_ethdev_mtr.c
@@ -285,15 +285,54 @@ cnxk_nix_mtr_profile_delete(struct rte_eth_dev *eth_dev, 
uint32_t profile_id,
return 0;
 }
 
+static int
+update_mtr_err(uint32_t act_color, struct rte_mtr_error *error, bool action)
+{
+   const char *str;
+   switch (act_color) {
+   case RTE_COLOR_GREEN:
+   if (action) {
+   str = "Green action is not valid";
+   goto notsup;
+   } else {
+   str = "Green action is null";
+   goto notvalid;
+   }
+   break;
+   case RTE_COLOR_YELLOW:
+   if (action) {
+   str = "Yellow action is not valid";
+   goto notsup;
+   } else {
+   str = "Yellow action is null";
+   goto notvalid;
+   }
+   break;
+   case RTE_COLOR_RED:
+   if (action) {
+   str = "Red action is not valid";
+   goto notsup;
+   } else {
+   str = "Red action is null";
+   goto notvalid;
+   }
+   break;
+   }
+notsup:
+   return -rte_mtr_error_set(error, ENOTSUP,
+ RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
+notvalid:
+   return -rte_mtr_error_set(error, EINVAL,
+ RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
+}
+
 static int
 cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
 struct rte_mtr_meter_policy_params *policy,
 struct rte_mtr_error *error)
 {
-   static const char *const action_color[] = {"Green", "Yellow", "Red"};
bool supported[RTE_COLORS] = {false, false, false};
const struct rte_flow_action *action;
-   char message[1024];
uint32_t i;
 
RTE_SET_USED(dev);
@@ -315,21 +354,11 @@ cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
if (action->type == RTE_FLOW_ACTION_TYPE_VOID)
supported[i] = true;
 
-   if (!supported[i]) {
-   sprintf(message,
-   "%s action is not valid",
-   action_color[i]);
-   return -rte_mtr_error_set(error,
- ENOTSUP,
- RTE_MTR_ERROR_TYPE_METER_POLICY, NULL,
- message);
-   }
+   if (!supported[i])
+   return update_mtr_err(i, error, true);
}
} else {
-   sprintf(message, "%s action is null", action_color[i]);
-   return -rte_mtr_error_set(error, EINVAL,
-   RTE_MTR_ERROR_TYPE_METER_POLICY, NULL,
-   message);
+   return update_mtr_err(i, error, false);
}
}
 
-- 
2.25.1

[PATCH v3 1/3] examples/ipsec-secgw: update error prints to data path log

[Nithin Dabilpuram]

Update error prints in data path to RTE_LOG_DP().
Error prints in fast path are not good for performance
as they slow down the application when few bad packets are
received.

Signed-off-by: Nithin Dabilpuram 
Acked-by: Akhil Goyal 
---

v2:
- Fixed issue with warning in patch 4/4 by checking for session pool
  initialization instead of mbuf_pool as now mbuf pool is per port.

v3:
- Removed patch 2/4 from this series. Will send it with other series
  that adds seperate worker thread for ipsec-secgw if all SA's are from
  inline protocol.
- Added documentation for patch 4/4.

 examples/ipsec-secgw/ipsec_worker.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec_worker.c 
b/examples/ipsec-secgw/ipsec_worker.c
index 7419e85..e9493c5 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -332,7 +332,8 @@ process_ipsec_ev_inbound(struct ipsec_ctx *ctx, struct 
route_table *rt,
break;
 
default:
-   RTE_LOG(ERR, IPSEC, "Unsupported packet type = %d\n", type);
+   RTE_LOG_DP(DEBUG, IPSEC_ESP, "Unsupported packet type = %d\n",
+  type);
goto drop_pkt_and_exit;
}
 
@@ -570,7 +571,8 @@ classify_pkt(struct rte_mbuf *pkt, struct ipsec_traffic *t)
t->ip6.pkts[(t->ip6.num)++] = pkt;
break;
default:
-   RTE_LOG(ERR, IPSEC, "Unsupported packet type = %d\n", type);
+   RTE_LOG_DP(DEBUG, IPSEC_ESP, "Unsupported packet type = %d\n",
+  type);
free_pkts(&pkt, 1);
break;
}
-- 
2.8.4

[PATCH v3 2/3] examples/ipsec-secgw: fix buffer free logic in vector mode

[Nithin Dabilpuram]

Fix packet processing to skip after mbuf is freed instead of
touching and Tx'ing it.

Also free vector event buffer in event worker when after processing
there is no pkt to be enqueued to Tx adapter.

Fixes: 86738ebe1e3d ("examples/ipsec-secgw: support event vector")
Cc: scha...@marvell.com
Cc: sta...@dpdk.org

Signed-off-by: Nithin Dabilpuram 
Acked-by: Akhil Goyal 
---
 examples/ipsec-secgw/ipsec_worker.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec_worker.c 
b/examples/ipsec-secgw/ipsec_worker.c
index e9493c5..8639426 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -205,12 +205,16 @@ check_sp_sa_bulk(struct sp_ctx *sp, struct sa_ctx *sa_ctx,
ip->pkts[j++] = m;
else {
sa = *(struct ipsec_sa **)rte_security_dynfield(m);
-   if (sa == NULL)
+   if (sa == NULL) {
free_pkts(&m, 1);
+   continue;
+   }
 
/* SPI on the packet should match with the one in SA */
-   if (unlikely(sa->spi != sa_ctx->sa[res - 1].spi))
+   if (unlikely(sa->spi != sa_ctx->sa[res - 1].spi)) {
free_pkts(&m, 1);
+   continue;
+   }
 
ip->pkts[j++] = m;
}
@@ -536,6 +540,7 @@ ipsec_ev_route_pkts(struct rte_event_vector *vec, struct 
route_table *rt,
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)) {
RTE_LOG(ERR, IPSEC, "SA type not supported\n");
free_pkts(&pkt, 1);
+   continue;
}
rte_security_set_pkt_metadata(sess->security.ctx,
sess->security.ses, pkt, NULL);
@@ -695,11 +700,13 @@ ipsec_ev_vector_process(struct 
lcore_conf_ev_tx_int_port_wrkr *lconf,
ret = process_ipsec_ev_outbound_vector(&lconf->outbound,
   &lconf->rt, vec);
 
-   if (ret > 0) {
+   if (likely(ret > 0)) {
vec->nb_elem = ret;
rte_event_eth_tx_adapter_enqueue(links[0].eventdev_id,
 links[0].event_port_id,
 ev, 1, 0);
+   } else {
+   rte_mempool_put(rte_mempool_from_obj(vec), vec);
}
 }
 
@@ -720,6 +727,8 @@ ipsec_ev_vector_drv_mode_process(struct eh_event_link_info 
*links,
rte_event_eth_tx_adapter_enqueue(links[0].eventdev_id,
 links[0].event_port_id,
 ev, 1, 0);
+   else
+   rte_mempool_put(rte_mempool_from_obj(vec), vec);
 }
 
 /*
-- 
2.8.4

[PATCH v3 3/3] examples/ipsec-secgw: add per port pool and vector pool size

[Nithin Dabilpuram]

Add support to enable per port packet pool and also override
vector pool size from command line args. This is useful
on some HW to tune performance based on usecase.

Signed-off-by: Nithin Dabilpuram 
Acked-by: Akhil Goyal 
---
 doc/guides/sample_app_ug/ipsec_secgw.rst |  7 +++
 examples/ipsec-secgw/event_helper.c  | 17 +--
 examples/ipsec-secgw/event_helper.h  |  2 +
 examples/ipsec-secgw/ipsec-secgw.c   | 82 
 examples/ipsec-secgw/ipsec-secgw.h   |  2 +
 examples/ipsec-secgw/ipsec.h |  2 +-
 6 files changed, 88 insertions(+), 24 deletions(-)

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst 
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index c53ee7c..d93acf0 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -249,6 +249,13 @@ Where:
 Should be lower for low number of reassembly buckets.
 Valid values: from 1 ns to 10 s. Default value: 1000 (10 s).
 
+*   ``--per-port-pool``: Enable per ethdev port pktmbuf pool.
+ By default one packet mbuf pool per socket is created and configured
+ via Rx queue setup.
+
+*   ``--vector-pool-sz``: Number of buffers in vector pool.
+By default, vector pool size depeneds on packet pool size
+and size of each vector.
 
 The mapping of lcores to port/queues is similar to other l3fwd applications.
 
diff --git a/examples/ipsec-secgw/event_helper.c 
b/examples/ipsec-secgw/event_helper.c
index 8947e41..172ab8e 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -792,8 +792,8 @@ eh_rx_adapter_configure(struct eventmode_conf *em_conf,
uint32_t service_id, socket_id, nb_elem;
struct rte_mempool *vector_pool = NULL;
uint32_t lcore_id = rte_lcore_id();
+   int ret, portid, nb_ports = 0;
uint8_t eventdev_id;
-   int ret;
int j;
 
/* Get event dev ID */
@@ -806,10 +806,21 @@ eh_rx_adapter_configure(struct eventmode_conf *em_conf,
return ret;
}
 
+   RTE_ETH_FOREACH_DEV(portid)
+   if ((em_conf->eth_portmask & (1 << portid)))
+   nb_ports++;
+
if (em_conf->ext_params.event_vector) {
socket_id = rte_lcore_to_socket_id(lcore_id);
-   nb_elem = (nb_bufs_in_pool / em_conf->ext_params.vector_size)
- + 1;
+
+   if (em_conf->vector_pool_sz) {
+   nb_elem = em_conf->vector_pool_sz;
+   } else {
+   nb_elem = (nb_bufs_in_pool /
+  em_conf->ext_params.vector_size) + 1;
+   if (per_port_pool)
+   nb_elem = nb_ports * nb_elem;
+   }
 
vector_pool = rte_event_vector_pool_create(
"vector_pool", nb_elem, 0,
diff --git a/examples/ipsec-secgw/event_helper.h 
b/examples/ipsec-secgw/event_helper.h
index 5be6c62..f3cbe57 100644
--- a/examples/ipsec-secgw/event_helper.h
+++ b/examples/ipsec-secgw/event_helper.h
@@ -183,6 +183,8 @@ struct eventmode_conf {
/**< 64 bit field to specify extended params */
uint64_t vector_tmo_ns;
/**< Max vector timeout in nanoseconds */
+   uint64_t vector_pool_sz;
+   /**< Vector pool size */
 };
 
 /**
diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index 9de1c6d..42b5081 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -118,6 +118,8 @@ struct flow_info flow_info_tbl[RTE_MAX_ETHPORTS];
 #define CMD_LINE_OPT_EVENT_VECTOR  "event-vector"
 #define CMD_LINE_OPT_VECTOR_SIZE   "vector-size"
 #define CMD_LINE_OPT_VECTOR_TIMEOUT"vector-tmo"
+#define CMD_LINE_OPT_VECTOR_POOL_SZ"vector-pool-sz"
+#define CMD_LINE_OPT_PER_PORT_POOL "per-port-pool"
 
 #define CMD_LINE_ARG_EVENT "event"
 #define CMD_LINE_ARG_POLL  "poll"
@@ -145,6 +147,8 @@ enum {
CMD_LINE_OPT_EVENT_VECTOR_NUM,
CMD_LINE_OPT_VECTOR_SIZE_NUM,
CMD_LINE_OPT_VECTOR_TIMEOUT_NUM,
+   CMD_LINE_OPT_VECTOR_POOL_SZ_NUM,
+   CMD_LINE_OPT_PER_PORT_POOL_NUM,
 };
 
 static const struct option lgopts[] = {
@@ -161,6 +165,8 @@ static const struct option lgopts[] = {
{CMD_LINE_OPT_EVENT_VECTOR, 0, 0, CMD_LINE_OPT_EVENT_VECTOR_NUM},
{CMD_LINE_OPT_VECTOR_SIZE, 1, 0, CMD_LINE_OPT_VECTOR_SIZE_NUM},
{CMD_LINE_OPT_VECTOR_TIMEOUT, 1, 0, CMD_LINE_OPT_VECTOR_TIMEOUT_NUM},
+   {CMD_LINE_OPT_VECTOR_POOL_SZ, 1, 0, CMD_LINE_OPT_VECTOR_POOL_SZ_NUM},
+   {CMD_LINE_OPT_PER_PORT_POOL, 0, 0, CMD_LINE_OPT_PER_PORT_POOL_NUM},
{NULL, 0, 0, 0}
 };
 
@@ -234,7 +240,6 @@ struct lcore_conf {
struct rt_ctx *rt6_ctx;
struct {
struct rte_ip_frag_tbl *tbl;
-   struct rte_mempool *pool_dir;
struct rte_mempool *pool_indir;

[PATCH] net/cnxk: fix compilation issue for gcc12

[Rakesh Kudurumalla]

resolve compilation error caused due to gcc 12 version
error: storing the address of local variable message in *error.message

Fixes: 26b034f78ca7 ("net/cnxk: support to validate meter policy")

Cc: sta...@dpdk.org

Signed-off-by: Rakesh Kudurumalla 
---
v2 : removed changeid

 drivers/net/cnxk/cnxk_ethdev_mtr.c | 59 ++
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/net/cnxk/cnxk_ethdev_mtr.c 
b/drivers/net/cnxk/cnxk_ethdev_mtr.c
index cc783e5f86..c8183aa12d 100644
--- a/drivers/net/cnxk/cnxk_ethdev_mtr.c
+++ b/drivers/net/cnxk/cnxk_ethdev_mtr.c
@@ -285,15 +285,54 @@ cnxk_nix_mtr_profile_delete(struct rte_eth_dev *eth_dev, 
uint32_t profile_id,
return 0;
 }
 
+static int
+update_mtr_err(uint32_t act_color, struct rte_mtr_error *error, bool action)
+{
+   const char *str;
+   switch (act_color) {
+   case RTE_COLOR_GREEN:
+   if (action) {
+   str = "Green action is not valid";
+   goto notsup;
+   } else {
+   str = "Green action is null";
+   goto notvalid;
+   }
+   break;
+   case RTE_COLOR_YELLOW:
+   if (action) {
+   str = "Yellow action is not valid";
+   goto notsup;
+   } else {
+   str = "Yellow action is null";
+   goto notvalid;
+   }
+   break;
+   case RTE_COLOR_RED:
+   if (action) {
+   str = "Red action is not valid";
+   goto notsup;
+   } else {
+   str = "Red action is null";
+   goto notvalid;
+   }
+   break;
+   }
+notsup:
+   return -rte_mtr_error_set(error, ENOTSUP,
+ RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
+notvalid:
+   return -rte_mtr_error_set(error, EINVAL,
+ RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
+}
+
 static int
 cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
 struct rte_mtr_meter_policy_params *policy,
 struct rte_mtr_error *error)
 {
-   static const char *const action_color[] = {"Green", "Yellow", "Red"};
bool supported[RTE_COLORS] = {false, false, false};
const struct rte_flow_action *action;
-   char message[1024];
uint32_t i;
 
RTE_SET_USED(dev);
@@ -315,21 +354,11 @@ cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
if (action->type == RTE_FLOW_ACTION_TYPE_VOID)
supported[i] = true;
 
-   if (!supported[i]) {
-   sprintf(message,
-   "%s action is not valid",
-   action_color[i]);
-   return -rte_mtr_error_set(error,
- ENOTSUP,
- RTE_MTR_ERROR_TYPE_METER_POLICY, NULL,
- message);
-   }
+   if (!supported[i])
+   return update_mtr_err(i, error, true);
}
} else {
-   sprintf(message, "%s action is null", action_color[i]);
-   return -rte_mtr_error_set(error, EINVAL,
-   RTE_MTR_ERROR_TYPE_METER_POLICY, NULL,
-   message);
+   return update_mtr_err(i, error, false);
}
}
 
-- 
2.25.1

Re: [PATCH 2/4] examples/ipsec-secgw: disable Tx chksum offload for inline

[Nithin Kumar Dabilpuram]

On 2/18/22 7:28 PM, Nithin Kumar Dabilpuram wrote:



On 2/18/22 12:47 AM, Ananyev, Konstantin wrote:



Enable Tx IPv4 checksum offload only when Tx inline crypto is needed.
In other cases such as Tx Inline protocol offload, checksum 
computation

is implicitly taken care by HW.


Why is that?
These is two separate HW offload and user has to enable each of them 
explicitly.



In Inline IPSec protocol offload, the complete tunnel header for tunnel
mode is updated by HW/PMD. So it doesn't have any dependency on
RTE_ETH_TX_OFFLOAD_IPV4_CKSUM as there is no valid l2_len/l3_len yet in
the mbuf. Similarly in case of Transport mode, the IPv4 header is
updated by HW itself for next proto and hence the offsets and all can
vary based on the HW implementation.

Hence my thought was for Inline IPsec protocol offload, there is no need
to explicitly say that RTE_ETH_TX_OFFLOAD_IPV4_CKSUM is enabled and need
not provide ol_flags RTE_MBUF_F_TX_IP_CKSUM and l2_len and l3_len which
might not be correct in prepare_tx_pkt().

  >* RTE_MBUF_F_TX_IP_CKSUM.
  > *  - fill the mbuf offload information: l2_len, l3_len
(Ex: Tunnel header being inserted is IPv6 while inner header is IPv4.

For inline crypto I agree, the packet content is all in place except for
plain text->cipher text translation so l2/l3 offsets are valid.


Ok, but apart from inline modes we also have lookaside modes.
Why to disable ip cksum for them?


Ack, I missed that case. I'll make the change to enable Tx checksum 
offload enabled even for Lookaside crypto.






  > Also we can TX clear-text traffic.
Ok, I agree that we can have clear-text traffic. We are already handling
ipv4 checksum in SW in case Tx offload doesn't have IPv4 Checksum
offload enabled. And for clear text traffic I think that is not needed
as well as we are not updating ttl.


As I remember we always recalculate ip cksum if RTE_MBUF_F_TX_IP_CKSUM
is not set:

static inline void
prepare_tx_pkt(struct rte_mbuf *pkt, uint16_t port,
 const struct lcore_conf *qconf)
{
 struct ip *ip;
 struct rte_ether_hdr *ethhdr;

 ip = rte_pktmbuf_mtod(pkt, struct ip *);

 ethhdr = (struct rte_ether_hdr *)
 rte_pktmbuf_prepend(pkt, RTE_ETHER_HDR_LEN);

 if (ip->ip_v == IPVERSION) {
 pkt->ol_flags |= qconf->outbound.ipv4_offloads;
 pkt->l3_len = sizeof(struct ip);
 pkt->l2_len = RTE_ETHER_HDR_LEN;

 ip->ip_sum = 0;

 /* calculate IPv4 cksum in SW */
 if ((pkt->ol_flags & RTE_MBUF_F_TX_IP_CKSUM) == 0)
 ip->ip_sum = rte_ipv4_cksum((struct 
rte_ipv4_hdr *)ip);


...



I'm working on another series to restructure fast path based on 
different mode. As part of that, I think we can avoid checksum 
recalculation in cases of inline protocol offload.


I removed this patch from v3 of this series. I'll included it in other 
series that I'm working on to have separate worker thread when all

SA's are of particular mode. There we can avoid checksum recalculation
completely both in SW and HW.

Thanks
Nithin





My overall intention was to have lighter Tx burst function for Inline
IPsec protocol offload as mainly IPsec traffic and not plain traffic is
primary use case for ipsec-secgw.






The advantage of having only necessary
offloads enabled is that Tx burst function can be as light as 
possible.


Signed-off-by: Nithin Dabilpuram 
---
   examples/ipsec-secgw/ipsec-secgw.c | 3 ---
   examples/ipsec-secgw/sa.c  | 9 +
   2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c

index 21abc0d..d8a9bfa 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -2314,9 +2314,6 @@ port_init(uint16_t portid, uint64_t 
req_rx_offloads, uint64_t req_tx_offloads)

   local_port_conf.txmode.offloads |=
   RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE;

-    if (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_IPV4_CKSUM)
-    local_port_conf.txmode.offloads |= 
RTE_ETH_TX_OFFLOAD_IPV4_CKSUM;

-
   printf("port %u configuring rx_offloads=0x%" PRIx64
   ", tx_offloads=0x%" PRIx64 "\n",
   portid, local_port_conf.rxmode.offloads,
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 1839ac7..b878a48 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1790,6 +1790,15 @@ sa_check_offloads(uint16_t port_id, uint64_t 
*rx_offloads,

   RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)
   && rule->portid == port_id) {
   *tx_offloads |= RTE_ETH_TX_OFFLOAD_SECURITY;
+
+    /* Checksum offload is not needed for inline protocol as
+ * all processing for Outbound IPSec packets will be
+ * implicitly taken care and for non-IPSec packets,
+ * there is no need of IPv4 Checksum 

RE: [PATCH v5] app/eventdev: add crypto producer mode

[Shijith Thotton]

>-Original Message-
>From: Gujjar, Abhinandan S 
>Sent: Wednesday, February 23, 2022 2:32 PM
>To: Shijith Thotton ; Van Haaren, Harry
>; Jerin Jacob ; Hemant
>Agrawal ; Nipun Gupta 
>Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
>Subject: [EXT] RE: [PATCH v5] app/eventdev: add crypto producer mode
>
>External Email
>
>--
>
>
>> -Original Message-
>> From: Shijith Thotton 
>> Sent: Tuesday, February 22, 2022 12:34 PM
>> To: Van Haaren, Harry ; Gujjar, Abhinandan S
>> ; Jerin Jacob ;
>> Hemant Agrawal ; Nipun Gupta
>> 
>> Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
>> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
>>
>> >> >
>> >> > + @Van Haaren, Harry
>> >
>> >Hi All,
>> >
>> >I have been away on vacation for the last week - hence the delay in
>> >reply on this thread.
>> >
>> >
>> >
>> >> > > [1]
>> >> > > Steps to reproduce:
>> >> > > * Clone https://urldefense.proofpoint.com/v2/url?u=http-
>> >3A__dpdk.org_git_next_dpdk-2Dnext-
>> >2Deventdev&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=G9w4KsPaQLAC
>> BfGCL
>> >35PtiRH996yqJDxAZwrWegU2qQ&m=-yaLm_cvg5cKTbBy3OoUs719W-
>> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=lZjsn2zecck8IBBQRA7fId7
>> BXSYKk
>> >U8Tjj10gNQLB6U&e=
>> >> > > * Apply [v5] app/eventdev: add crypto producer mode
>> >> > >   git-pw --server
>> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
>> Q&r=G
>> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
>> >yaLm_cvg5cKTbBy3OoUs719W-
>> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
>> SneOm
>> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
>> >> > > patch apply 107645
>> >> > > * Apply [RFC] app/eventdev: add software crypto adapter support
>> >> > >   git-pw --server
>> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
>> Q&r=G
>> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
>> >yaLm_cvg5cKTbBy3OoUs719W-
>> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
>> SneOm
>> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
>> >> > > patch apply 107029
>> >> > > * meson x86_build_debug  -Dc_args='-g -O0' -
>> Ddisable_drivers="*/cnxk"
>> >> > > * ninja -C x86_build_debug
>> >> > > * Command to reproduce crash
>> >> > >   sudo ./x86_build_debug/app/dpdk-test-eventdev -l 0-8 -s 0xf0
>> >> > > --vdev=event_sw0  --vdev="crypto_null" -- --prod_type_cryptodev
>> >> > > --crypto_adptr_mode 0 --test=perf_queue --stlist=a --wlcores 1
>> >> > > --plcores 2
>> >
>> >Can confirm that these steps indeed cause segfault as reported.
>> >
>> >In debugging, it seems like there are *zero* NEW events, and large
>> >numbers of RELEASE events are enqueued... if so, this is not compliant to
>> the Eventdev API.
>> >Can somebody confirm that?
>> >
>> >The SW PMD is being told there are events to release, but there aren't any.
>> >Eventually, this leads to a mismatch in credit allocations, which then
>> >causes the IQ-chunks datastructure to corrupt.
>> >
>> >All in all, I'm not convinced this is a SW PMD issue yet - initial
>> >testing points to incorrect event OP NEW/FWD/RELEASE usage. Can we
>> >verify that the OPs being sent are correct?
>> >
>>
>> Looks like an issue in crypto adapter service. The service is starting with
>> OP_FORWARD, if RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE is set.
>> Abhinandan can confirm.
>
>The service is started with what application is requesting for from the 
>adapter.
>The app can request either OP_NEW or FWD mode. Adapter while creating a new
>instance
>requests for evendev caps & based on that adapter enqueues events back to
>evdev
>in FWD or NEW mode. All events are triggered by application and adapter is
>transparent here. Could you please explain me how this creating an issue?
>

In lib/eventdev/rte_event_crypto_adapter.c:
...
eca_ops_enqueue_burst(struct event_crypto_adapter *adapter,
...
rte_memcpy(ev, &m_data->response_info, sizeof(*ev));
ev->event_ptr = ops[i];
ev->event_type = RTE_EVENT_TYPE_CRYPTODEV;
if (adapter->implicit_release_disabled)
ev->op = RTE_EVENT_OP_FORWARD;
else
ev->op = RTE_EVENT_OP_NEW;
 ...

op and event_type is set in the service. Changing FORWARD to NEW will fix the 
crash.

I think, we should update the spec with what all values are used in response 
info.
I will remove setting op/event_type field of response info in the application.
PMD/service can take care of it.

Re: [PATCH] sched: fix integer handling issue

[Ferruh Yigit]

On 2/23/2022 7:17 AM, Morten Brørup wrote:

From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Tuesday, 22 February 2022 17.03

On Tue, 22 Feb 2022 15:13:53 +0100
Morten Brørup  wrote:


From: Megha Ajmera [mailto:megha.ajm...@intel.com]
Sent: Tuesday, 22 February 2022 14.19

Masking of core mask was incorrect. Instead of using 1U for

shifting,

it
should be using 1LU as the result is assigned to uint64.

CID 375859: Potentially overflowing expression "1U <<

app_main_core"

with
type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit
arithmetic,
and then used in a context that expects an expression of type
"uint64_t"
(64 bits, unsigned).

Coverity issue: 375859

Signed-off-by: Megha Ajmera 
---
  examples/qos_sched/args.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
index 10ca7bea61..44f2f5640e 100644
--- a/examples/qos_sched/args.c
+++ b/examples/qos_sched/args.c
@@ -433,7 +433,7 @@ app_parse_args(int argc, char **argv)
return -1;
}
}
-   app_used_core_mask |= 1u << app_main_core;
+   app_used_core_mask |= 1lu << app_main_core;


Still wrong on 32 bit platforms, where long unsigned int is still 32

bits.


Use this instead:
app_used_core_mask |= RTE_BIT64(app_main_core);


DPDK now supports > 64 lcores. So all code using/assuming a 64 bit mask
is broken.



Good point. Is there a TODO-list where such a general review request can be 
filed, or should we just file it as a system-wide bug in Bugzilla?

Nonetheless, I think this one-line fix should be accepted as a short term 
solution.



Hi Morten,

I suspect there can be more places that testpmd assumes
max core number is 64, someone needs to spend time to
analyze and fix it.

Re: [PATCH v2 00/21] net/ena: v2.6.0 driver update

[Michał Krawczyk]

wt., 22 lut 2022 o 23:21 Ferruh Yigit  napisał(a):
>
> On 2/22/2022 6:11 PM, Michal Krawczyk wrote:
> > Hi,
> >
> > this set contains new ENA features:
> >
> > * New xstats.
> > * Reconfigurable link status event.
> > * Usage of the optimized memcpy on arm/arm64.
> > * Better MP support.
> > * Reconfigurable Tx completion timeout value using devarg.
> >
> > Beside that, this patchset contains multiple fixes, minor improvements, new
> > DPDK API support and extra error checks.
> >
> > v2:
> > * Fix reviewer's email (s/igo...@semihalf.com/igo...@amazon.com/).
> > * Fix commit messages typos found by the checkpatch.
> >
> > Dawid Gorecki (4):
> >net/ena: expose Tx cleanup function
> >net/ena: check if reset was already triggered
> >net/ena: extend debug prints for invalid req ID resets
> >net/ena: don't initialize LLQ when membar isn't exposed
> >
> > Michal Krawczyk (15):
> >net/ena: remove linearization function
> >net/ena: add assertion on Tx info mbuf
> >net/ena: remove unused enumeration
> >net/ena: remove unused offloads variables
> >net/ena: add extra Rx checksum related xstats
> >net/ena: make LSC configurable
> >net/ena: skip timer if the reset is triggered
> >net/ena: perform Tx cleanup before sending pkts
> >net/ena/base: use optimized memcpy version also on Arm
> >net/ena/base: make IO memzone unique per port
> >net/ena: add API for probing xstat names by ID
> >net/ena: make Tx completion timeout configurable
> >net/ena: fix meta-desc DF flag setup
> >net/ena: don't indicate bad csum for L4 csum error
> >net/ena: update version to 2.6.0
> >
> > Stanislaw Kardach (2):
> >net/ena: proxy AQ calls to primary process
> >net/ena: enable stats get function for MP mode
>
> Hi Michal, Marcin, Shai, Evgeny, Igor,
>
> We are 3-4 days away from -rc2 and received this biggish set,
> I wish it was sent a little earlier to give more time for it.
>
> At least can you please send the roadmap next time so we can
> know what will come, what to expect instead of surprise.
>

Hi Ferruh,

I'm sorry for that, we had those patches enqueued internally for a
longer period and finally managed to perform the internal review.

We'll work on better communication from our side toward the next
releases and choose the best way to inform you about the upcoming
changes and internal deadlines, similar to what the other vendors are
doing.

>
> At first glance there is a build error on the set, I will
> comment on the relevant patch.

Thanks for taking a look at those patches, I really appreciate that.
I'll work on relevant fixes and send v3 ASAP.

Thanks,
Michal

>
> Thanks,
> ferruh

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Anoob Joseph]

Hi Arek,

I agree that these cases may not be particularly useful from cryptographic 
standpoint, but how do we say from what values a PMD "must" support? Are you 
having some trouble supporting some of these values? Should we consider 
extending capabilities to help with this rather than just removing the test 
vectors?

Thanks,
Anoob

> -Original Message-
> From: Arek Kusztal 
> Sent: Tuesday, February 8, 2022 4:25 PM
> To: dev@dpdk.org
> Cc: Akhil Goyal ; roy.fan.zh...@intel.com; Arek
> Kusztal 
> Subject: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases
> 
> External Email
> 
> --
> Even if mod exp tests cases where modulus is not the biggest number are
> mathematically correct and can be computed, cryptographically it is useless
> and PMD does not need to support it.
> 
> Signed-off-by: Arek Kusztal 
> ---
>  app/test/test_cryptodev_mod_test_vectors.h | 501 
> -
>  1 file changed, 501 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> b/app/test/test_cryptodev_mod_test_vectors.h
> index c66f4b18bc..d108059624 100644
> --- a/app/test/test_cryptodev_mod_test_vectors.h
> +++ b/app/test/test_cryptodev_mod_test_vectors.h
> @@ -167,141 +167,6 @@ modex_test_data modex_test_case[] = {  },  {
>   .description = "Modular Exponentiation "
> -"(mod=8, base=65, exp=17, res=8)",
> - .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> - .base = {
> - .data = {
> - 0x25, 0x74, 0x41, 0xCE, 0xFA, 0x5C, 0x07, 0x2A,
> - 0xD1, 0x74, 0xF3, 0x3D, 0xE1, 0xCC, 0xC3, 0x18,
> - 0x7E, 0x4A, 0x21, 0x9F, 0x97, 0xA3, 0x26, 0x85,
> - 0x85, 0xD9, 0x9B, 0xE3, 0xBA, 0xB3, 0x70, 0xC9,
> - 0x26, 0x68, 0xE4, 0xB7, 0x4C, 0x88, 0x48, 0xC1,
> - 0x6B, 0xC6, 0x3C, 0x00, 0x8C, 0x6B, 0xC6, 0x11,
> - 0xD0, 0xD6, 0x61, 0x5D, 0xEC, 0xAA, 0xBA, 0x3B,
> - 0x7D, 0xB3, 0x0D, 0x3F, 0xA5, 0x4D, 0xEE, 0xE4,
> - 0xAC
> - },
> - .len = 65
> - },
> - .exponent = {
> - .data = {
> - 0x1C, 0x54, 0x2F, 0xCA, 0xDE, 0x4F, 0x17, 0x38,
> - 0x69, 0x87, 0xB4, 0xFF, 0x3A, 0x6C, 0x82, 0x70,
> - 0x53
> - },
> - .len = 17
> - },
> - .reminder = {
> - .data = {
> - 0x52, 0x06, 0x1A, 0x35, 0x70, 0x33, 0x78, 0x45
> - },
> - .len = 8
> - },
> - .modulus = {
> - .data = {
> - 0x6B, 0x6D, 0xFA, 0xCB, 0x09, 0x5D, 0x9C, 0xFD
> - },
> - .len = 8
> - },
> - .result_len = 8
> -},
> -{
> - .description = "Modular Exponentiation "
> -"(mod=100, base=150, exp=192, res=100)",
> - .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> - .base = {
> - .data = {
> - 0xC1, 0xA1, 0x04, 0xE4, 0x4D, 0x4A, 0xD3, 0x5C,
> - 0xB3, 0xD0, 0x16, 0x51, 0xA7, 0xF4, 0x82, 0x6C,
> - 0x22, 0xDD, 0x4D, 0xAA, 0x70, 0x30, 0x25, 0xA7,
> - 0xFA, 0xA9, 0xF2, 0x20, 0x55, 0x9B, 0xEA, 0x26,
> - 0xF6, 0xB5, 0xF8, 0x9C, 0x46, 0x21, 0x85, 0x0E,
> - 0x38, 0x73, 0x01, 0xC6, 0x72, 0x67, 0x9B, 0x49,
> - 0xCE, 0x48, 0xB7, 0x4A, 0xEE, 0x08, 0x21, 0x26,
> - 0xF3, 0x21, 0x77, 0xE7, 0x3C, 0x77, 0xF4, 0x0A,
> - 0x82, 0xC8, 0x16, 0x94, 0x6C, 0xBF, 0xA8, 0xD8,
> - 0x8B, 0x7D, 0x27, 0x60, 0xAC, 0x06, 0x69, 0x7E,
> - 0x46, 0x2C, 0xE2, 0xD1, 0x13, 0x50, 0x7D, 0xCE,
> - 0x4D, 0xC4, 0x5D, 0x81, 0xFB, 0x6B, 0x11, 0x4A,
> - 0x2D, 0xA2, 0x03, 0x55, 0x77, 0x8C, 0x3D, 0xA1,
> - 0xAD, 0xBE, 0x9C, 0x72, 0xE5, 0xA5, 0xFB, 0x49,
> - 0x5F, 0x13, 0x48, 0xC7, 0xAC, 0xD1, 0x0F, 0x5E,
> - 0xDF, 0x9C, 0xC7, 0xF5, 0x19, 0xFD, 0xC5, 0x77,
> - 0x27, 0x8D, 0xC4, 0x1D, 0x90, 0x8C, 0x20, 0x96,
> - 0xC8, 0x6A, 0x0D, 0x2F, 0xE2, 0x8B, 0xB0, 0x58,
> - 0xF8, 0xC4, 0x31, 0x0A, 0x17, 0x11
> - },
> - .len = 150
> - },
> - .exponent = {
> - .data = {
> - 0xC6, 0x20, 0x99, 0xD9, 0xBC, 0xE2, 0xAD, 0x74,
> - 0x11, 0x6F, 0x74, 0x14, 0x72, 0xB8, 0x09, 0xCB,
> - 0x5C, 0x74, 0x11, 0x21, 0x17, 0x84, 0x02, 0xDC,
> - 0x70, 0x59, 0x20, 0x79, 0x40, 0x7B, 0x0E, 0x52,
> - 0xAD, 0x00, 0x38, 0x4F, 0x5A, 0xE5, 0x0D, 0x28,
> - 0xB5, 0xF8, 0xDC, 0x54, 0x92, 0xB2, 0xB0, 0xA8,
>

RE: [PATCH v5] app/eventdev: add crypto producer mode

[Van Haaren, Harry]

> -Original Message-
> From: Shijith Thotton 
> Sent: Wednesday, February 23, 2022 10:02 AM
> To: Gujjar, Abhinandan S ; Van Haaren, Harry
> ; Jerin Jacob ; Hemant
> Agrawal ; Nipun Gupta 
> Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
> 
> 
> 
> >-Original Message-
> >From: Gujjar, Abhinandan S 
> >Sent: Wednesday, February 23, 2022 2:32 PM
> >To: Shijith Thotton ; Van Haaren, Harry
> >; Jerin Jacob ; Hemant
> >Agrawal ; Nipun Gupta 
> >Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> >Subject: [EXT] RE: [PATCH v5] app/eventdev: add crypto producer mode
> >
> >External Email
> >
> >--
> >
> >
> >> -Original Message-
> >> From: Shijith Thotton 
> >> Sent: Tuesday, February 22, 2022 12:34 PM
> >> To: Van Haaren, Harry ; Gujjar, Abhinandan S
> >> ; Jerin Jacob ;
> >> Hemant Agrawal ; Nipun Gupta
> >> 
> >> Cc: Jerin Jacob Kollanukkaran ; dev@dpdk.org
> >> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
> >>
> >> >> >
> >> >> > + @Van Haaren, Harry
> >> >
> >> >Hi All,
> >> >
> >> >I have been away on vacation for the last week - hence the delay in
> >> >reply on this thread.
> >> >
> >> >
> >> >
> >> >> > > [1]
> >> >> > > Steps to reproduce:
> >> >> > > * Clone https://urldefense.proofpoint.com/v2/url?u=http-
> >> >3A__dpdk.org_git_next_dpdk-2Dnext-
> >> >2Deventdev&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=G9w4KsPaQLAC
> >> BfGCL
> >> >35PtiRH996yqJDxAZwrWegU2qQ&m=-yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=lZjsn2zecck8IBBQRA7fId7
> >> BXSYKk
> >> >U8Tjj10gNQLB6U&e=
> >> >> > > * Apply [v5] app/eventdev: add crypto producer mode
> >> >> > >   git-pw --server
> >> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> >> Q&r=G
> >> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >> >yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> >> SneOm
> >> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> >> > > patch apply 107645
> >> >> > > * Apply [RFC] app/eventdev: add software crypto adapter support
> >> >> > >   git-pw --server
> >> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> >> Q&r=G
> >> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >> >yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> >> SneOm
> >> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> >> > > patch apply 107029
> >> >> > > * meson x86_build_debug  -Dc_args='-g -O0' -
> >> Ddisable_drivers="*/cnxk"
> >> >> > > * ninja -C x86_build_debug
> >> >> > > * Command to reproduce crash
> >> >> > >   sudo ./x86_build_debug/app/dpdk-test-eventdev -l 0-8 -s 0xf0
> >> >> > > --vdev=event_sw0  --vdev="crypto_null" -- --prod_type_cryptodev
> >> >> > > --crypto_adptr_mode 0 --test=perf_queue --stlist=a --wlcores 1
> >> >> > > --plcores 2
> >> >
> >> >Can confirm that these steps indeed cause segfault as reported.
> >> >
> >> >In debugging, it seems like there are *zero* NEW events, and large
> >> >numbers of RELEASE events are enqueued... if so, this is not compliant to
> >> the Eventdev API.
> >> >Can somebody confirm that?
> >> >
> >> >The SW PMD is being told there are events to release, but there aren't 
> >> >any.
> >> >Eventually, this leads to a mismatch in credit allocations, which then
> >> >causes the IQ-chunks datastructure to corrupt.
> >> >
> >> >All in all, I'm not convinced this is a SW PMD issue yet - initial
> >> >testing points to incorrect event OP NEW/FWD/RELEASE usage. Can we
> >> >verify that the OPs being sent are correct?
> >> >
> >>
> >> Looks like an issue in crypto adapter service. The service is starting with
> >> OP_FORWARD, if RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE is set.
> >> Abhinandan can confirm.
> >
> >The service is started with what application is requesting for from the 
> >adapter.
> >The app can request either OP_NEW or FWD mode. Adapter while creating a
> new
> >instance
> >requests for evendev caps & based on that adapter enqueues events back to
> >evdev
> >in FWD or NEW mode. All events are triggered by application and adapter is
> >transparent here. Could you please explain me how this creating an issue?
> >
> 
> In lib/eventdev/rte_event_crypto_adapter.c:
> ...
> eca_ops_enqueue_burst(struct event_crypto_adapter *adapter,
> ...
> rte_memcpy(ev, &m_data->response_info, sizeof(*ev));
> ev->event_ptr = ops[i];
> ev->event_type = RTE_EVENT_TYPE_CRYPTODEV;
> if (adapter->implicit_release_disabled)
> ev->op = RTE_EVENT_OP_FORWARD;
> else
> ev->op = RTE_EVENT_OP_NEW;
>  ...
> 
> op and event_type is set in the service. Changing FORWARD to NEW will fix the
> crash.

Y

[PATCH] net/mlx5: fix destroying empty matchers list

[Adham Masarwah]

The table remove callback function is trying to destroy the
matchers list associated with table entries without checking
if the list is valid, which causes nullptr dereference.
Fixed by validating the matchers list before destroying it.

Issue can be reproduced with testpmd on Windows, when you run:
port close all

Fixes: 1872635570be ("net/mlx5: make matcher list thread safe")
Cc: sta...@dpdk.org

Signed-off-by: Adham Masarwah 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_dv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ef9c66eddf..baef252a7a 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -10503,7 +10503,8 @@ flow_dv_tbl_remove_cb(void *tool_ctx, struct 
mlx5_list_entry *entry)
tbl_data->tunnel->tunnel_id : 0,
tbl_data->group_id);
}
-   mlx5_list_destroy(tbl_data->matchers);
+   if (tbl_data->matchers)
+   mlx5_list_destroy(tbl_data->matchers);
mlx5_ipool_free(sh->ipool[MLX5_IPOOL_JUMP], tbl_data->idx);
 }
 
-- 
2.16.1.windows.4

RE: [dpdk-dev] [PATCH] net/ice: fix wrong data path selection in secondary process

[Zhang, Liheng]

They are both included in DPDK21.11 according to my alignment with Qi and 
Dapeng.

> -Original Message-
> From: Dong, Yao 
> Sent: Tuesday, February 22, 2022 8:07 PM
> To: Kevin Traynor 
> Cc: Zhang, Qi Z ; Navin Srinivas
> ; Wang, Yixue ; Yang,
> Qiming ; Zhang, Liheng ;
> dev@dpdk.org; sta...@dpdk.org; Xueming(Steven) Li 
> Subject: Re: [dpdk-dev] [PATCH] net/ice: fix wrong data path selection in
> secondary process
> 
> are those patch available/merged in dpdk 21.11?
> 
> Dong yao (from my iPhone)
> 
> > 在 2022年2月22日，下午5:26，Kevin Traynor  写
> 道：
> >
> > On 22/02/2022 04:30, Zhang, Qi Z wrote:
> >> Hi Srinivas:
> >> This is the fix for PF driver only, for VF we have a separated fix and it 
> >> is not be
> captured in 20.11.3, but I saw the patches are already merged in stable tree.
> >> You can try with latest 20.11.4-rc1,   or wait for 20.11.4 LTS.
> >
> > 20.11.4 is already released. Xueming sent details here
> > http://inbox.dpdk.org/announce/20220124084950.482883-1-
> xuemingl@nvidia
> > .com/T/#u
> >
> > You can check the release notes (or git) for specific fixes
> > https://git.dpdk.org/dpdk-stable/tree/doc/guides/rel_notes/release_20_
> > 11.rst?h=20.11
> >
> >> Regards
> >> Qi
> >> From: Navin Srinivas 
> >> Sent: Tuesday, February 22, 2022 11:56 AM
> >> To: Zhang, Qi Z 
> >> Cc: Wang, Yixue ; Yang, Qiming
> >> ; Zhang, Liheng ;
> >> Dong, Yao ; dev@dpdk.org; sta...@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] net/ice: fix wrong data path
> >> selection in secondary process Hi, Is this tested on VFs? I saw crash
> >> on both PF as well as VF, on 20.11.1, but did not see PF crash on
> >> 20.11.3, I'm seeing a crash on the secondary process when it receives
> >> packet on the VF, but PF doesn't crash now on 20.11.3 So I suspect this is 
> >> the
> patch which is fixing the issue on ICE secondary process crash on PF.
> >> Thanks & Regards,
> >> Navin Srinivas
> >>> On Thu, Jun 3, 2021 at 3:51 PM Zhang, Qi Z
> mailto:qi.z.zh...@intel.com>> wrote:
> >>> -Original Message-
> >>> From: Wang, Yixue
> >>> mailto:yixue.w...@intel.com>>
> >>> Sent: Thursday, June 3, 2021 6:04 PM
> >>> To: Zhang, Qi Z mailto:qi.z.zh...@intel.com>>;
> >>> Yang, Qiming mailto:qiming.y...@intel.com>>
> >>> Cc: Zhang, Liheng
> >>> mailto:liheng.zh...@intel.com>>; Dong, Yao
> >>> mailto:yao.d...@intel.com>>;
> >>> dev@dpdk.org;
> >>> sta...@dpdk.org
> >>> Subject: RE: [PATCH] net/ice: fix wrong data path selection in
> >>> secondary process
> >>>
> >>> Hi, Qi
> >>>
> >>> I've tested this patch and it works.
> >>>
> >>> Best Regards,
> >>> Yixue.
> >>>
>  -Original Message-
>  From: Zhang, Qi Z
>  mailto:qi.z.zh...@intel.com>>
>  Sent: Monday, May 24, 2021 17:08
>  To: Yang, Qiming
>  mailto:qiming.y...@intel.com>>
>  Cc: Zhang, Liheng
>  mailto:liheng.zh...@intel.com>>; Wang,
>  Yixue mailto:yixue.w...@intel.com>>; Dong,
>  Yao mailto:yao.d...@intel.com>>;
>  dev@dpdk.org;
>  Zhang, Qi Z mailto:qi.z.zh...@intel.com>>;
>  sta...@dpdk.org
>  Subject: [PATCH] net/ice: fix wrong data path selection in
>  secondary process
> 
>  The flag use_avx2 and use_avx512 are defined as local variables,
>  they will not be aware by the secondary process, then wrong data
>  path is selected. Fix the issue by moving them into struct ice_adapter.
> 
>  Fixes: ae60d3c9b227 ("net/ice: support Rx AVX2 vector")
>  Fixes: 2d5f6953d56d ("net/ice: support vector AVX2 in Tx")
>  Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
>  Cc: sta...@dpdk.org
> 
>  Reported-by: Yixue Wang
>  mailto:yixue.w...@intel.com>>
>  Signed-off-by: Qi Zhang
>  mailto:qi.z.zh...@intel.com>>
> >> Tested-by: Yixue Wang
> >> mailto:yixue.w...@intel.com>>
> >> Applied to dpdk-next-net-intel.
> >> Thanks
> >> Qi
> >

Re: [PATCH v1] net/i40e: fix coverity issue

[Ferruh Yigit]

On 2/23/2022 6:41 AM, Steve Yang wrote:

Cast 1 to type uint64_t to avoid overflow.

CID 375812 (#1 of 1):
Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
overflow_before_widen: Potentially overflowing expression 1 << 2 * i + 1
with type int (32 bits, signed) is evaluated using 32-bit arithmetic, and
then used in a context that expects an expression of type uint64_t
(64 bits, unsigned).

Coverity issue: 375812
Fixes: 5fec01c35c49 ("net/i40e: support Linux VF to configure IRQ link list")

Signed-off-by: Steve Yang 


Hi Steve,

Can you please describe what is actually done in the
patch title?
Fixing a static tool warning is not descriptive enough.

[PATCH v2 0/2] Wangxun log fixes

[Jiawen Wu]

Remove redundant debug logs and unify the log format.

v2:
- Fix compile error.
- Merge broken log message lines.
- Use 'RTE_ETHER_ADDR_PRT_FMT' for MAC format.

Jiawen Wu (2):
  net/ngbe: fix debug log
  net/txgbe: fix debug log

 drivers/net/ngbe/base/ngbe_eeprom.c   |  22 +--
 drivers/net/ngbe/base/ngbe_hw.c   | 152 +--
 drivers/net/ngbe/base/ngbe_mbx.c  |  22 ---
 drivers/net/ngbe/base/ngbe_mng.c  |  16 +-
 drivers/net/ngbe/base/ngbe_phy.c  |  30 +---
 drivers/net/ngbe/base/ngbe_phy_mvl.c  |  17 +--
 drivers/net/ngbe/base/ngbe_phy_rtl.c  |  18 +--
 drivers/net/ngbe/base/ngbe_phy_yt.c   |  18 +--
 drivers/net/ngbe/ngbe_logs.h  |   7 +-
 drivers/net/txgbe/base/meson.build|   2 +-
 drivers/net/txgbe/base/txgbe_eeprom.c |  41 ++
 drivers/net/txgbe/base/txgbe_hw.c | 202 ++
 drivers/net/txgbe/base/txgbe_mbx.c|  38 -
 drivers/net/txgbe/base/txgbe_mng.c|  21 +--
 drivers/net/txgbe/base/txgbe_osdep.h  |   1 +
 drivers/net/txgbe/base/txgbe_phy.c|  84 ++-
 drivers/net/txgbe/base/txgbe_vf.c |  12 +-
 drivers/net/txgbe/txgbe_logs.h|   7 +-
 18 files changed, 144 insertions(+), 566 deletions(-)

-- 
2.21.0.windows.1

[PATCH v2 1/2] net/ngbe: fix debug log

[Jiawen Wu]

Remove 'DEBUGFUNC' due to too many invalid debug log prints, unify the
DEBUG level macros.

Fixes: cc934df178ab ("net/ngbe: add log and error types")
Cc: sta...@dpdk.org

Signed-off-by: Jiawen Wu 
---
 drivers/net/ngbe/base/ngbe_eeprom.c  |  22 +---
 drivers/net/ngbe/base/ngbe_hw.c  | 152 +++
 drivers/net/ngbe/base/ngbe_mbx.c |  22 
 drivers/net/ngbe/base/ngbe_mng.c |  16 +--
 drivers/net/ngbe/base/ngbe_phy.c |  30 ++
 drivers/net/ngbe/base/ngbe_phy_mvl.c |  17 +--
 drivers/net/ngbe/base/ngbe_phy_rtl.c |  18 ++--
 drivers/net/ngbe/base/ngbe_phy_yt.c  |  18 +---
 drivers/net/ngbe/ngbe_logs.h |   7 +-
 9 files changed, 65 insertions(+), 237 deletions(-)

diff --git a/drivers/net/ngbe/base/ngbe_eeprom.c 
b/drivers/net/ngbe/base/ngbe_eeprom.c
index f9a876e9bd..6375ee9b29 100644
--- a/drivers/net/ngbe/base/ngbe_eeprom.c
+++ b/drivers/net/ngbe/base/ngbe_eeprom.c
@@ -20,8 +20,6 @@ s32 ngbe_init_eeprom_params(struct ngbe_hw *hw)
u32 eec;
u16 eeprom_size;
 
-   DEBUGFUNC("ngbe_init_eeprom_params");
-
if (eeprom->type != ngbe_eeprom_unknown)
return 0;
 
@@ -52,8 +50,8 @@ s32 ngbe_init_eeprom_params(struct ngbe_hw *hw)
eeprom->address_bits = 16;
eeprom->sw_addr = 0x80;
 
-   DEBUGOUT("eeprom params: type = %d, size = %d, address bits: "
- "%d %d\n", eeprom->type, eeprom->word_size,
+   DEBUGOUT("eeprom params: type = %d, size = %d, address bits: %d %d",
+ eeprom->type, eeprom->word_size,
  eeprom->address_bits, eeprom->sw_addr);
 
return 0;
@@ -72,9 +70,6 @@ s32 ngbe_get_eeprom_semaphore(struct ngbe_hw *hw)
u32 i;
u32 swsm;
 
-   DEBUGFUNC("ngbe_get_eeprom_semaphore");
-
-
/* Get SMBI software semaphore between device drivers first */
for (i = 0; i < timeout; i++) {
/*
@@ -90,8 +85,7 @@ s32 ngbe_get_eeprom_semaphore(struct ngbe_hw *hw)
}
 
if (i == timeout) {
-   DEBUGOUT("Driver can't access the eeprom - SMBI Semaphore "
-"not granted.\n");
+   DEBUGOUT("Driver can't access the eeprom - SMBI Semaphore not 
granted.");
/*
 * this release is particularly important because our attempts
 * above to get the semaphore may have succeeded, and if there
@@ -134,13 +128,12 @@ s32 ngbe_get_eeprom_semaphore(struct ngbe_hw *hw)
 * was not granted because we don't have access to the EEPROM
 */
if (i >= timeout) {
-   DEBUGOUT("SWESMBI Software EEPROM semaphore not 
granted.\n");
+   DEBUGOUT("SWESMBI Software EEPROM semaphore not 
granted.");
ngbe_release_eeprom_semaphore(hw);
status = NGBE_ERR_EEPROM;
}
} else {
-   DEBUGOUT("Software semaphore SMBI between device drivers "
-"not granted.\n");
+   DEBUGOUT("Software semaphore SMBI between device drivers not 
granted.");
}
 
return status;
@@ -154,8 +147,6 @@ s32 ngbe_get_eeprom_semaphore(struct ngbe_hw *hw)
  **/
 void ngbe_release_eeprom_semaphore(struct ngbe_hw *hw)
 {
-   DEBUGFUNC("ngbe_release_eeprom_semaphore");
-
wr32m(hw, NGBE_MNGSWSYNC, NGBE_MNGSWSYNC_REQ, 0);
wr32m(hw, NGBE_SWSEM, NGBE_SWSEM_PF, 0);
ngbe_flush(hw);
@@ -276,7 +267,6 @@ s32 ngbe_validate_eeprom_checksum_em(struct ngbe_hw *hw,
u32 eeprom_cksum_devcap = 0;
int err = 0;
 
-   DEBUGFUNC("ngbe_validate_eeprom_checksum_em");
UNREFERENCED_PARAMETER(checksum_val);
 
/* Check EEPROM only once */
@@ -315,8 +305,6 @@ s32 ngbe_save_eeprom_version(struct ngbe_hw *hw)
u32 etrack_id = 0;
u32 offset = (hw->rom.sw_addr + NGBE_EEPROM_VERSION_L) << 1;
 
-   DEBUGFUNC("ngbe_save_eeprom_version");
-
if (hw->bus.lan_id == 0) {
hw->rom.read32(hw, offset, &eeprom_verl);
etrack_id = eeprom_verl;
diff --git a/drivers/net/ngbe/base/ngbe_hw.c b/drivers/net/ngbe/base/ngbe_hw.c
index 931fe8c8cb..fa2d749240 100644
--- a/drivers/net/ngbe/base/ngbe_hw.c
+++ b/drivers/net/ngbe/base/ngbe_hw.c
@@ -20,8 +20,6 @@ s32 ngbe_start_hw(struct ngbe_hw *hw)
 {
s32 err;
 
-   DEBUGFUNC("ngbe_start_hw");
-
/* Clear the VLAN filter table */
hw->mac.clear_vfta(hw);
 
@@ -31,7 +29,7 @@ s32 ngbe_start_hw(struct ngbe_hw *hw)
/* Setup flow control */
err = hw->mac.setup_fc(hw);
if (err != 0 && err != NGBE_NOT_IMPLEMENTED) {
-   DEBUGOUT("Flow control setup failed, returning %d\n", err);
+   DEBUGOUT("Flow control setup failed, returning %d", err);
return err;
}
 
@@ -55,8 +53,6 @@ s32 ngbe_init_hw(struct ngbe_hw *hw)
 {
s32 status;
 
-   DEBUGFUNC("ngbe_init_hw");
-
 

[PATCH v2 2/2] net/txgbe: fix debug log

[Jiawen Wu]

Remove 'DEBUGFUNC' due to too many invalid debug log prints, unify the
DEBUG level macros.

Fixes: 7dc117068a7c ("net/txgbe: support probe and remove")
Cc: sta...@dpdk.org

Signed-off-by: Jiawen Wu 
---
 drivers/net/txgbe/base/meson.build|   2 +-
 drivers/net/txgbe/base/txgbe_eeprom.c |  41 ++
 drivers/net/txgbe/base/txgbe_hw.c | 202 ++
 drivers/net/txgbe/base/txgbe_mbx.c|  38 -
 drivers/net/txgbe/base/txgbe_mng.c|  21 +--
 drivers/net/txgbe/base/txgbe_osdep.h  |   1 +
 drivers/net/txgbe/base/txgbe_phy.c|  84 ++-
 drivers/net/txgbe/base/txgbe_vf.c |  12 +-
 drivers/net/txgbe/txgbe_logs.h|   7 +-
 9 files changed, 79 insertions(+), 329 deletions(-)

diff --git a/drivers/net/txgbe/base/meson.build 
b/drivers/net/txgbe/base/meson.build
index 7a30191472..09da79af40 100644
--- a/drivers/net/txgbe/base/meson.build
+++ b/drivers/net/txgbe/base/meson.build
@@ -22,6 +22,6 @@ foreach flag: error_cflags
 endforeach
 
 base_lib = static_library('txgbe_base', sources,
-dependencies: static_rte_eal,
+dependencies: [static_rte_eal, static_rte_ethdev],
 c_args: c_args)
 base_objs = base_lib.extract_all_objects(recursive: true)
diff --git a/drivers/net/txgbe/base/txgbe_eeprom.c 
b/drivers/net/txgbe/base/txgbe_eeprom.c
index 72901cd0b0..4ed6bd6728 100644
--- a/drivers/net/txgbe/base/txgbe_eeprom.c
+++ b/drivers/net/txgbe/base/txgbe_eeprom.c
@@ -21,8 +21,6 @@ s32 txgbe_init_eeprom_params(struct txgbe_hw *hw)
u16 eeprom_size;
int err = 0;
 
-   DEBUGFUNC("txgbe_init_eeprom_params");
-
if (eeprom->type != txgbe_eeprom_unknown)
return 0;
 
@@ -54,12 +52,12 @@ s32 txgbe_init_eeprom_params(struct txgbe_hw *hw)
 
err = eeprom->read32(hw, TXGBE_SW_REGION_PTR << 1, &eeprom->sw_addr);
if (err) {
-   DEBUGOUT("EEPROM read failed.\n");
+   DEBUGOUT("EEPROM read failed.");
return err;
}
 
-   DEBUGOUT("eeprom params: type = %d, size = %d, address bits: "
- "%d %d\n", eeprom->type, eeprom->word_size,
+   DEBUGOUT("eeprom params: type = %d, size = %d, address bits: %d %d",
+ eeprom->type, eeprom->word_size,
  eeprom->address_bits, eeprom->sw_addr);
 
return 0;
@@ -78,9 +76,6 @@ s32 txgbe_get_eeprom_semaphore(struct txgbe_hw *hw)
u32 i;
u32 swsm;
 
-   DEBUGFUNC("txgbe_get_eeprom_semaphore");
-
-
/* Get SMBI software semaphore between device drivers first */
for (i = 0; i < timeout; i++) {
/*
@@ -96,8 +91,7 @@ s32 txgbe_get_eeprom_semaphore(struct txgbe_hw *hw)
}
 
if (i == timeout) {
-   DEBUGOUT("Driver can't access the eeprom - SMBI Semaphore "
-"not granted.\n");
+   DEBUGOUT("Driver can't access the eeprom - SMBI Semaphore not 
granted.");
/*
 * this release is particularly important because our attempts
 * above to get the semaphore may have succeeded, and if there
@@ -140,13 +134,12 @@ s32 txgbe_get_eeprom_semaphore(struct txgbe_hw *hw)
 * was not granted because we don't have access to the EEPROM
 */
if (i >= timeout) {
-   DEBUGOUT("SWESMBI Software EEPROM semaphore not 
granted.\n");
+   DEBUGOUT("SWESMBI Software EEPROM semaphore not 
granted.");
txgbe_release_eeprom_semaphore(hw);
status = TXGBE_ERR_EEPROM;
}
} else {
-   DEBUGOUT("Software semaphore SMBI between device drivers "
-"not granted.\n");
+   DEBUGOUT("Software semaphore SMBI between device drivers not 
granted.");
}
 
return status;
@@ -160,8 +153,6 @@ s32 txgbe_get_eeprom_semaphore(struct txgbe_hw *hw)
  **/
 void txgbe_release_eeprom_semaphore(struct txgbe_hw *hw)
 {
-   DEBUGFUNC("txgbe_release_eeprom_semaphore");
-
wr32m(hw, TXGBE_MNGSWSYNC, TXGBE_MNGSWSYNC_REQ, 0);
wr32m(hw, TXGBE_SWSEM, TXGBE_SWSEM_PF, 0);
txgbe_flush(hw);
@@ -290,8 +281,6 @@ s32 txgbe_ee_write16(struct txgbe_hw *hw, u32 offset,
u32 addr = (offset << 1);
int err;
 
-   DEBUGFUNC("\n");
-
err = hw->mac.acquire_swfw_sync(hw, mask);
if (err)
return err;
@@ -348,8 +337,6 @@ s32 txgbe_ee_writew_sw(struct txgbe_hw *hw, u32 offset,
u32 addr = hw->rom.sw_addr + (offset << 1);
int err;
 
-   DEBUGFUNC("\n");
-
err = hw->mac.acquire_swfw_sync(hw, mask);
if (err)
return err;
@@ -399,11 +386,9 @@ s32 txgbe_calc_eeprom_checksum(struct txgbe_hw *hw)
int err;
u16 buffer[BUFF_SIZE];
 
-   DEBUGFUNC("txgbe_calc_eeprom_checksum");
-
err = hw->rom.readw_sw(hw, TXGBE_EEPROM_CHECKSUM, &read_checksum);
if (err) {
-

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Zhang, Roy Fan]

Hi Anoob,

You are right QAT doesn't like these test vectors - for the reason Arek stated 
in the patch.
We are in the same page on updating the capability - we already planned for 
next release.
Since you also agree these cases are not useful - can we do both instead 
(removing these test vectors in this release and update the capability in the 
next)?

Regards,
Fan

> -Original Message-
> From: Anoob Joseph 
> Sent: Wednesday, February 23, 2022 10:09 AM
> To: Kusztal, ArkadiuszX 
> Cc: Akhil Goyal ; Zhang, Roy Fan
> ; Umesh Kartha ;
> Ramkumar Balu ; dev@dpdk.org
> Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> cases
> 
> Hi Arek,
> 
> I agree that these cases may not be particularly useful from cryptographic
> standpoint, but how do we say from what values a PMD "must" support? Are
> you having some trouble supporting some of these values? Should we
> consider extending capabilities to help with this rather than just removing
> the test vectors?
> 
> Thanks,
> Anoob
> 
> > -Original Message-
> > From: Arek Kusztal 
> > Sent: Tuesday, February 8, 2022 4:25 PM
> > To: dev@dpdk.org
> > Cc: Akhil Goyal ; roy.fan.zh...@intel.com; Arek
> > Kusztal 
> > Subject: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> cases
> >
> > External Email
> >
> > --
> > Even if mod exp tests cases where modulus is not the biggest number are
> > mathematically correct and can be computed, cryptographically it is useless
> > and PMD does not need to support it.
> >
> > Signed-off-by: Arek Kusztal 
> > ---
> >  app/test/test_cryptodev_mod_test_vectors.h | 501 --
> --
> > -
> >  1 file changed, 501 deletions(-)
> >
> > diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> > b/app/test/test_cryptodev_mod_test_vectors.h
> > index c66f4b18bc..d108059624 100644
> > --- a/app/test/test_cryptodev_mod_test_vectors.h
> > +++ b/app/test/test_cryptodev_mod_test_vectors.h
> > @@ -167,141 +167,6 @@ modex_test_data modex_test_case[] = {  },  {
> > .description = "Modular Exponentiation "
> > -  "(mod=8, base=65, exp=17, res=8)",
> > -   .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> > -   .base = {
> > -   .data = {
> > -   0x25, 0x74, 0x41, 0xCE, 0xFA, 0x5C, 0x07, 0x2A,
> > -   0xD1, 0x74, 0xF3, 0x3D, 0xE1, 0xCC, 0xC3, 0x18,
> > -   0x7E, 0x4A, 0x21, 0x9F, 0x97, 0xA3, 0x26, 0x85,
> > -   0x85, 0xD9, 0x9B, 0xE3, 0xBA, 0xB3, 0x70, 0xC9,
> > -   0x26, 0x68, 0xE4, 0xB7, 0x4C, 0x88, 0x48, 0xC1,
> > -   0x6B, 0xC6, 0x3C, 0x00, 0x8C, 0x6B, 0xC6, 0x11,
> > -   0xD0, 0xD6, 0x61, 0x5D, 0xEC, 0xAA, 0xBA, 0x3B,
> > -   0x7D, 0xB3, 0x0D, 0x3F, 0xA5, 0x4D, 0xEE, 0xE4,
> > -   0xAC
> > -   },
> > -   .len = 65
> > -   },
> > -   .exponent = {
> > -   .data = {
> > -   0x1C, 0x54, 0x2F, 0xCA, 0xDE, 0x4F, 0x17, 0x38,
> > -   0x69, 0x87, 0xB4, 0xFF, 0x3A, 0x6C, 0x82, 0x70,
> > -   0x53
> > -   },
> > -   .len = 17
> > -   },
> > -   .reminder = {
> > -   .data = {
> > -   0x52, 0x06, 0x1A, 0x35, 0x70, 0x33, 0x78, 0x45
> > -   },
> > -   .len = 8
> > -   },
> > -   .modulus = {
> > -   .data = {
> > -   0x6B, 0x6D, 0xFA, 0xCB, 0x09, 0x5D, 0x9C, 0xFD
> > -   },
> > -   .len = 8
> > -   },
> > -   .result_len = 8
> > -},
> > -{
> > -   .description = "Modular Exponentiation "
> > -  "(mod=100, base=150, exp=192, res=100)",
> > -   .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> > -   .base = {
> > -   .data = {
> > -   0xC1, 0xA1, 0x04, 0xE4, 0x4D, 0x4A, 0xD3, 0x5C,
> > -   0xB3, 0xD0, 0x16, 0x51, 0xA7, 0xF4, 0x82, 0x6C,
> > -   0x22, 0xDD, 0x4D, 0xAA, 0x70, 0x30, 0x25, 0xA7,
> > -   0xFA, 0xA9, 0xF2, 0x20, 0x55, 0x9B, 0xEA, 0x26,
> > -   0xF6, 0xB5, 0xF8, 0x9C, 0x46, 0x21, 0x85, 0x0E,
> > -   0x38, 0x73, 0x01, 0xC6, 0x72, 0x67, 0x9B, 0x49,
> > -   0xCE, 0x48, 0xB7, 0x4A, 0xEE, 0x08, 0x21, 0x26,
> > -   0xF3, 0x21, 0x77, 0xE7, 0x3C, 0x77, 0xF4, 0x0A,
> > -   0x82, 0xC8, 0x16, 0x94, 0x6C, 0xBF, 0xA8, 0xD8,
> > -   0x8B, 0x7D, 0x27, 0x60, 0xAC, 0x06, 0x69, 0x7E,
> > -   0x46, 0x2C, 0xE2, 0xD1, 0x13, 0x50, 0x7D, 0xCE,
> > -   0x4D, 0xC4, 0x5D, 0x81, 0xFB, 0x6B, 0x11, 0x4A,
> > -   0x2D, 0xA2, 0x03, 0x55, 0x77, 0x8C, 0x3D, 0xA1,
> > -   0xAD, 0xBE, 0x9C, 0x72, 0xE5, 0xA5, 0xFB, 0x49,
> > -   0x5F, 0x13, 0x48, 0xC7, 0xAC, 0xD1, 0x0F, 0x5E,
> > -   0xDF, 0x9C, 0xC7, 0xF5, 0x19, 0xFD, 0xC5, 0x77,

RE: [PATCH] net/mlx5: fix destroying empty matchers list

[Tal Shnaiderman]

> Subject: [PATCH] net/mlx5: fix destroying empty matchers list
> 
> The table remove callback function is trying to destroy the matchers list
> associated with table entries without checking if the list is valid, which 
> causes
> nullptr dereference.
> Fixed by validating the matchers list before destroying it.
> 
> Issue can be reproduced with testpmd on Windows, when you run:
> port close all
> 
> Fixes: 1872635570be ("net/mlx5: make matcher list thread safe")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Adham Masarwah 
> Acked-by: Viacheslav Ovsiienko 
> ---
>  drivers/net/mlx5/mlx5_flow_dv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index ef9c66eddf..baef252a7a 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -10503,7 +10503,8 @@ flow_dv_tbl_remove_cb(void *tool_ctx, struct
> mlx5_list_entry *entry)
>   tbl_data->tunnel->tunnel_id : 0,
>   tbl_data->group_id);
>   }
> - mlx5_list_destroy(tbl_data->matchers);
> + if (tbl_data->matchers)
> + mlx5_list_destroy(tbl_data->matchers);
>   mlx5_ipool_free(sh->ipool[MLX5_IPOOL_JUMP], tbl_data->idx);  }
> 
> --
> 2.16.1.windows.4

Acked-by: Tal Shnaiderman 

[PATCH v2 0/2] Add new IPsec test cases

[Volodymyr Fialko]

Following test cases were added:
- IPv4 TTL
- IPv6 hop limit
- IPv4 L4 checksum in transport mode

v2:
- rebase to the latest for-main

Volodymyr Fialko (2):
  test/crypto: add TTL and hop limit decrement cases
  test/crypto: add L4 checksum case for transport mode

 app/test/test_cryptodev.c| 44 
 app/test/test_cryptodev_security_ipsec.c | 37 
 app/test/test_cryptodev_security_ipsec.h |  1 +
 3 files changed, 82 insertions(+)

-- 
2.25.1

[PATCH v2 1/2] test/crypto: add TTL and hop limit decrement cases

[Volodymyr Fialko]

Add test cases to verify TTL and hop limit decrement with lookaside
IPsec offload.

Signed-off-by: Volodymyr Fialko 
Acked-by: Anoob Joseph 
---
 app/test/test_cryptodev.c| 29 +++
 app/test/test_cryptodev_security_ipsec.c | 37 
 app/test/test_cryptodev_security_ipsec.h |  1 +
 3 files changed, 67 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index fc3c09d86f..694b073f4f 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -10102,6 +10102,27 @@ test_PDCP_PROTO_all(void)
return TEST_SUCCESS;
 }
 
+static int
+test_ipsec_proto_ipv4_ttl_decrement(const void *data __rte_unused)
+{
+   struct ipsec_test_flags flags = {
+   .dec_ttl_or_hop_limit = true
+   };
+
+   return test_ipsec_proto_all(&flags);
+}
+
+static int
+test_ipsec_proto_ipv6_hop_limit_decrement(const void *data __rte_unused)
+{
+   struct ipsec_test_flags flags = {
+   .ipv6 = true,
+   .dec_ttl_or_hop_limit = true
+   };
+
+   return test_ipsec_proto_all(&flags);
+}
+
 static int
 test_docsis_proto_uplink(const void *data)
 {
@@ -15158,6 +15179,14 @@ static struct unit_test_suite ipsec_proto_testsuite  = 
{
ut_setup_security, ut_teardown,
test_ipsec_proto_pkt_esn_antireplay4096,
&pkt_aes_128_gcm),
+   TEST_CASE_NAMED_ST(
+   "Tunnel header IPv4 decrement inner TTL",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_ipv4_ttl_decrement),
+   TEST_CASE_NAMED_ST(
+   "Tunnel header IPv6 decrement inner hop limit",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_ipv6_hop_limit_decrement),
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
diff --git a/app/test/test_cryptodev_security_ipsec.c 
b/app/test/test_cryptodev_security_ipsec.c
index 3887b05135..f66360f4c4 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -443,6 +443,9 @@ test_ipsec_td_prepare(const struct crypto_param *param1,
if (flags->dscp == TEST_IPSEC_COPY_DSCP_INNER_0 ||
flags->dscp == TEST_IPSEC_COPY_DSCP_INNER_1)
td->ipsec_xform.options.copy_dscp = 1;
+
+   if (flags->dec_ttl_or_hop_limit)
+   td->ipsec_xform.options.dec_ttl = 1;
}
 }
 
@@ -650,6 +653,32 @@ test_ipsec_l4_csum_verify(struct rte_mbuf *m)
return TEST_SUCCESS;
 }
 
+static int
+test_ipsec_ttl_or_hop_decrement_verify(void *received, void *expected)
+{
+   struct rte_ipv4_hdr *iph4_ex, *iph4_re;
+   struct rte_ipv6_hdr *iph6_ex, *iph6_re;
+
+   if (is_ipv4(received) && is_ipv4(expected)) {
+   iph4_ex = expected;
+   iph4_re = received;
+   iph4_ex->time_to_live -= 1;
+   if (iph4_re->time_to_live != iph4_ex->time_to_live)
+   return TEST_FAILED;
+   } else if (!is_ipv4(received) && !is_ipv4(expected)) {
+   iph6_ex = expected;
+   iph6_re = received;
+   iph6_ex->hop_limits -= 1;
+   if (iph6_re->hop_limits != iph6_ex->hop_limits)
+   return TEST_FAILED;
+   } else {
+   printf("IP header version miss match\n");
+   return TEST_FAILED;
+   }
+
+   return TEST_SUCCESS;
+}
+
 static int
 test_ipsec_td_verify(struct rte_mbuf *m, const struct ipsec_test_data *td,
 bool silent, const struct ipsec_test_flags *flags)
@@ -740,6 +769,14 @@ test_ipsec_td_verify(struct rte_mbuf *m, const struct 
ipsec_test_data *td,
 
memcpy(td_output_text, td->output_text.data + skip, len);
 
+   if ((td->ipsec_xform.direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS) &&
+   flags->dec_ttl_or_hop_limit) {
+   if (test_ipsec_ttl_or_hop_decrement_verify(output_text, 
td_output_text)) {
+   printf("Inner TTL/hop limit decrement test failed\n");
+   return TEST_FAILED;
+   }
+   }
+
if (test_ipsec_pkt_update(td_output_text, flags)) {
printf("Could not update expected vector");
return TEST_FAILED;
diff --git a/app/test/test_cryptodev_security_ipsec.h 
b/app/test/test_cryptodev_security_ipsec.h
index a15c1d3015..7529d2ae50 100644
--- a/app/test/test_cryptodev_security_ipsec.h
+++ b/app/test/test_cryptodev_security_ipsec.h
@@ -87,6 +87,7 @@ struct ipsec_test_flags {
bool antireplay;
enum df_flags df;
enum dscp_flags dscp;
+   bool dec_ttl_or_hop_limit;
 };
 
 struct crypto_param {
-- 
2.25.1

[PATCH v2 2/2] test/crypto: add L4 checksum case for transport mode

[Volodymyr Fialko]

Added test case to verify L4 checksum offload in IPsec transport mode.

Signed-off-by: Volodymyr Fialko 
Acked-by: Anoob Joseph 
---
 app/test/test_cryptodev.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 694b073f4f..a0c8926776 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -9724,6 +9724,17 @@ test_ipsec_proto_transport_v4(const void *data 
__rte_unused)
return test_ipsec_proto_all(&flags);
 }
 
+static int
+test_ipsec_proto_transport_l4_csum(const void *data __rte_unused)
+{
+   struct ipsec_test_flags flags = {
+   .l4_csum = true,
+   .transport = true,
+   };
+
+   return test_ipsec_proto_all(&flags);
+}
+
 static int
 test_ipsec_proto_stats(const void *data __rte_unused)
 {
@@ -15096,6 +15107,10 @@ static struct unit_test_suite ipsec_proto_testsuite  = 
{
"Transport IPv4",
ut_setup_security, ut_teardown,
test_ipsec_proto_transport_v4),
+   TEST_CASE_NAMED_ST(
+   "Transport l4 checksum",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_transport_l4_csum),
TEST_CASE_NAMED_ST(
"Statistics: success",
ut_setup_security, ut_teardown,
-- 
2.25.1

RE: more than 64 lcores not properly supported

[Morten Brørup]

+Thomas, you may be interested in this discussion about applications using an 
uint64_t bit mask to identify active lcores.

> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Wednesday, 23 February 2022 11.03
> 
> On 2/23/2022 7:17 AM, Morten Brørup wrote:
> >> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> >> Sent: Tuesday, 22 February 2022 17.03

[...]

> >>
> >> DPDK now supports > 64 lcores. So all code using/assuming a 64 bit
> mask
> >> is broken.
> >>
> >
> > Good point. Is there a TODO-list where such a general review request
> can be filed, or should we just file it as a system-wide bug in
> Bugzilla?
> >
> > Nonetheless, I think this one-line fix should be accepted as a short
> term solution.
> >
> 
> Hi Morten,
> 
> I suspect there can be more places that testpmd assumes
> max core number is 64, someone needs to spend time to
> analyze and fix it.

My point exactly. Someone needs to spend time to analyze all DPDK libraries and 
applications, and fix it where appropriate. Where do we register this required 
effort, so it can be picked up by someone?

Also, it should probably be mentioned as a known bug in the 22.03 release notes.

RE: [PATCH v2 1/2] test/crypto: add TTL and hop limit decrement cases

[Akhil Goyal]

> Add test cases to verify TTL and hop limit decrement with lookaside
> IPsec offload.
> 
> Signed-off-by: Volodymyr Fialko 
> Acked-by: Anoob Joseph 
Series Applied to dpdk-next-crypto

Thanks.

RE: [PATCH v3 1/3] examples/ipsec-secgw: update error prints to data path log

[Akhil Goyal]

> Update error prints in data path to RTE_LOG_DP().
> Error prints in fast path are not good for performance
> as they slow down the application when few bad packets are
> received.
> 
> Signed-off-by: Nithin Dabilpuram 
> Acked-by: Akhil Goyal 
> ---
Series Applied to dpdk-next-crypto

Thanks.

RE: [EXT] [PATCH] examples/l2fwd-crypto: fix potential overflow

[Akhil Goyal]

> Coverity flags an issue with 32-bit value. If max ethports value is
> configured with a value larger than 32 there will be an issue.
> Coverity issue: 375863 Unintentional integer overflow
> 
> Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
> Cc: declan.dohe...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Brian Dooley 
> ---
Acked-by: Akhil Goyal 

Applied to dpdk-next-crypto

Thanks.

RE: [EXT] [PATCH v1] baseband/acc100: avoid out-of-bounds access corner cases

[Akhil Goyal]

> Coverity issue: 375803, 375813, 375819, 375827, 375831
> The actual maximum number of gather pointers should have been limited
> Fixes: 5ad5060f8f7a ("baseband/acc100: add LDPC processing functions")
> 
> Signed-off-by: Nicolas Chautru 
Cc: sta...@dpdk.org
Applied to dpdk-next-crypto

Thanks

RE: [PATCH v2] crypto/virtio: fix out of bounds access bug

[Zhang, Roy Fan]

> -Original Message-
> From: Dooley, Brian 
> Sent: Tuesday, February 22, 2022 9:55 AM
> To: dev@dpdk.org
> Cc: Dooley, Brian ; Zhang, Roy Fan
> ; sta...@dpdk.org; Jay Zhou
> 
> Subject: [PATCH v2] crypto/virtio: fix out of bounds access bug
> 
> Coverity flags an untrusted loop bound. Check length of session iv.
> 
> Coverity issue: 375802
> 
> Fixes: b063e843fa03 ("crypto/virtio: fix IV physical address")
> Cc: roy.fan.zh...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Brian Dooley 
> 
> ---
Acked-by: Fan Zhang 

RE: [PATCH v2] crypto/virtio: fix out of bounds access bug

[Zhang, Roy Fan]

> -Original Message-
> From: Dooley, Brian 
> Sent: Tuesday, February 22, 2022 9:55 AM
> To: dev@dpdk.org
> Cc: Dooley, Brian ; Zhang, Roy Fan
> ; sta...@dpdk.org; Jay Zhou
> 
> Subject: [PATCH v2] crypto/virtio: fix out of bounds access bug
> 
> Coverity flags an untrusted loop bound. Check length of session iv.
> 
> Coverity issue: 375802
> 
> Fixes: b063e843fa03 ("crypto/virtio: fix IV physical address")
> Cc: roy.fan.zh...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Brian Dooley 
> 
> ---
Reacking as the last ack not shown in patchwork
Acked-by: Fan Zhang 

RE: [PATCH v2] crypto/virtio: fix out of bounds access bug

[Akhil Goyal]

> > Coverity flags an untrusted loop bound. Check length of session iv.
> >
> > Coverity issue: 375802
> >
> > Fixes: b063e843fa03 ("crypto/virtio: fix IV physical address")
> > Cc: roy.fan.zh...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Brian Dooley 
> >
> > ---
> Reacking as the last ack not shown in patchwork
> Acked-by: Fan Zhang 

Applied to dpdk-next-crypto

Thanks.

Re: more than 64 lcores not properly supported

[Ferruh Yigit]

On 2/23/2022 10:42 AM, Morten Brørup wrote:

+Thomas, you may be interested in this discussion about applications using an 
uint64_t bit mask to identify active lcores.


From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
Sent: Wednesday, 23 February 2022 11.03

On 2/23/2022 7:17 AM, Morten Brørup wrote:

From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Tuesday, 22 February 2022 17.03


[...]



DPDK now supports > 64 lcores. So all code using/assuming a 64 bit

mask

is broken.



Good point. Is there a TODO-list where such a general review request

can be filed, or should we just file it as a system-wide bug in
Bugzilla?


Nonetheless, I think this one-line fix should be accepted as a short

term solution.




Hi Morten,

I suspect there can be more places that testpmd assumes
max core number is 64, someone needs to spend time to
analyze and fix it.


My point exactly. Someone needs to spend time to analyze all DPDK libraries and 
applications, and fix it where appropriate. Where do we register this required 
effort, so it can be picked up by someone?



testpmd is an application and it has its own restrictions,
I *assumed* libraries are safe and restriction is only in
testpmd, but may be better to verify this as well.


Also, it should probably be mentioned as a known bug in the 22.03 release notes.

Re: [PATCH v1] eal/linux: fix memory illegal accesses

[Ferruh Yigit]

On 2/23/2022 8:49 AM, Steve Yang wrote:

'recv()' fills the 'buf', later 'strlcpy()' used to copy from this buffer.
But as coverity warns 'recv()' doesn't guarantee that 'buf' is
null-terminated, but 'strlcpy()' requires it.

Enlarge 'buf' size to 'EAL_UEV_MSG_LEN + 1' and ensure the last one can
be set to 0 when received buffer size is EAL_UEV_MSG_LEN.

CID 375864:  Memory - illegal accesses  (STRING_NULL)
Passing unterminated string "buf" to "dev_uev_parse", which expects
a null-terminated string.

Coverity issue: 375864
Fixes: 0d0f478d0483 ("eal/linux: add uevent parse and process")
Cc: sta...@dpdk.org

Signed-off-by: Steve Yang 


Acked-by: Ferruh Yigit 

[PATCH v3] gpu/cuda: CPU map GPU memory with GDRCopy

[eagostini]

From: Elena Agostini 

To enable the gpudev rte_gpu_mem_cpu_map feature to expose
GPU memory to the CPU, the GPU CUDA driver library needs
the GDRCopy library and driver.

If DPDK is built without GDRCopy, the GPU CUDA driver returns
error if the is invoked rte_gpu_mem_cpu_map.

All the others GPU CUDA driver functionalities are not affected by
the absence of GDRCopy, thus this is an optional functionality
that can be enabled in the GPU CUDA driver.

CUDA driver documentation has been updated accordingly.

Signed-off-by: Elena Agostini 



Changelog:
- Fix checkpatch and doc build issue
---
 doc/guides/gpus/cuda.rst |  52 +
 doc/guides/gpus/features/default.ini |   2 +
 drivers/gpu/cuda/cuda.c  |  78 +-
 drivers/gpu/cuda/gdrcopy.c   | 155 +++
 drivers/gpu/cuda/gdrcopy.h   |  29 +
 drivers/gpu/cuda/meson.build |   6 +-
 6 files changed, 319 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/cuda/gdrcopy.c
 create mode 100644 drivers/gpu/cuda/gdrcopy.h

diff --git a/doc/guides/gpus/cuda.rst b/doc/guides/gpus/cuda.rst
index 38e22dc2c0..5d4fe02d77 100644
--- a/doc/guides/gpus/cuda.rst
+++ b/doc/guides/gpus/cuda.rst
@@ -29,6 +29,34 @@ Three ways:
 
 If headers are not found, the CUDA GPU driver library is not built.
 
+CPU map GPU memory
+~~
+
+To enable this gpudev feature (i.e. implement the ``rte_gpu_mem_cpu_map``),
+you need the `GDRCopy `_ library and driver
+installed on your system.
+
+A quick recipe to download, build and run GDRCopy library and driver:
+
+.. code-block:: console
+
+  $ git clone https://github.com/NVIDIA/gdrcopy.git
+  $ make
+  $ # make install to install GDRCopy library system wide
+  $ # Launch gdrdrv kernel module on the system
+  $ sudo ./insmod.sh
+
+You need to indicate to meson where GDRCopy headers files as in case of CUDA 
headers.
+An example would be:
+
+.. code-block:: console
+
+  $ meson build -Dc_args="-I/usr/local/cuda/include -I/path/to/gdrcopy/include"
+
+If headers are not found, the CUDA GPU driver library is built without the CPU 
map capability
+and will return error if the application invokes the gpude 
``rte_gpu_mem_cpu_map`` function.
+
+
 CUDA Shared Library
 ---
 
@@ -46,6 +74,30 @@ All CUDA API symbols are loaded at runtime as well.
 For this reason, to build the CUDA driver library,
 no need to install the CUDA library.
 
+CPU map GPU memory
+~~
+
+Similarly to CUDA shared library, if the **libgdrapi.so** shared library is not
+installed in default locations (e.g. /usr/local/lib) you can use the
+``GDRCOPY_PATH_L``.
+
+As an example, to enable the CPU map feature sanity check, run the 
``app/test-gpudev``
+application with:
+
+.. code-block:: console
+
+  $ sudo CUDA_PATH_L=/path/to/libcuda GDRCOPY_PATH_L=/path/to/libgdrapi 
./build/app/dpdk-test-gpudev
+
+Additionally, the ``gdrdrv`` kernel module built with the GDRCopy project has 
to loaded
+on the system:
+
+.. code-block:: console
+
+  $ lsmod | egrep gdrdrv
+  gdrdrv 20480  0
+  nvidia  35307520  19 nvidia_uvm,nv_peer_mem,gdrdrv,nvidia_modeset
+
+
 Design
 --
 
diff --git a/doc/guides/gpus/features/default.ini 
b/doc/guides/gpus/features/default.ini
index 87e9966424..817113f2c2 100644
--- a/doc/guides/gpus/features/default.ini
+++ b/doc/guides/gpus/features/default.ini
@@ -11,3 +11,5 @@ Get device info=
 Share CPU memory with device   =
 Allocate device memory =
 Free memory=
+CPU map device memory  =
+CPU unmap device memory=
diff --git a/drivers/gpu/cuda/cuda.c b/drivers/gpu/cuda/cuda.c
index b43d5a32b7..ca400d473c 100644
--- a/drivers/gpu/cuda/cuda.c
+++ b/drivers/gpu/cuda/cuda.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "gdrcopy.h"
 
 #define CUDA_DRIVER_MIN_VERSION 11040
 #define CUDA_API_MIN_VERSION 3020
@@ -51,6 +52,7 @@ static PFN_cuFlushGPUDirectRDMAWrites 
pfn_cuFlushGPUDirectRDMAWrites;
 static void *cudalib;
 static unsigned int cuda_api_version;
 static int cuda_driver_version;
+static gdr_t gdrc_h;
 
 /* NVIDIA GPU vendor */
 #define NVIDIA_GPU_VENDOR_ID (0x10de)
@@ -157,6 +159,7 @@ struct mem_entry {
CUcontext ctx;
cuda_ptr_key pkey;
enum mem_type mtype;
+   gdr_mh_t mh;
struct mem_entry *prev;
struct mem_entry *next;
 };
@@ -797,6 +800,47 @@ cuda_mem_register(struct rte_gpu *dev, size_t size, void 
*ptr)
return 0;
 }
 
+static int
+cuda_mem_cpu_map(struct rte_gpu *dev, __rte_unused size_t size, void *ptr_in, 
void **ptr_out)
+{
+   struct mem_entry *mem_item;
+   cuda_ptr_key hk;
+
+   if (dev == NULL)
+   return -ENODEV;
+
+   hk = get_hash_from_ptr((void *)ptr_in);
+
+   mem_item = mem_list_find_item(hk);
+   if (mem_item == NULL) {
+   rte_cuda_log(ERR, "Memory address 0x%p not found 

Re: [PATCH v11 1/2] common/cnxk: support priority flow ctrl config API

[Jerin Jacob]

On Tue, Feb 22, 2022 at 4:08 PM  wrote:
>
> From: Sunil Kumar Kori 
>
> CNXK platforms support priority flow control(802.1qbb) to pause
> respective traffic per class on that link.
>
> Adds RoC interface to configure priority flow control on MAC
> block i.e. CGX on cn9k and RPM on cn10k.
>
> Signed-off-by: Sunil Kumar Kori 
> ---
> v1..v2:
>  - fix RoC API naming convention.
>
> v2..v3:
>  - fix pause quanta configuration for cn10k.
>  - remove unnecessary code
>
> v3..v4:
>  - fix PFC configuration with other type of TM tree
>i.e. default, user and rate limit tree.
>
> v4..v5:
>  - rebase on top of tree
>  - fix review comments
>  - fix initialization error for LBK devices
>
> v5..v6:
>  - fix review comments
>
> v6..v7:
>  - no change
>
> v7..v8:
>  - rebase on top of 22.03-rc1
>
> v8..v10:
>  - no change
>
> v10..v11:
>  - Rebase to dpdk-next-net-mrvl branch

Series Acked-by: Jerin Jacob 
Series applied to dpdk-next-net-mrvl/for-next-net. Thanks.



>
>  drivers/common/cnxk/roc_mbox.h   |  19 ++-
>  drivers/common/cnxk/roc_nix.h|  21 
>  drivers/common/cnxk/roc_nix_fc.c |  95 +--
>  drivers/common/cnxk/roc_nix_priv.h   |   6 +-
>  drivers/common/cnxk/roc_nix_tm.c | 171 ++-
>  drivers/common/cnxk/roc_nix_tm_ops.c |  14 ++-
>  drivers/common/cnxk/version.map  |   4 +
>  7 files changed, 310 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/common/cnxk/roc_mbox.h b/drivers/common/cnxk/roc_mbox.h
> index 8967858914..b608f58357 100644
> --- a/drivers/common/cnxk/roc_mbox.h
> +++ b/drivers/common/cnxk/roc_mbox.h
> @@ -95,6 +95,8 @@ struct mbox_msghdr {
>   msg_rsp)
>  \
> M(CGX_STATS_RST, 0x21A, cgx_stats_rst, msg_req, msg_rsp)  
>  \
> M(RPM_STATS, 0x21C, rpm_stats, msg_req, rpm_stats_rsp)
>  \
> +   M(CGX_PRIO_FLOW_CTRL_CFG, 0x21F, cgx_prio_flow_ctrl_cfg, cgx_pfc_cfg, 
>  \
> + cgx_pfc_rsp)
>  \
> /* NPA mbox IDs (range 0x400 - 0x5FF) */  
>  \
> M(NPA_LF_ALLOC, 0x400, npa_lf_alloc, npa_lf_alloc_req,
>  \
>   npa_lf_alloc_rsp)   
>  \
> @@ -551,6 +553,19 @@ struct cgx_pause_frm_cfg {
> uint8_t __io tx_pause;
>  };
>
> +struct cgx_pfc_cfg {
> +   struct mbox_msghdr hdr;
> +   uint8_t __io rx_pause;
> +   uint8_t __io tx_pause;
> +   uint16_t __io pfc_en; /*  bitmap indicating enabled traffic classes */
> +};
> +
> +struct cgx_pfc_rsp {
> +   struct mbox_msghdr hdr;
> +   uint8_t __io rx_pause;
> +   uint8_t __io tx_pause;
> +};
> +
>  struct sfp_eeprom_s {
>  #define SFP_EEPROM_SIZE 256
> uint16_t __io sff_id;
> @@ -1125,7 +1140,9 @@ struct nix_bp_cfg_req {
>  /* PF can be mapped to either CGX or LBK interface,
>   * so maximum 64 channels are possible.
>   */
> -#define NIX_MAX_CHAN 64
> +#define NIX_MAX_CHAN64
> +#define NIX_CGX_MAX_CHAN 16
> +#define NIX_LBK_MAX_CHAN 1
>  struct nix_bp_cfg_rsp {
> struct mbox_msghdr hdr;
> /* Channel and bpid mapping */
> diff --git a/drivers/common/cnxk/roc_nix.h b/drivers/common/cnxk/roc_nix.h
> index 755212c8f9..680a34cdcd 100644
> --- a/drivers/common/cnxk/roc_nix.h
> +++ b/drivers/common/cnxk/roc_nix.h
> @@ -165,16 +165,27 @@ struct roc_nix_fc_cfg {
>
> struct {
> uint32_t rq;
> +   uint16_t tc;
> uint16_t cq_drop;
> bool enable;
> } cq_cfg;
>
> struct {
> +   uint32_t sq;
> +   uint16_t tc;
> bool enable;
> } tm_cfg;
> };
>  };
>
> +struct roc_nix_pfc_cfg {
> +   enum roc_nix_fc_mode mode;
> +   /* For SET, tc must be [0, 15].
> +* For GET, TC will represent bitmap
> +*/
> +   uint16_t tc;
> +};
> +
>  struct roc_nix_eeprom_info {
>  #define ROC_NIX_EEPROM_SIZE 256
> uint16_t sff_id;
> @@ -478,6 +489,7 @@ void __roc_api roc_nix_unregister_cq_irqs(struct roc_nix 
> *roc_nix);
>  enum roc_nix_tm_tree {
> ROC_NIX_TM_DEFAULT = 0,
> ROC_NIX_TM_RLIMIT,
> +   ROC_NIX_TM_PFC,
> ROC_NIX_TM_USER,
> ROC_NIX_TM_TREE_MAX,
>  };
> @@ -624,6 +636,7 @@ roc_nix_tm_shaper_default_red_algo(struct roc_nix_tm_node 
> *node,
>  int __roc_api roc_nix_tm_lvl_cnt_get(struct roc_nix *roc_nix);
>  int __roc_api roc_nix_tm_lvl_have_link_access(struct roc_nix *roc_nix, int 
> lvl);
>  int __roc_api roc_nix_tm_prepare_rate_limited_tree(struct roc_nix *roc_nix);
> +int __roc_api roc_nix_tm_pfc_prepare_tree(struct roc_nix *roc_nix);
>  bool __roc_api roc_nix_tm_is_user_hierarchy_enabled(struct roc_nix *nix);
>  int __roc_api roc_nix_tm_tree_type_get(struct roc_nix *nix);
>
> @@

Re: [PATCH] net/cnxk: fix compilation issue for gcc12

[Jerin Jacob]

On Wed, Feb 23, 2022 at 3:20 PM Rakesh Kudurumalla
 wrote:
>
> resolve compilation error caused due to gcc 12 version
> error: storing the address of local variable message in *error.message
>
> Fixes: 26b034f78ca7 ("net/cnxk: support to validate meter policy")
>
> Cc: sta...@dpdk.org
>

Reported-By: Ferruh Yigit 

> Signed-off-by: Rakesh Kudurumalla 
> ---
>  drivers/net/cnxk/cnxk_ethdev_mtr.c | 59 ++
>  1 file changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/cnxk/cnxk_ethdev_mtr.c 
> b/drivers/net/cnxk/cnxk_ethdev_mtr.c
> index cc783e5f86..c8183aa12d 100644
> --- a/drivers/net/cnxk/cnxk_ethdev_mtr.c
> +++ b/drivers/net/cnxk/cnxk_ethdev_mtr.c
> @@ -285,15 +285,54 @@ cnxk_nix_mtr_profile_delete(struct rte_eth_dev 
> *eth_dev, uint32_t profile_id,
> return 0;
>  }
>
> +static int
> +update_mtr_err(uint32_t act_color, struct rte_mtr_error *error, bool action)
> +{
> +   const char *str;
> +   switch (act_color) {
> +   case RTE_COLOR_GREEN:
> +   if (action) {
> +   str = "Green action is not valid";
> +   goto notsup;
> +   } else {
> +   str = "Green action is null";
> +   goto notvalid;
> +   }
> +   break;
> +   case RTE_COLOR_YELLOW:
> +   if (action) {
> +   str = "Yellow action is not valid";
> +   goto notsup;
> +   } else {
> +   str = "Yellow action is null";
> +   goto notvalid;
> +   }
> +   break;
> +   case RTE_COLOR_RED:
> +   if (action) {
> +   str = "Red action is not valid";
> +   goto notsup;
> +   } else {
> +   str = "Red action is null";
> +   goto notvalid;
> +   }
> +   break;
> +   }
> +notsup:
> +   return -rte_mtr_error_set(error, ENOTSUP,
> + RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
> +notvalid:
> +   return -rte_mtr_error_set(error, EINVAL,
> + RTE_MTR_ERROR_TYPE_METER_POLICY, NULL, str);
> +}
> +
>  static int
>  cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
>  struct rte_mtr_meter_policy_params *policy,
>  struct rte_mtr_error *error)
>  {
> -   static const char *const action_color[] = {"Green", "Yellow", "Red"};
> bool supported[RTE_COLORS] = {false, false, false};
> const struct rte_flow_action *action;
> -   char message[1024];
> uint32_t i;
>
> RTE_SET_USED(dev);
> @@ -315,21 +354,11 @@ cnxk_nix_mtr_policy_validate(struct rte_eth_dev *dev,
> if (action->type == RTE_FLOW_ACTION_TYPE_VOID)
> supported[i] = true;
>
> -   if (!supported[i]) {
> -   sprintf(message,
> -   "%s action is not valid",
> -   action_color[i]);
> -   return -rte_mtr_error_set(error,
> - ENOTSUP,
> - RTE_MTR_ERROR_TYPE_METER_POLICY, 
> NULL,
> - message);
> -   }
> +   if (!supported[i])
> +   return update_mtr_err(i, error, true);
> }
> } else {
> -   sprintf(message, "%s action is null", 
> action_color[i]);
> -   return -rte_mtr_error_set(error, EINVAL,
> -   RTE_MTR_ERROR_TYPE_METER_POLICY, NULL,
> -   message);
> +   return update_mtr_err(i, error, false);
> }
> }
>
> --
> 2.25.1
>

[PATCH 0/2] app/testpmd: fix testpmd quit with pf and vfs

[wenxuanx . wu]

From: wenxuan wu 

Apply our reverse iterator macro into testpmd to 
avoid testpmd startups with pf and vfs quit without 
error heap-free-before-use 
wenxuan wu (2):
  lib/ethdev: add reverse macro to quit testpmd
  app/testpmd:fix testpmd quit failure

 app/test-pmd/testpmd.c  |  4 ++--
 lib/ethdev/rte_ethdev.h | 11 ++-
 2 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH v2 1/2] lib/ethdev: add reverse macro to quit testpmd

[wenxuanx . wu]

From: wenxuan wu 

There is a heap-free-after-use bug when quit testpmd
with pf and vfs, stop and close ports in reverse order
is a more reasonable approach.

Cc: sta...@dpdk.org

Signed-off-by: wenxuan wu 
---
 lib/ethdev/rte_ethdev.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 2660e4f374..813f72e825 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -2185,7 +2185,8 @@ struct rte_eth_dev_owner {
  * @return
  *   Next valid port ID owned by owner_id, RTE_MAX_ETHPORTS if there is none.
  */
-uint64_t rte_eth_find_next_owned_by(uint16_t port_id,
+uint64_t
+rte_eth_find_next_owned_by(uint16_t port_id,
const uint64_t owner_id);
 
 /**
@@ -2212,6 +2213,14 @@ uint16_t rte_eth_find_next(uint16_t port_id);
 #define RTE_ETH_FOREACH_DEV(p) \
RTE_ETH_FOREACH_DEV_OWNED_BY(p, RTE_ETH_DEV_NO_OWNER)
 
+/**
+ * Macro to iterate over all enabled and ownerless ethdev ports in reverse 
order.
+ */
+#define RTE_ETH_FOREACH_DEV_REVERSE(p) \
+   for (p = rte_eth_dev_count_total() - 1; \
+p < rte_eth_dev_count_total(); \
+p--)
+
 /**
  * Iterates over ethdev ports of a specified device.
  *
-- 
2.25.1

[PATCH v2 2/2] app/testpmd:fix testpmd quit failure

[wenxuanx . wu]

From: wenxuan wu 

When testpmd start ed with 1 pf and 2 vfs, testpmd quited while vfs 
were still alive would result in failure. Root cause is that pf had
been released already but vfs were still accessing by func 
rte_eth_dev_info_get, which would result in heap-free-after-use error.

By quitting our ports in reverse order to avoid this.And the order is
guaranteed that vf are created after pfs.

Fixes: d3a274ce9dee ("app/testpmd: handle SIGINT and SIGTERM")
Cc: sta...@dpdk.org

Signed-off-by: wenxuan wu 
---
 app/test-pmd/testpmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index e1da961311..698b6d8cc4 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3384,12 +3384,12 @@ pmd_test_exit(void)
 #endif
if (ports != NULL) {
no_link_check = 1;
-   RTE_ETH_FOREACH_DEV(pt_id) {
+   RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
printf("\nStopping port %d...\n", pt_id);
fflush(stdout);
stop_port(pt_id);
}
-   RTE_ETH_FOREACH_DEV(pt_id) {
+   RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
printf("\nShutting down port %d...\n", pt_id);
fflush(stdout);
close_port(pt_id);
-- 
2.25.1

Re: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure

[Ferruh Yigit]

On 2/23/2022 11:32 AM, wenxuanx...@intel.com wrote:

From: wenxuan wu 

When testpmd start ed with 1 pf and 2 vfs, testpmd quited while vfs
were still alive would result in failure. Root cause is that pf had
been released already but vfs were still accessing by func
rte_eth_dev_info_get, which would result in heap-free-after-use error.

By quitting our ports in reverse order to avoid this.And the order is
guaranteed that vf are created after pfs.

Fixes: d3a274ce9dee ("app/testpmd: handle SIGINT and SIGTERM")
Cc: sta...@dpdk.org

Signed-off-by: wenxuan wu 
---
  app/test-pmd/testpmd.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index e1da961311..698b6d8cc4 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3384,12 +3384,12 @@ pmd_test_exit(void)
  #endif
if (ports != NULL) {
no_link_check = 1;
-   RTE_ETH_FOREACH_DEV(pt_id) {
+   RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {


The main problem with this patch was this logic,
can you please check comment on previous version?


printf("\nStopping port %d...\n", pt_id);
fflush(stdout);
stop_port(pt_id);
}
-   RTE_ETH_FOREACH_DEV(pt_id) {
+   RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
printf("\nShutting down port %d...\n", pt_id);
fflush(stdout);
close_port(pt_id);

Re: [dpdk-dev] [PATCH v2] net/cnxk: unify file names

[Ferruh Yigit]

On 2/23/2022 9:08 AM, Jerin Jacob wrote:

On Wed, Feb 23, 2022 at 12:01 AM  wrote:


From: Jerin Jacob 

Except for the cn*_rte_flow* files, none of the other
file has rte in the file name, remove the
rte to unify the file name across the directory.

Signed-off-by: Jerin Jacob 
Acked-by: Kiran Kumar K 


Applied to dpdk-next-net-mrvl/for-next-net. Thanks




v2 updated in next-net, can you please rebase on latest next-net?

[PATCH v3 00/21] net/ena: v2.6.0 driver update

[Michal Krawczyk]

Hi,

this set contains new ENA features:

* New xstats.
* Reconfigurable link status event.
* Usage of the optimized memcpy on arm/arm64.
* Better MP support.
* Reconfigurable Tx completion timeout value using devarg.

Beside that, this patchset contains multiple fixes, minor improvements, new
DPDK API support and extra error checks.

v3:
* Fix build errors of the AQ proxy patch:
  - for the FreeBSD, by changing ECOMM error to EIO,
  - with assertions enabled, by fixing variable name.

v2:
* Fix reviewer's email (s/igo...@semihalf.com/igo...@amazon.com/).
* Fix commit messages typos found by the checkpatch.

Dawid Gorecki (4):
  net/ena: expose Tx cleanup function
  net/ena: check if reset was already triggered
  net/ena: extend debug prints for invalid req ID resets
  net/ena: don't initialize LLQ when membar isn't exposed

Michal Krawczyk (15):
  net/ena: remove linearization function
  net/ena: add assertion on Tx info mbuf
  net/ena: remove unused enumeration
  net/ena: remove unused offloads variables
  net/ena: add extra Rx checksum related xstats
  net/ena: make LSC configurable
  net/ena: skip timer if the reset is triggered
  net/ena: perform Tx cleanup before sending pkts
  net/ena/base: use optimized memcpy version also on Arm
  net/ena/base: make IO memzone unique per port
  net/ena: add API for probing xstat names by ID
  net/ena: make Tx completion timeout configurable
  net/ena: fix meta-desc DF flag setup
  net/ena: don't indicate bad csum for L4 csum error
  net/ena: update version to 2.6.0

Stanislaw Kardach (2):
  net/ena: proxy AQ calls to primary process
  net/ena: enable stats get function for MP mode

 doc/guides/nics/ena.rst|   9 +
 doc/guides/nics/features/ena.ini   |   2 +
 doc/guides/rel_notes/release_22_03.rst |  14 +
 drivers/net/ena/base/ena_plat_dpdk.h   |  69 +-
 drivers/net/ena/ena_ethdev.c   | 916 -
 drivers/net/ena/ena_ethdev.h   |  28 +-
 drivers/net/ena/ena_rss.c  |  10 +-
 7 files changed, 800 insertions(+), 248 deletions(-)

--
2.25.1

[PATCH v3 01/21] net/ena: remove linearization function

[Michal Krawczyk]

The linearization of the mbuf isn't common practice for the PMD, as it
can expose it's capabilities to the upper layer using
rte_eth_dev_info_get().

Moreover, the rte_eth_tx_prepare() function should also verify if the
number of segments inside the mbuf isn't too high.

Because of those 2 circumstances, it may be safer to avoid modifying
mbuf on PMD's Tx side and remove linearization at all. Instead, add
verification of the number of segments to the eth_ena_prep_pkts().

Signed-off-by: Michal Krawczyk 
Reviewed-by: Artur Rojek 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Igor Chauskin 
Reviewed-by: Shai Brandes 

---
 drivers/net/ena/ena_ethdev.c | 74 +---
 drivers/net/ena/ena_ethdev.h |  2 -
 2 files changed, 19 insertions(+), 57 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index db2b5ec8e7..deaee30664 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -93,8 +93,6 @@ static const struct ena_stats ena_stats_tx_strings[] = {
ENA_STAT_TX_ENTRY(cnt),
ENA_STAT_TX_ENTRY(bytes),
ENA_STAT_TX_ENTRY(prepare_ctx_err),
-   ENA_STAT_TX_ENTRY(linearize),
-   ENA_STAT_TX_ENTRY(linearize_failed),
ENA_STAT_TX_ENTRY(tx_poll),
ENA_STAT_TX_ENTRY(doorbells),
ENA_STAT_TX_ENTRY(bad_req_id),
@@ -2408,6 +2406,17 @@ eth_ena_prep_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,
return i;
}
 
+   if (unlikely(m->nb_segs >= tx_ring->sgl_size &&
+   !(tx_ring->tx_mem_queue_type == 
ENA_ADMIN_PLACEMENT_POLICY_DEV &&
+ m->nb_segs == tx_ring->sgl_size &&
+ m->data_len < tx_ring->tx_max_header_size))) {
+   PMD_TX_LOG(DEBUG,
+   "mbuf[%" PRIu32 "] has too many segments: %" 
PRIu16 "\n",
+   i, m->nb_segs);
+   rte_errno = EINVAL;
+   return i;
+   }
+
 #ifdef RTE_LIBRTE_ETHDEV_DEBUG
/* Check if requested offload is also enabled for the queue */
if ((ol_flags & RTE_MBUF_F_TX_IP_CKSUM &&
@@ -2554,56 +2563,6 @@ static void ena_update_hints(struct ena_adapter *adapter,
}
 }
 
-static int ena_check_space_and_linearize_mbuf(struct ena_ring *tx_ring,
- struct rte_mbuf *mbuf)
-{
-   struct ena_com_dev *ena_dev;
-   int num_segments, header_len, rc;
-
-   ena_dev = &tx_ring->adapter->ena_dev;
-   num_segments = mbuf->nb_segs;
-   header_len = mbuf->data_len;
-
-   if (likely(num_segments < tx_ring->sgl_size))
-   goto checkspace;
-
-   if (ena_dev->tx_mem_queue_type == ENA_ADMIN_PLACEMENT_POLICY_DEV &&
-   (num_segments == tx_ring->sgl_size) &&
-   (header_len < tx_ring->tx_max_header_size))
-   goto checkspace;
-
-   /* Checking for space for 2 additional metadata descriptors due to
-* possible header split and metadata descriptor. Linearization will
-* be needed so we reduce the segments number from num_segments to 1
-*/
-   if (!ena_com_sq_have_enough_space(tx_ring->ena_com_io_sq, 3)) {
-   PMD_TX_LOG(DEBUG, "Not enough space in the Tx queue\n");
-   return ENA_COM_NO_MEM;
-   }
-   ++tx_ring->tx_stats.linearize;
-   rc = rte_pktmbuf_linearize(mbuf);
-   if (unlikely(rc)) {
-   PMD_TX_LOG(WARNING, "Mbuf linearize failed\n");
-   rte_atomic64_inc(&tx_ring->adapter->drv_stats->ierrors);
-   ++tx_ring->tx_stats.linearize_failed;
-   return rc;
-   }
-
-   return 0;
-
-checkspace:
-   /* Checking for space for 2 additional metadata descriptors due to
-* possible header split and metadata descriptor
-*/
-   if (!ena_com_sq_have_enough_space(tx_ring->ena_com_io_sq,
- num_segments + 2)) {
-   PMD_TX_LOG(DEBUG, "Not enough space in the Tx queue\n");
-   return ENA_COM_NO_MEM;
-   }
-
-   return 0;
-}
-
 static void ena_tx_map_mbuf(struct ena_ring *tx_ring,
struct ena_tx_buffer *tx_info,
struct rte_mbuf *mbuf,
@@ -2688,9 +2647,14 @@ static int ena_xmit_mbuf(struct ena_ring *tx_ring, 
struct rte_mbuf *mbuf)
int nb_hw_desc;
int rc;
 
-   rc = ena_check_space_and_linearize_mbuf(tx_ring, mbuf);
-   if (unlikely(rc))
-   return rc;
+   /* Checking for space for 2 additional metadata descriptors due to
+* possible header split and metadata descriptor
+*/
+   if (!ena_com_sq_have_enough_space(tx_ring->ena_com_io_sq,
+ mbuf->nb_segs + 2)) {
+   PMD_DRV_LOG(DEBUG, "Not enough space in the tx queue\n");
+   return ENA_COM_NO_MEM;
+   }
 
next_to_use = tx_ring-

[PATCH v3 02/21] net/ena: add assertion on Tx info mbuf

[Michal Krawczyk]

To make sure there is no outstanding mbuf in the reused Tx queue (due to
unproper cleanup, or some invalid logic on Tx path), the assertion was
added on the Tx path.

As it's being compiled out in the release version, it won't affect
the IO path performance.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index deaee30664..34fb43cb00 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -2661,6 +2661,7 @@ static int ena_xmit_mbuf(struct ena_ring *tx_ring, struct 
rte_mbuf *mbuf)
req_id = tx_ring->empty_tx_reqs[next_to_use];
tx_info = &tx_ring->tx_buffer_info[req_id];
tx_info->num_of_bufs = 0;
+   RTE_ASSERT(tx_info->mbuf == NULL);
 
ena_tx_map_mbuf(tx_ring, tx_info, mbuf, &push_header, &header_len);
 
-- 
2.25.1

[PATCH v3 03/21] net/ena: remove unused enumeration

[Michal Krawczyk]

The enumeration seems to be leftover from porting the Linux driver to
the DPDK. It was used nowhere and refers to the ethtool which is not
present in the DPDK.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Artur Rojek 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Igor Chauskin 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 34fb43cb00..2de2dcf12f 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -38,11 +38,6 @@
 
 #define ENA_PTYPE_HAS_HASH (RTE_PTYPE_L4_TCP | RTE_PTYPE_L4_UDP)
 
-enum ethtool_stringset {
-   ETH_SS_TEST = 0,
-   ETH_SS_STATS,
-};
-
 struct ena_stats {
char name[ETH_GSTRING_LEN];
int stat_offset;
-- 
2.25.1

[PATCH v3 04/21] net/ena: remove unused offloads variables

[Michal Krawczyk]

Those variables are being set, but never read. As they seem to be
leftover from the old offloads API and don't have any purpose right
now, they are simply being removed.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Artur Rojek 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Igor Chauskin 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 3 ---
 drivers/net/ena/ena_ethdev.h | 5 -
 2 files changed, 8 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 2de2dcf12f..de5fdb8f1d 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -2015,9 +2015,6 @@ static int ena_dev_configure(struct rte_eth_dev *dev)
 */
adapter->tx_cleanup_stall_delay = adapter->missing_tx_completion_to / 2;
 
-   adapter->tx_selected_offloads = dev->data->dev_conf.txmode.offloads;
-   adapter->rx_selected_offloads = dev->data->dev_conf.rxmode.offloads;
-
return 0;
 }
 
diff --git a/drivers/net/ena/ena_ethdev.h b/drivers/net/ena/ena_ethdev.h
index f47ba3fb02..4dfa604d51 100644
--- a/drivers/net/ena/ena_ethdev.h
+++ b/drivers/net/ena/ena_ethdev.h
@@ -278,11 +278,6 @@ struct ena_adapter {
struct ena_driver_stats *drv_stats;
enum ena_adapter_state state;
 
-   uint64_t tx_supported_offloads;
-   uint64_t tx_selected_offloads;
-   uint64_t rx_supported_offloads;
-   uint64_t rx_selected_offloads;
-
bool link_status;
 
enum ena_regs_reset_reason_types reset_reason;
-- 
2.25.1

[PATCH v3 05/21] net/ena: add extra Rx checksum related xstats

[Michal Krawczyk]

* Split 'bad_csum' Rx statistic into 'l3_csum_bad' and 'l4_csum_bad' to
  be able to check which checksum was not calculated properly.
* Add l4_csum_good statistic, which shows how many times L4 Rx checksum
  was properly offloaded.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/rel_notes/release_22_03.rst |  8 +++
 drivers/net/ena/ena_ethdev.c   | 32 --
 drivers/net/ena/ena_ethdev.h   |  4 +++-
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 74965ebd56..f6b881b8b4 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -104,6 +104,14 @@ New Features
   * Added support for libxdp >=v1.2.2.
   * Re-enabled secondary process support. RX/TX is not supported.
 
+* **Updated Amazon ENA PMD.**
+
+  Updated the Amazon ENA PMD. The new driver version (v2.6.0) introduced
+  bug fixes and improvements, including:
+
+  * Added new checksum related xstats: ``l3_csum_bad``, ``l4_csum_bad`` and
+``l4_csum_good``.
+
 * **Updated Cisco enic driver.**
 
   * Added rte_flow support for matching GENEVE packets.
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index de5fdb8f1d..d534b93749 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -99,7 +99,9 @@ static const struct ena_stats ena_stats_rx_strings[] = {
ENA_STAT_RX_ENTRY(cnt),
ENA_STAT_RX_ENTRY(bytes),
ENA_STAT_RX_ENTRY(refill_partial),
-   ENA_STAT_RX_ENTRY(bad_csum),
+   ENA_STAT_RX_ENTRY(l3_csum_bad),
+   ENA_STAT_RX_ENTRY(l4_csum_bad),
+   ENA_STAT_RX_ENTRY(l4_csum_good),
ENA_STAT_RX_ENTRY(mbuf_alloc_fail),
ENA_STAT_RX_ENTRY(bad_desc_num),
ENA_STAT_RX_ENTRY(bad_req_id),
@@ -273,10 +275,12 @@ static const struct eth_dev_ops ena_dev_ops = {
.rss_hash_conf_get= ena_rss_hash_conf_get,
 };
 
-static inline void ena_rx_mbuf_prepare(struct rte_mbuf *mbuf,
+static inline void ena_rx_mbuf_prepare(struct ena_ring *rx_ring,
+  struct rte_mbuf *mbuf,
   struct ena_com_rx_ctx *ena_rx_ctx,
   bool fill_hash)
 {
+   struct ena_stats_rx *rx_stats = &rx_ring->rx_stats;
uint64_t ol_flags = 0;
uint32_t packet_type = 0;
 
@@ -287,21 +291,27 @@ static inline void ena_rx_mbuf_prepare(struct rte_mbuf 
*mbuf,
 
if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV4) {
packet_type |= RTE_PTYPE_L3_IPV4;
-   if (unlikely(ena_rx_ctx->l3_csum_err))
+   if (unlikely(ena_rx_ctx->l3_csum_err)) {
+   ++rx_stats->l3_csum_bad;
ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
-   else
+   } else {
ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+   }
} else if (ena_rx_ctx->l3_proto == ENA_ETH_IO_L3_PROTO_IPV6) {
packet_type |= RTE_PTYPE_L3_IPV6;
}
 
-   if (!ena_rx_ctx->l4_csum_checked || ena_rx_ctx->frag)
+   if (!ena_rx_ctx->l4_csum_checked || ena_rx_ctx->frag) {
ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN;
-   else
-   if (unlikely(ena_rx_ctx->l4_csum_err))
+   } else {
+   if (unlikely(ena_rx_ctx->l4_csum_err)) {
+   ++rx_stats->l4_csum_bad;
ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
-   else
+   } else {
+   ++rx_stats->l4_csum_good;
ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
+   }
+   }
 
if (fill_hash &&
likely((packet_type & ENA_PTYPE_HAS_HASH) && !ena_rx_ctx->frag)) {
@@ -2336,13 +2346,11 @@ static uint16_t eth_ena_recv_pkts(void *rx_queue, 
struct rte_mbuf **rx_pkts,
}
 
/* fill mbuf attributes if any */
-   ena_rx_mbuf_prepare(mbuf, &ena_rx_ctx, fill_hash);
+   ena_rx_mbuf_prepare(rx_ring, mbuf, &ena_rx_ctx, fill_hash);
 
if (unlikely(mbuf->ol_flags &
-   (RTE_MBUF_F_RX_IP_CKSUM_BAD | 
RTE_MBUF_F_RX_L4_CKSUM_BAD))) {
+   (RTE_MBUF_F_RX_IP_CKSUM_BAD | 
RTE_MBUF_F_RX_L4_CKSUM_BAD)))
rte_atomic64_inc(&rx_ring->adapter->drv_stats->ierrors);
-   ++rx_ring->rx_stats.bad_csum;
-   }
 
rx_pkts[completed] = mbuf;
rx_ring->rx_stats.bytes += mbuf->pkt_len;
diff --git a/drivers/net/ena/ena_ethdev.h b/drivers/net/ena/ena_ethdev.h
index 4dfa604d51..42c47c9455 100644
--- a/drivers/net/ena/ena_ethdev.h
+++ b/drivers/net/ena/ena_ethdev.h
@@ -114,7 +114,9 @@ struct ena_stats_rx {
u64 cnt;
u64 bytes;
u64 refill_part

[PATCH v3 06/21] net/ena: make LSC configurable

[Michal Krawczyk]

ENA uses AENQ for notification about various events, like LSC, keep
alive etc. By default it was enabling all AENQ that were supported by
both the driver and the device. As a result the LSC was always processed
even if the application turned it off explicitly.

As the DPDK provides application with the possibility to configure the
LSC, ENA should respect that. AENQ groups are now being updated upon
configure step, thus LSC can be activated or disabled between ENA PMD
reconfigurations. Moreover, the LSC capability for the device is being
determined dynamically.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/rel_notes/release_22_03.rst |  1 +
 drivers/net/ena/ena_ethdev.c   | 66 +++---
 drivers/net/ena/ena_ethdev.h   |  5 +-
 3 files changed, 53 insertions(+), 19 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index f6b881b8b4..c8e38d4c70 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -111,6 +111,7 @@ New Features
 
   * Added new checksum related xstats: ``l3_csum_bad``, ``l4_csum_bad`` and
 ``l4_csum_good``.
+  * Added support for the link status configuration.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index d534b93749..a2793f13cd 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -160,10 +160,9 @@ static const struct rte_pci_id pci_id_ena_map[] = {
 
 static struct ena_aenq_handlers aenq_handlers;
 
-static int ena_device_init(struct ena_com_dev *ena_dev,
+static int ena_device_init(struct ena_adapter *adapter,
   struct rte_pci_device *pdev,
-  struct ena_com_dev_get_features_ctx *get_feat_ctx,
-  bool *wd_state);
+  struct ena_com_dev_get_features_ctx *get_feat_ctx);
 static int ena_dev_configure(struct rte_eth_dev *dev);
 static void ena_tx_map_mbuf(struct ena_ring *tx_ring,
struct ena_tx_buffer *tx_info,
@@ -249,6 +248,7 @@ static int ena_rx_queue_intr_enable(struct rte_eth_dev *dev,
uint16_t queue_id);
 static int ena_rx_queue_intr_disable(struct rte_eth_dev *dev,
 uint16_t queue_id);
+static int ena_configure_aenq(struct ena_adapter *adapter);
 
 static const struct eth_dev_ops ena_dev_ops = {
.dev_configure= ena_dev_configure,
@@ -1416,11 +1416,11 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, 
unsigned int count)
return i;
 }
 
-static int ena_device_init(struct ena_com_dev *ena_dev,
+static int ena_device_init(struct ena_adapter *adapter,
   struct rte_pci_device *pdev,
-  struct ena_com_dev_get_features_ctx *get_feat_ctx,
-  bool *wd_state)
+  struct ena_com_dev_get_features_ctx *get_feat_ctx)
 {
+   struct ena_com_dev *ena_dev = &adapter->ena_dev;
uint32_t aenq_groups;
int rc;
bool readless_supported;
@@ -1485,13 +1485,8 @@ static int ena_device_init(struct ena_com_dev *ena_dev,
  BIT(ENA_ADMIN_WARNING);
 
aenq_groups &= get_feat_ctx->aenq.supported_groups;
-   rc = ena_com_set_aenq_config(ena_dev, aenq_groups);
-   if (rc) {
-   PMD_DRV_LOG(ERR, "Cannot configure AENQ groups, rc: %d\n", rc);
-   goto err_admin_init;
-   }
 
-   *wd_state = !!(aenq_groups & BIT(ENA_ADMIN_KEEP_ALIVE));
+   adapter->all_aenq_groups = aenq_groups;
 
return 0;
 
@@ -1517,7 +1512,7 @@ static void ena_interrupt_handler_rte(void *cb_arg)
 
 static void check_for_missing_keep_alive(struct ena_adapter *adapter)
 {
-   if (!adapter->wd_state)
+   if (!(adapter->active_aenq_groups & BIT(ENA_ADMIN_KEEP_ALIVE)))
return;
 
if (adapter->keep_alive_timeout == ENA_HW_HINTS_NO_TIMEOUT)
@@ -1798,7 +1793,6 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
int rc;
static int adapters_found;
bool disable_meta_caching;
-   bool wd_state = false;
 
eth_dev->dev_ops = &ena_dev_ops;
eth_dev->rx_pkt_burst = ð_ena_recv_pkts;
@@ -1850,12 +1844,15 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
}
 
/* device specific initialization routine */
-   rc = ena_device_init(ena_dev, pci_dev, &get_feat_ctx, &wd_state);
+   rc = ena_device_init(adapter, pci_dev, &get_feat_ctx);
if (rc) {
PMD_INIT_LOG(CRIT, "Failed to init ENA device\n");
goto err;
}
-   adapter->wd_state = wd_state;
+
+   /* Check if device supports LSC */
+   if (!(adapter->all_aenq_groups & BIT(ENA_ADMIN_LINK_CHANGE)))
+   adapter->edev_data->dev_flags &= ~RTE_ETH_DEV_INTR_LSC;
 
 

[PATCH v3 07/21] net/ena: skip timer if the reset is triggered

[Michal Krawczyk]

Some user applications may not support PMD reset handling. If they will
support timer service it could cause a situation, when information
about the reset trigger is being showed every time the timer service is
being called.

Timer service is now being skipped if the reset was already triggered.

Fixes: d9b8b106bf9d ("net/ena: add watchdog and keep alive AENQ handler")
Cc: sta...@dpdk.org

Signed-off-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index a2793f13cd..4b82372155 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1624,6 +1624,9 @@ static void ena_timer_wd_callback(__rte_unused struct 
rte_timer *timer,
struct rte_eth_dev *dev = arg;
struct ena_adapter *adapter = dev->data->dev_private;
 
+   if (unlikely(adapter->trigger_reset))
+   return;
+
check_for_missing_keep_alive(adapter);
check_for_admin_com_state(adapter);
check_for_tx_completions(adapter);
-- 
2.25.1

[PATCH v3 08/21] net/ena: perform Tx cleanup before sending pkts

[Michal Krawczyk]

To increase likehood that current burst will fit in the HW rings,
perform Tx cleanup before pushing packets to the HW. It may increase
latency a bit for sparse bursts, but the Tx flow now should be more
smooth.

It's also common order in the Tx burst function for other PMDs.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 4b82372155..ed3dd162ba 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -2776,6 +2776,10 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
}
 #endif
 
+   available_desc = ena_com_free_q_entries(tx_ring->ena_com_io_sq);
+   if (available_desc < tx_ring->tx_free_thresh)
+   ena_tx_cleanup(tx_ring);
+
for (sent_idx = 0; sent_idx < nb_pkts; sent_idx++) {
if (ena_xmit_mbuf(tx_ring, tx_pkts[sent_idx]))
break;
@@ -2784,9 +2788,6 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
tx_ring->size_mask)]);
}
 
-   available_desc = ena_com_free_q_entries(tx_ring->ena_com_io_sq);
-   tx_ring->tx_stats.available_desc = available_desc;
-
/* If there are ready packets to be xmitted... */
if (likely(tx_ring->pkts_without_db)) {
/* ...let HW do its best :-) */
@@ -2795,9 +2796,6 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
tx_ring->pkts_without_db = false;
}
 
-   if (available_desc < tx_ring->tx_free_thresh)
-   ena_tx_cleanup(tx_ring);
-
tx_ring->tx_stats.available_desc =
ena_com_free_q_entries(tx_ring->ena_com_io_sq);
tx_ring->tx_stats.tx_poll++;
-- 
2.25.1

[PATCH v3 09/21] net/ena/base: use optimized memcpy version also on Arm

[Michal Krawczyk]

As the default behavior for arm64 is to alias rte_memcpy as memcpy, ENA
cannot redefine memcpy as rte_memcpy as it would cause nested
declaration.

To make it possible to use optimized memcpy in the ena_com layer on Arm,
the driver now redefines memcpy when it is beneficial:
  * For arm64 only when the flag RTE_ARCH_ARM64_MEMCPY was defined
  * For arm only when the flag RTE_ARCH_ARM_NEON_MEMCPY was defined

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/rel_notes/release_22_03.rst | 1 +
 drivers/net/ena/base/ena_plat_dpdk.h   | 7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index c8e38d4c70..92490afd60 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -112,6 +112,7 @@ New Features
   * Added new checksum related xstats: ``l3_csum_bad``, ``l4_csum_bad`` and
 ``l4_csum_good``.
   * Added support for the link status configuration.
+  * Added optimized memcpy support for the ARM platforms.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h 
b/drivers/net/ena/base/ena_plat_dpdk.h
index 4e7f52881a..41db883c63 100644
--- a/drivers/net/ena/base/ena_plat_dpdk.h
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -66,8 +66,11 @@ typedef uint64_t dma_addr_t;
 #define ENA_UDELAY(x) rte_delay_us_block(x)
 
 #define ENA_TOUCH(x) ((void)(x))
-/* Avoid nested declaration on arm64, as it may define rte_memcpy as memcpy. */
-#if defined(RTE_ARCH_X86)
+/* Redefine memcpy with caution: rte_memcpy can be simply aliased to memcpy, so
+ * make the redefinition only if it's safe (and beneficial) to do so.
+ */
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64_MEMCPY) || \
+   defined(RTE_ARCH_ARM_NEON_MEMCPY)
 #undef memcpy
 #define memcpy rte_memcpy
 #endif
-- 
2.25.1

[PATCH v3 10/21] net/ena: proxy AQ calls to primary process

[Michal Krawczyk]

From: Stanislaw Kardach 

Due to how the ena_com compatibility layer is written, all AQ commands
triggering functions use stack to save results of AQ and then copy them
to user given function.
Therefore to keep the compatibility layer common, introduce ENA_PROXY
macro. It either calls the wrapped function directly (in primary
process) or proxies it to the primary via DPDK IPC mechanism. Since all
proxied calls are taken under a lock share the result data through
shared memory (in struct ena_adapter) to work around 256B IPC parameter
size limit.

New proxy calls can be added by
1. Adding a new message type at the end of enum ena_mp_req
2. Adding new message arguments to the struct ena_mp_body if needed
3. Defining proxy request descriptor with ENA_PROXY_DESC. Its arguments
   include handlers for request preparation and response processing.
   Any of those may be empty (aside of marking arguments as used).
4. Adding request handling logic to ena_mp_primary_handle()
5. Replacing proxied function calls with ENA_PROXY(adapter, , ...)

Signed-off-by: Stanislaw Kardach 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
v3:
* Fix FreeBSD build error, by changing ECOMM error to EIO.
* Fix build errors with assertions enabled, by fixing the variable name.

 doc/guides/rel_notes/release_22_03.rst |   1 +
 drivers/net/ena/ena_ethdev.c   | 384 -
 drivers/net/ena/ena_ethdev.h   |   9 +
 drivers/net/ena/ena_rss.c  |  10 +-
 4 files changed, 384 insertions(+), 20 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 92490afd60..5c2521e870 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -113,6 +113,7 @@ New Features
 ``l4_csum_good``.
   * Added support for the link status configuration.
   * Added optimized memcpy support for the ARM platforms.
+  * Added ENA admin queue support for the MP applications.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ed3dd162ba..e36d06ba91 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -242,13 +242,16 @@ static int ena_process_bool_devarg(const char *key,
   void *opaque);
 static int ena_parse_devargs(struct ena_adapter *adapter,
 struct rte_devargs *devargs);
-static int ena_copy_eni_stats(struct ena_adapter *adapter);
+static int ena_copy_eni_stats(struct ena_adapter *adapter,
+ struct ena_stats_eni *stats);
 static int ena_setup_rx_intr(struct rte_eth_dev *dev);
 static int ena_rx_queue_intr_enable(struct rte_eth_dev *dev,
uint16_t queue_id);
 static int ena_rx_queue_intr_disable(struct rte_eth_dev *dev,
 uint16_t queue_id);
 static int ena_configure_aenq(struct ena_adapter *adapter);
+static int ena_mp_primary_handle(const struct rte_mp_msg *mp_msg,
+const void *peer);
 
 static const struct eth_dev_ops ena_dev_ops = {
.dev_configure= ena_dev_configure,
@@ -275,6 +278,261 @@ static const struct eth_dev_ops ena_dev_ops = {
.rss_hash_conf_get= ena_rss_hash_conf_get,
 };
 
+/*
+ *  Multi-Process communication bits
+ */
+/* rte_mp IPC message name */
+#define ENA_MP_NAME"net_ena_mp"
+/* Request timeout in seconds */
+#define ENA_MP_REQ_TMO 5
+
+/** Proxy request type */
+enum ena_mp_req {
+   ENA_MP_DEV_STATS_GET,
+   ENA_MP_ENI_STATS_GET,
+   ENA_MP_MTU_SET,
+   ENA_MP_IND_TBL_GET,
+   ENA_MP_IND_TBL_SET
+};
+
+/** Proxy message body. Shared between requests and responses. */
+struct ena_mp_body {
+   /* Message type */
+   enum ena_mp_req type;
+   int port_id;
+   /* Processing result. Set in replies. 0 if message succeeded, negative
+* error code otherwise.
+*/
+   int result;
+   union {
+   int mtu; /* For ENA_MP_MTU_SET */
+   } args;
+};
+
+/**
+ * Initialize IPC message.
+ *
+ * @param[out] msg
+ *   Pointer to the message to initialize.
+ * @param[in] type
+ *   Message type.
+ * @param[in] port_id
+ *   Port ID of target device.
+ *
+ */
+static void
+mp_msg_init(struct rte_mp_msg *msg, enum ena_mp_req type, int port_id)
+{
+   struct ena_mp_body *body = (struct ena_mp_body *)&msg->param;
+
+   memset(msg, 0, sizeof(*msg));
+   strlcpy(msg->name, ENA_MP_NAME, sizeof(msg->name));
+   msg->len_param = sizeof(*body);
+   body->type = type;
+   body->port_id = port_id;
+}
+
+/*
+ *  Multi-Process communication PMD API
+ ***

[PATCH v3 11/21] net/ena: enable stats get function for MP mode

[Michal Krawczyk]

From: Stanislaw Kardach 

Since statistic gathering is now proxied safely to primary process, it
can be enabled in secondary processes.

Signed-off-by: Stanislaw Kardach 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index e36d06ba91..38fbe1618e 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1068,9 +1068,6 @@ static int ena_stats_get(struct rte_eth_dev *dev,
int i;
int max_rings_stats;
 
-   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
-   return -ENOTSUP;
-
memset(&ena_stats, 0, sizeof(ena_stats));
 
rte_spinlock_lock(&adapter->admin_lock);
-- 
2.25.1

[PATCH v3 12/21] net/ena/base: make IO memzone unique per port

[Michal Krawczyk]

Originally, the ena_com memzone counter was shared by ports, which
caused the memzones to be harder to identify and could potentially
lead to race and because of that the counter had to be atomic.

This atomic counter was global variable and it couldn't work in the
multiprocess implementation.

The memzone is now being identified by the local to port memzone counter
and the port ID - both of those information can be found in the shared
data, so it can be probed easily.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/nics/features/ena.ini |  1 +
 drivers/net/ena/base/ena_plat_dpdk.h | 62 
 drivers/net/ena/ena_ethdev.c | 52 ++-
 drivers/net/ena/ena_ethdev.h |  2 +
 4 files changed, 71 insertions(+), 46 deletions(-)

diff --git a/doc/guides/nics/features/ena.ini b/doc/guides/nics/features/ena.ini
index 4db1db11f4..55690aaf5a 100644
--- a/doc/guides/nics/features/ena.ini
+++ b/doc/guides/nics/features/ena.ini
@@ -17,6 +17,7 @@ L3 checksum offload  = Y
 L4 checksum offload  = Y
 Basic stats  = Y
 Extended stats   = Y
+Multiprocess aware   = Y
 Linux= Y
 ARMv8= Y
 x86-32   = Y
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h 
b/drivers/net/ena/base/ena_plat_dpdk.h
index 41db883c63..8f2b3a87c2 100644
--- a/drivers/net/ena/base/ena_plat_dpdk.h
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -202,35 +203,20 @@ typedef struct {
 #define ENA_GET_SYSTEM_TIMEOUT(timeout_us)\
((timeout_us) * rte_get_timer_hz() / 100 + rte_get_timer_cycles())
 
-/*
- * Each rte_memzone should have unique name.
- * To satisfy it, count number of allocations and add it to name.
- */
-extern rte_atomic64_t ena_alloc_cnt;
+const struct rte_memzone *
+ena_mem_alloc_coherent(struct rte_eth_dev_data *data, size_t size,
+  int socket_id, unsigned int alignment, void **virt_addr,
+  dma_addr_t *phys_addr);
 
 #define ENA_MEM_ALLOC_COHERENT_ALIGNED(
   \
dmadev, size, virt, phys, mem_handle, alignment)   \
do {   \
-   const struct rte_memzone *mz = NULL;   \
-   ENA_TOUCH(dmadev); \
-   if ((size) > 0) {  \
-   char z_name[RTE_MEMZONE_NAMESIZE]; \
-   snprintf(z_name, sizeof(z_name),   \
-   "ena_alloc_%" PRIi64 "",   \
-   rte_atomic64_add_return(&ena_alloc_cnt, 1));   \
-   mz = rte_memzone_reserve_aligned(z_name, (size),   \
-   SOCKET_ID_ANY, RTE_MEMZONE_IOVA_CONTIG,\
-   alignment);\
-   mem_handle = mz;   \
-   }  \
-   if (mz == NULL) {  \
-   virt = NULL;   \
-   phys = 0;  \
-   } else {   \
-   memset(mz->addr, 0, (size));   \
-   virt = mz->addr;   \
-   phys = mz->iova;   \
-   }  \
+   void *virt_addr;   \
+   dma_addr_t phys_addr;  \
+   (mem_handle) = ena_mem_alloc_coherent((dmadev), (size),\
+   SOCKET_ID_ANY, (alignment), &virt_addr, &phys_addr);   \
+   (virt) = virt_addr;\
+   (phys) = phys_addr;\
} while (0)
 #define ENA_MEM_ALLOC_COHERENT(dmadev, size, virt, phys, mem_handle)  \
ENA_MEM_ALLOC_COHERENT_ALIGNED(dmadev, size, virt, phys,   \
@@ -242,25 +228,13 @@ extern rte_atomic64_t ena_alloc_cnt;
 #define ENA_MEM_ALLOC_COHERENT_NODE_ALIGNED(  \
dmadev, size, virt, phys, mem_handle, node, dev_node, alignment)   \
do {   \
-

[PATCH v3 13/21] net/ena: expose Tx cleanup function

[Michal Krawczyk]

From: Dawid Gorecki 

ENA driver did not allow applications to call tx_cleanup. Freeing Tx
mbufs was always done by the driver and it was not possible to manually
request the driver to free mbufs.

Modify ena_tx_cleanup function to accept maximum number of packets to
free and return number of packets that was freed.

Signed-off-by: Dawid Gorecki 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 doc/guides/nics/features/ena.ini   |  1 +
 doc/guides/rel_notes/release_22_03.rst |  1 +
 drivers/net/ena/ena_ethdev.c   | 27 ++
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/doc/guides/nics/features/ena.ini b/doc/guides/nics/features/ena.ini
index 55690aaf5a..59c1ae85fa 100644
--- a/doc/guides/nics/features/ena.ini
+++ b/doc/guides/nics/features/ena.ini
@@ -7,6 +7,7 @@
 Link status  = Y
 Link status event= Y
 Rx interrupt = Y
+Free Tx mbuf on demand = Y
 MTU update   = Y
 Scattered Rx = Y
 TSO  = Y
diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 5c2521e870..95b31fc372 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -114,6 +114,7 @@ New Features
   * Added support for the link status configuration.
   * Added optimized memcpy support for the ARM platforms.
   * Added ENA admin queue support for the MP applications.
+  * Added free Tx mbuf on demand feature support.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 73c1d63174..5e7b964995 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -170,7 +170,7 @@ static void ena_tx_map_mbuf(struct ena_ring *tx_ring,
void **push_header,
uint16_t *header_len);
 static int ena_xmit_mbuf(struct ena_ring *tx_ring, struct rte_mbuf *mbuf);
-static void ena_tx_cleanup(struct ena_ring *tx_ring);
+static int ena_tx_cleanup(void *txp, uint32_t free_pkt_cnt);
 static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
  uint16_t nb_pkts);
 static uint16_t eth_ena_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
@@ -276,6 +276,7 @@ static const struct eth_dev_ops ena_dev_ops = {
.rx_queue_intr_disable = ena_rx_queue_intr_disable,
.rss_hash_update  = ena_rss_hash_update,
.rss_hash_conf_get= ena_rss_hash_conf_get,
+   .tx_done_cleanup  = ena_tx_cleanup,
 };
 
 /*
@@ -2990,16 +2991,22 @@ static int ena_xmit_mbuf(struct ena_ring *tx_ring, 
struct rte_mbuf *mbuf)
return 0;
 }
 
-static void ena_tx_cleanup(struct ena_ring *tx_ring)
+static int ena_tx_cleanup(void *txp, uint32_t free_pkt_cnt)
 {
+   struct ena_ring *tx_ring = (struct ena_ring *)txp;
unsigned int total_tx_descs = 0;
+   unsigned int total_tx_pkts = 0;
uint16_t cleanup_budget;
uint16_t next_to_clean = tx_ring->next_to_clean;
 
-   /* Attempt to release all Tx descriptors (ring_size - 1 -> size_mask) */
-   cleanup_budget = tx_ring->size_mask;
+   /*
+* If free_pkt_cnt is equal to 0, it means that the user requested
+* full cleanup, so attempt to release all Tx descriptors
+* (ring_size - 1 -> size_mask)
+*/
+   cleanup_budget = (free_pkt_cnt == 0) ? tx_ring->size_mask : 
free_pkt_cnt;
 
-   while (likely(total_tx_descs < cleanup_budget)) {
+   while (likely(total_tx_pkts < cleanup_budget)) {
struct rte_mbuf *mbuf;
struct ena_tx_buffer *tx_info;
uint16_t req_id;
@@ -3021,6 +3028,7 @@ static void ena_tx_cleanup(struct ena_ring *tx_ring)
tx_ring->empty_tx_reqs[next_to_clean] = req_id;
 
total_tx_descs += tx_info->tx_descs;
+   total_tx_pkts++;
 
/* Put back descriptor to the ring for reuse */
next_to_clean = ENA_IDX_NEXT_MASKED(next_to_clean,
@@ -3034,8 +3042,11 @@ static void ena_tx_cleanup(struct ena_ring *tx_ring)
ena_com_update_dev_comp_head(tx_ring->ena_com_io_cq);
}
 
-   /* Notify completion handler that the cleanup was just called */
-   tx_ring->last_cleanup_ticks = rte_get_timer_cycles();
+   /* Notify completion handler that full cleanup was performed */
+   if (free_pkt_cnt == 0 || total_tx_pkts < cleanup_budget)
+   tx_ring->last_cleanup_ticks = rte_get_timer_cycles();
+
+   return total_tx_pkts;
 }
 
 static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
@@ -3056,7 +3067,7 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
 
available_desc = ena_com_free_q_entries(tx_ring->ena_com_io_sq);
if (available_desc < tx_ring->tx_free_thresh)
-   ena_tx_cleanup(tx_ring);
+   ena

[PATCH v3 14/21] net/ena: add API for probing xstat names by ID

[Michal Krawczyk]

ENA was only supporting retrieval of all the xstats name and wasn't
implementing the eth_xstats_get_names_by_id API.

As this API may be more efficient than retrieving all the names, it
tries to avoid excessive string copying.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/rel_notes/release_22_03.rst |   1 +
 drivers/net/ena/ena_ethdev.c   | 130 -
 2 files changed, 108 insertions(+), 23 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 95b31fc372..1746abddbb 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -115,6 +115,7 @@ New Features
   * Added optimized memcpy support for the ARM platforms.
   * Added ENA admin queue support for the MP applications.
   * Added free Tx mbuf on demand feature support.
+  * Added ``rte_eth_xstats_get_names_by_id`` API support.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 5e7b964995..11c9bb05e6 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -230,6 +230,10 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev);
 static int ena_xstats_get_names(struct rte_eth_dev *dev,
struct rte_eth_xstat_name *xstats_names,
unsigned int n);
+static int ena_xstats_get_names_by_id(struct rte_eth_dev *dev,
+ const uint64_t *ids,
+ struct rte_eth_xstat_name *xstats_names,
+ unsigned int size);
 static int ena_xstats_get(struct rte_eth_dev *dev,
  struct rte_eth_xstat *stats,
  unsigned int n);
@@ -254,29 +258,30 @@ static int ena_mp_primary_handle(const struct rte_mp_msg 
*mp_msg,
 const void *peer);
 
 static const struct eth_dev_ops ena_dev_ops = {
-   .dev_configure= ena_dev_configure,
-   .dev_infos_get= ena_infos_get,
-   .rx_queue_setup   = ena_rx_queue_setup,
-   .tx_queue_setup   = ena_tx_queue_setup,
-   .dev_start= ena_start,
-   .dev_stop = ena_stop,
-   .link_update  = ena_link_update,
-   .stats_get= ena_stats_get,
-   .xstats_get_names = ena_xstats_get_names,
-   .xstats_get   = ena_xstats_get,
-   .xstats_get_by_id = ena_xstats_get_by_id,
-   .mtu_set  = ena_mtu_set,
-   .rx_queue_release = ena_rx_queue_release,
-   .tx_queue_release = ena_tx_queue_release,
-   .dev_close= ena_close,
-   .dev_reset= ena_dev_reset,
-   .reta_update  = ena_rss_reta_update,
-   .reta_query   = ena_rss_reta_query,
-   .rx_queue_intr_enable = ena_rx_queue_intr_enable,
-   .rx_queue_intr_disable = ena_rx_queue_intr_disable,
-   .rss_hash_update  = ena_rss_hash_update,
-   .rss_hash_conf_get= ena_rss_hash_conf_get,
-   .tx_done_cleanup  = ena_tx_cleanup,
+   .dev_configure  = ena_dev_configure,
+   .dev_infos_get  = ena_infos_get,
+   .rx_queue_setup = ena_rx_queue_setup,
+   .tx_queue_setup = ena_tx_queue_setup,
+   .dev_start  = ena_start,
+   .dev_stop   = ena_stop,
+   .link_update= ena_link_update,
+   .stats_get  = ena_stats_get,
+   .xstats_get_names   = ena_xstats_get_names,
+   .xstats_get_names_by_id = ena_xstats_get_names_by_id,
+   .xstats_get = ena_xstats_get,
+   .xstats_get_by_id   = ena_xstats_get_by_id,
+   .mtu_set= ena_mtu_set,
+   .rx_queue_release   = ena_rx_queue_release,
+   .tx_queue_release   = ena_tx_queue_release,
+   .dev_close  = ena_close,
+   .dev_reset  = ena_dev_reset,
+   .reta_update= ena_rss_reta_update,
+   .reta_query = ena_rss_reta_query,
+   .rx_queue_intr_enable   = ena_rx_queue_intr_enable,
+   .rx_queue_intr_disable  = ena_rx_queue_intr_disable,
+   .rss_hash_update= ena_rss_hash_update,
+   .rss_hash_conf_get  = ena_rss_hash_conf_get,
+   .tx_done_cleanup= ena_tx_cleanup,
 };
 
 /*
@@ -3165,6 +3170,85 @@ static int ena_xstats_get_names(struct rte_eth_dev *dev,
return xstats_count;
 }
 
+/**
+ * DPDK callback to retrieve names of extended device statistics for the given
+ * ids.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ * @param[out] xstats_names
+ *   Buffer to insert names into.
+ * @param ids
+ *   IDs array for which the names should be retrieved.
+ * @param size
+ *   Number of 

[PATCH v3 15/21] net/ena: check if reset was already triggered

[Michal Krawczyk]

From: Dawid Gorecki 

When triggering the reset, no check was performed to see if the reset
was already triggered. This could result in original reset reason being
overwritten. Add ena_trigger_reset helper function, which checks if the
reset was triggered and only sets the reset reason if the reset wasn't
triggered yet. Replace all occurrences of manually setting the reset
with ena_trigger_reset call.

Fixes: 2081d5e2e92d ("net/ena: add reset routine")
Cc: sta...@dpdk.org

Signed-off-by: Dawid Gorecki 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 11c9bb05e6..3cdeba9fad 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -539,6 +539,15 @@ ENA_PROXY_DESC(ena_com_indirect_table_get, 
ENA_MP_IND_TBL_GET,
 }),
struct ena_com_dev *ena_dev, u32 *ind_tbl);
 
+static inline void ena_trigger_reset(struct ena_adapter *adapter,
+enum ena_regs_reset_reason_types reason)
+{
+   if (likely(!adapter->trigger_reset)) {
+   adapter->reset_reason = reason;
+   adapter->trigger_reset = true;
+   }
+}
+
 static inline void ena_rx_mbuf_prepare(struct ena_ring *rx_ring,
   struct rte_mbuf *mbuf,
   struct ena_com_rx_ctx *ena_rx_ctx,
@@ -666,8 +675,7 @@ static int validate_tx_req_id(struct ena_ring *tx_ring, u16 
req_id)
 
/* Trigger device reset */
++tx_ring->tx_stats.bad_req_id;
-   tx_ring->adapter->reset_reason = ENA_REGS_RESET_INV_TX_REQ_ID;
-   tx_ring->adapter->trigger_reset = true;
+   ena_trigger_reset(tx_ring->adapter, ENA_REGS_RESET_INV_TX_REQ_ID);
return -EFAULT;
 }
 
@@ -1783,8 +1791,7 @@ static void check_for_missing_keep_alive(struct 
ena_adapter *adapter)
if (unlikely((rte_get_timer_cycles() - adapter->timestamp_wd) >=
adapter->keep_alive_timeout)) {
PMD_DRV_LOG(ERR, "Keep alive timeout\n");
-   adapter->reset_reason = ENA_REGS_RESET_KEEP_ALIVE_TO;
-   adapter->trigger_reset = true;
+   ena_trigger_reset(adapter, ENA_REGS_RESET_KEEP_ALIVE_TO);
++adapter->dev_stats.wd_expired;
}
 }
@@ -1794,8 +1801,7 @@ static void check_for_admin_com_state(struct ena_adapter 
*adapter)
 {
if (unlikely(!ena_com_get_admin_running_state(&adapter->ena_dev))) {
PMD_DRV_LOG(ERR, "ENA admin queue is not in running state\n");
-   adapter->reset_reason = ENA_REGS_RESET_ADMIN_TO;
-   adapter->trigger_reset = true;
+   ena_trigger_reset(adapter, ENA_REGS_RESET_ADMIN_TO);
}
 }
 
@@ -2606,14 +2612,13 @@ static uint16_t eth_ena_recv_pkts(void *rx_queue, 
struct rte_mbuf **rx_pkts,
rc);
if (rc == ENA_COM_NO_SPACE) {
++rx_ring->rx_stats.bad_desc_num;
-   rx_ring->adapter->reset_reason =
-   ENA_REGS_RESET_TOO_MANY_RX_DESCS;
+   ena_trigger_reset(rx_ring->adapter,
+   ENA_REGS_RESET_TOO_MANY_RX_DESCS);
} else {
++rx_ring->rx_stats.bad_req_id;
-   rx_ring->adapter->reset_reason =
-   ENA_REGS_RESET_INV_RX_REQ_ID;
+   ena_trigger_reset(rx_ring->adapter,
+   ENA_REGS_RESET_INV_RX_REQ_ID);
}
-   rx_ring->adapter->trigger_reset = true;
return 0;
}
 
@@ -2978,9 +2983,8 @@ static int ena_xmit_mbuf(struct ena_ring *tx_ring, struct 
rte_mbuf *mbuf)
if (unlikely(rc)) {
PMD_DRV_LOG(ERR, "Failed to prepare Tx buffers, rc: %d\n", rc);
++tx_ring->tx_stats.prepare_ctx_err;
-   tx_ring->adapter->reset_reason =
-   ENA_REGS_RESET_DRIVER_INVALID_STATE;
-   tx_ring->adapter->trigger_reset = true;
+   ena_trigger_reset(tx_ring->adapter,
+   ENA_REGS_RESET_DRIVER_INVALID_STATE);
return rc;
}
 
-- 
2.25.1

[PATCH v3 16/21] net/ena: make Tx completion timeout configurable

[Michal Krawczyk]

The default missing Tx completion timeout was set to 5 seconds.
In order to provide users with the interface to control this timeout
to adjust it with the application's watchdog, the device argument for
controlling this value was added.

The parameter is called 'miss_txc_to' and can be modified using the
devargs interface:

  ./app -a ,miss_txc_to=UINT_NUMBER

This parameter accepts values from 0 to 60 and indicates number of
seconds after which the Tx packet will be considered as missing.

HW hints for the Tx completions timeout were removed to do not overwrite
parameter from the user. Also specyfing default Tx completion timeout
value was moved from the configuration to init phase in order to
simplify default value assignment.

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 doc/guides/nics/ena.rst|  9 
 doc/guides/rel_notes/release_22_03.rst |  1 +
 drivers/net/ena/ena_ethdev.c   | 66 --
 drivers/net/ena/ena_ethdev.h   |  1 +
 4 files changed, 62 insertions(+), 15 deletions(-)

diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 85c790e80f..3d780acac9 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -87,6 +87,15 @@ Configuration information
  effect only if the device also supports large LLQ headers. Otherwise, the
  default value will be used.
 
+   * **miss_txc_to** (default 5)
+
+ Number of seconds after which the Tx packet will be considered missing.
+ If the missing packets number will exceed dynamically calculated 
threshold,
+ the driver will trigger the device reset which should be handled by the
+ application. Checking for missing Tx completions happens in the driver's
+ timer service. Setting this parameter to 0 disables this feature. Maximum
+ allowed value is 60 seconds.
+
 **ENA Configuration Parameters**
 
* **Number of Queues**
diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 1746abddbb..e04567ed5b 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -116,6 +116,7 @@ New Features
   * Added ENA admin queue support for the MP applications.
   * Added free Tx mbuf on demand feature support.
   * Added ``rte_eth_xstats_get_names_by_id`` API support.
+  * Added ``miss_txc_to`` device argument for setting the Tx completion 
timeout.
 
 * **Updated Cisco enic driver.**
 
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 3cdeba9fad..0ca4269522 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -62,6 +62,10 @@ struct ena_stats {
 
 /* Device arguments */
 #define ENA_DEVARG_LARGE_LLQ_HDR "large_llq_hdr"
+/* Timeout in seconds after which a single uncompleted Tx packet should be
+ * considered as a missing.
+ */
+#define ENA_DEVARG_MISS_TXC_TO "miss_txc_to"
 
 /*
  * Each rte_memzone should have unique name.
@@ -2132,6 +2136,8 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
snprintf(adapter->name, ENA_NAME_MAX_LEN, "ena_%d",
 adapter->id_number);
 
+   adapter->missing_tx_completion_to = ENA_TX_TIMEOUT;
+
rc = ena_parse_devargs(adapter, pci_dev->device.devargs);
if (rc != 0) {
PMD_INIT_LOG(CRIT, "Failed to parse devargs\n");
@@ -2307,7 +2313,6 @@ static int ena_dev_configure(struct rte_eth_dev *dev)
adapter->missing_tx_completion_budget =
RTE_MIN(ENA_MONITORED_TX_QUEUES, dev->data->nb_tx_queues);
 
-   adapter->missing_tx_completion_to = ENA_TX_TIMEOUT;
/* To avoid detection of the spurious Tx completion timeout due to
 * application not calling the Tx cleanup function, set timeout for the
 * Tx queue which should be half of the missing completion timeout for a
@@ -2830,20 +2835,6 @@ static void ena_update_hints(struct ena_adapter *adapter,
adapter->ena_dev.mmio_read.reg_read_to =
hints->mmio_read_timeout * 1000;
 
-   if (hints->missing_tx_completion_timeout) {
-   if (hints->missing_tx_completion_timeout ==
-   ENA_HW_HINTS_NO_TIMEOUT) {
-   adapter->missing_tx_completion_to =
-   ENA_HW_HINTS_NO_TIMEOUT;
-   } else {
-   /* Convert from msecs to ticks */
-   adapter->missing_tx_completion_to = rte_get_timer_hz() *
-   hints->missing_tx_completion_timeout / 1000;
-   adapter->tx_cleanup_stall_delay =
-   adapter->missing_tx_completion_to / 2;
-   }
-   }
-
if (hints->driver_watchdog_timeout) {
if (hints->driver_watchdog_timeout == ENA_HW_HINTS_NO_TIMEOUT)
adapter->keep_alive_timeout = ENA_HW_HINTS_NO_TIMEOUT;
@@ -3396,6 +3387,45 @@ static i

[PATCH v3 17/21] net/ena: fix meta-desc DF flag setup

[Michal Krawczyk]

Whenever Tx checksum offload is being used, the meta descriptor content
is taken into consideration. Setting DF field properly in the meta
descriptor may have huge impact on the performance both for the IPv4 and
IPv6 packets.

The requirements for the df field are as below:
* No offload used - value doesn't matter
* IPv4 - 0 or 1, depending on the DF flag in the IPv4 header
* IPv6 - 1

Setting DF to 0 causes the packet to enter the slow-path in the HW and
as a result can noticeable impact the performance.

Moreover, as 'true' may not always be mapped to 1 depending on it's
definition for the given platform/compiler, for safety DF field is being
set explicitly to 1.

Fixes: 1173fca25af9 ("ena: add polling-mode driver")
Cc: sta...@dpdk.org

Signed-off-by: Michal Krawczyk 
Reviewed-by: Dawid Gorecki 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 0ca4269522..53a8071968 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -624,6 +624,8 @@ static inline void ena_tx_mbuf_prepare(struct rte_mbuf 
*mbuf,
 
if (mbuf->ol_flags & RTE_MBUF_F_TX_IPV6) {
ena_tx_ctx->l3_proto = ENA_ETH_IO_L3_PROTO_IPV6;
+   /* For the IPv6 packets, DF always needs to be true. */
+   ena_tx_ctx->df = 1;
} else {
ena_tx_ctx->l3_proto = ENA_ETH_IO_L3_PROTO_IPV4;
 
@@ -631,7 +633,7 @@ static inline void ena_tx_mbuf_prepare(struct rte_mbuf 
*mbuf,
if (mbuf->packet_type &
(RTE_PTYPE_L4_NONFRAG
 | RTE_PTYPE_INNER_L4_NONFRAG))
-   ena_tx_ctx->df = true;
+   ena_tx_ctx->df = 1;
}
 
/* check if L4 checksum is needed */
-- 
2.25.1

[PATCH v3 18/21] net/ena: extend debug prints for invalid req ID resets

[Michal Krawczyk]

From: Dawid Gorecki 

Add information about port id, queue id and req_id to error logs in
validate_tx_req_id.

Signed-off-by: Dawid Gorecki 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 53a8071968..b471102ea9 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -675,9 +675,11 @@ static int validate_tx_req_id(struct ena_ring *tx_ring, 
u16 req_id)
}
 
if (tx_info)
-   PMD_TX_LOG(ERR, "tx_info doesn't have valid mbuf\n");
+   PMD_TX_LOG(ERR, "tx_info doesn't have valid mbuf. queue %d:%d 
req_id %u\n",
+   tx_ring->port_id, tx_ring->id, req_id);
else
-   PMD_TX_LOG(ERR, "Invalid req_id: %hu\n", req_id);
+   PMD_TX_LOG(ERR, "Invalid req_id: %hu in queue %d:%d\n",
+   req_id, tx_ring->port_id, tx_ring->id);
 
/* Trigger device reset */
++tx_ring->tx_stats.bad_req_id;
-- 
2.25.1

[PATCH v3 19/21] net/ena: don't initialize LLQ when membar isn't exposed

[Michal Krawczyk]

From: Dawid Gorecki 

The ena_com_config_dev_mode() performs many calculations related to LLQ
and then performs an admin queue call to configure LLQ in the device.

All of the operations performed by ena_com_config_dev_mode() are
unnecessary if membar hasn't been found. Move the dev_mem_base check
before ena_com_config_dev_mode() call. This prevents the unnecessary
operations from being performed.

Fixes: 2fca2a98c0d1 ("net/ena: support LLQv2")
Cc: sta...@dpdk.org

Signed-off-by: Dawid Gorecki 
Reviewed-by: Michal Krawczyk 
Reviewed-by: Shai Brandes 
---
 drivers/net/ena/ena_ethdev.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index b471102ea9..151c688eec 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1953,6 +1953,13 @@ ena_set_queues_placement_policy(struct ena_adapter 
*adapter,
return 0;
}
 
+   if (adapter->dev_mem_base == NULL) {
+   PMD_DRV_LOG(ERR,
+   "LLQ is advertised as supported, but device doesn't 
expose mem bar\n");
+   ena_dev->tx_mem_queue_type = ENA_ADMIN_PLACEMENT_POLICY_HOST;
+   return 0;
+   }
+
rc = ena_com_config_dev_mode(ena_dev, llq, llq_default_configurations);
if (unlikely(rc)) {
PMD_INIT_LOG(WARNING,
@@ -1965,13 +1972,6 @@ ena_set_queues_placement_policy(struct ena_adapter 
*adapter,
if (ena_dev->tx_mem_queue_type == ENA_ADMIN_PLACEMENT_POLICY_HOST)
return 0;
 
-   if (!adapter->dev_mem_base) {
-   PMD_DRV_LOG(ERR,
-   "Unable to access LLQ BAR resource. Fallback to host 
mode policy.\n");
-   ena_dev->tx_mem_queue_type = ENA_ADMIN_PLACEMENT_POLICY_HOST;
-   return 0;
-   }
-
ena_dev->mem_bar = adapter->dev_mem_base;
 
return 0;
-- 
2.25.1

[PATCH v3 20/21] net/ena: don't indicate bad csum for L4 csum error

[Michal Krawczyk]

Some HW may invalidly set checksum error bit for the valid L4 checksum.
To avoid drop of the packets in that situation, do not indicate bad
checksum for L4 Rx csum offloads. Instead, set it as unknown, so the
application will re-verify this value.

The statistics counters will still work as previously.

Fixes: 05817057faba ("net/ena: fix indication of bad L4 Rx checksums")
Cc: sta...@dpdk.org

Signed-off-by: Michal Krawczyk 
---
 drivers/net/ena/ena_ethdev.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 151c688eec..4b58dcda74 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -583,7 +583,13 @@ static inline void ena_rx_mbuf_prepare(struct ena_ring 
*rx_ring,
} else {
if (unlikely(ena_rx_ctx->l4_csum_err)) {
++rx_stats->l4_csum_bad;
-   ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+   /*
+* For the L4 Rx checksum offload the HW may indicate
+* bad checksum although it's valid. Because of that,
+* we're setting the UNKNOWN flag to let the app
+* re-verify the checksum.
+*/
+   ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN;
} else {
++rx_stats->l4_csum_good;
ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
-- 
2.25.1

[PATCH v3 21/21] net/ena: update version to 2.6.0

[Michal Krawczyk]

This release contains multiple bug fixes and improvements, including
  - Removal of the linearization function from the xmit Tx path. The
DPDK assumes checking for the mbuf segments number in the Tx prepare
function.
  - Extra logs, statistics, checks...
  - Cleanup of the unused variables and definitions.
  - Configurable Link Status event.
  - Improvements for the timer service and the reset.
  - Usage of the optimized memcpy on ARM.
  - MP awareness improvements - extra API support for the secondary
processes (like reading basic statistics).
  - Support of the xstats API to get xstat names by ID.
  - Configurable Tx completions timeout.
  - Proper setting of the meta-descriptor's DF flag.

Signed-off-by: Michal Krawczyk 
---
 drivers/net/ena/ena_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 4b58dcda74..68768cab70 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -21,7 +21,7 @@
 #include 
 
 #define DRV_MODULE_VER_MAJOR   2
-#define DRV_MODULE_VER_MINOR   5
+#define DRV_MODULE_VER_MINOR   6
 #define DRV_MODULE_VER_SUBMINOR0
 
 #define __MERGE_64B_H_L(h, l) (((uint64_t)h << 32) | l)
-- 
2.25.1

[PATCH v3 0/2] net/cnxk: support IP reassembly offload

[Akhil Goyal]

cn10k platform can support IP reassembly offload for upto 4 fragments
in the inline IPsec path.
The feature is enabled and tested as per unit test app[1].

The patchset is rebased over [2].

[1]: http://patchwork.dpdk.org/user/todo/dpdk/?series=21716
[2]: http://patchwork.dpdk.org/project/dpdk/list/?series=21801

Changes in v3:
- 3rd and 4th patch of the series are separated out.
- rebased over a dependent series.

changes in v2:
- updated as per changes in ethdev patches
- dynflags and dynfield for incomplete reassembly are registered in a
  single API
- squashed the patch for dynfield in the reassembly patch.



Vidya Sagar Velumuri (2):
  common/cnxk: configure reassembly specific params
  net/cnxk: support IP reassembly

 drivers/common/cnxk/cnxk_security.c   |  10 +
 drivers/common/cnxk/roc_nix_inl.c |  23 +
 drivers/common/cnxk/roc_nix_inl.h |   7 +
 drivers/common/cnxk/version.map   |   1 +
 drivers/event/cnxk/cn10k_worker.h |  16 +-
 drivers/event/cnxk/deq/cn10k/deq_192_207.c|  12 +
 .../event/cnxk/deq/cn10k/deq_192_207_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_192_207_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_192_207_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_192_207_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_192_207_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_192_207_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_192_207_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_192_207_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_192_207_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_208_223.c|  12 +
 .../event/cnxk/deq/cn10k/deq_208_223_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_208_223_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_208_223_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_208_223_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_208_223_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_208_223_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_208_223_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_208_223_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_208_223_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_224_239.c|  12 +
 .../event/cnxk/deq/cn10k/deq_224_239_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_224_239_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_224_239_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_224_239_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_224_239_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_224_239_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_224_239_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_224_239_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_224_239_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_240_255.c|  12 +
 .../event/cnxk/deq/cn10k/deq_240_255_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_240_255_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_240_255_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_240_255_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_240_255_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_240_255_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_240_255_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_240_255_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_240_255_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/meson.build|  64 ++
 drivers/net/cnxk/cn10k_ethdev.c   |  51 ++
 drivers/net/cnxk/cn10k_ethdev.h   |   2 +
 drivers/net/cnxk/cn10k_ethdev_sec.c   |  14 +
 drivers/net/cnxk/cn10k_rx

[PATCH v3 1/2] common/cnxk: configure reassembly specific params

[Akhil Goyal]

From: Vidya Sagar Velumuri 

When reassembly is enabled by application, set corresponding
flags in SA during creation.

Provide roc API to configure reassembly unit with active and zombie limits
and step size

Signed-off-by: Vidya Sagar Velumuri 
---
 drivers/common/cnxk/cnxk_security.c | 10 ++
 drivers/common/cnxk/roc_nix_inl.c   | 23 +++
 drivers/common/cnxk/roc_nix_inl.h   |  7 +++
 drivers/common/cnxk/version.map |  1 +
 4 files changed, 41 insertions(+)

diff --git a/drivers/common/cnxk/cnxk_security.c 
b/drivers/common/cnxk/cnxk_security.c
index d6006d3176..ec808c0033 100644
--- a/drivers/common/cnxk/cnxk_security.c
+++ b/drivers/common/cnxk/cnxk_security.c
@@ -339,6 +339,16 @@ cnxk_ot_ipsec_inb_sa_fill(struct roc_ot_ipsec_inb_sa *sa,
if (rc)
return rc;
 
+   /* Default options for pkt_out and pkt_fmt are with
+* second pass meta and no defrag.
+*/
+   sa->w0.s.pkt_format = ROC_IE_OT_SA_PKT_FMT_META;
+   sa->w0.s.pkt_output = ROC_IE_OT_SA_PKT_OUTPUT_NO_FRAG;
+   sa->w0.s.pkind = ROC_IE_OT_CPT_PKIND;
+
+   if (ipsec_xfrm->options.ip_reassembly_en)
+   sa->w0.s.pkt_output = ROC_IE_OT_SA_PKT_OUTPUT_HW_BASED_DEFRAG;
+
/* ESN */
sa->w2.s.esn_en = !!ipsec_xfrm->options.esn;
if (ipsec_xfrm->options.udp_encap) {
diff --git a/drivers/common/cnxk/roc_nix_inl.c 
b/drivers/common/cnxk/roc_nix_inl.c
index 7bf89a44c1..9db97b65df 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -231,6 +231,29 @@ roc_nix_inl_inb_sa_get(struct roc_nix *roc_nix, bool 
inb_inl_dev, uint32_t spi)
return (sa_base + ((spi & mask) * sz));
 }
 
+int
+roc_nix_reassembly_configure(uint32_t max_wait_time, uint16_t max_frags)
+{
+   struct idev_cfg *idev = idev_get_cfg();
+   struct roc_cpt *roc_cpt;
+   struct roc_cpt_rxc_time_cfg cfg;
+
+   (void)max_frags;
+   roc_cpt = idev->cpt;
+   if (!roc_cpt) {
+   plt_err("Cannot support inline inbound, cryptodev not probed");
+   return -ENOTSUP;
+   }
+
+   cfg.step = (max_wait_time * 1000 / ROC_NIX_INL_REAS_ACTIVE_LIMIT);
+   cfg.zombie_limit = ROC_NIX_INL_REAS_ZOMBIE_LIMIT;
+   cfg.zombie_thres = ROC_NIX_INL_REAS_ZOMBIE_THRESHOLD;
+   cfg.active_limit = ROC_NIX_INL_REAS_ACTIVE_LIMIT;
+   cfg.active_thres = ROC_NIX_INL_REAS_ACTIVE_THRESHOLD;
+
+   return roc_cpt_rxc_time_cfg(roc_cpt, &cfg);
+}
+
 int
 roc_nix_inl_inb_init(struct roc_nix *roc_nix)
 {
diff --git a/drivers/common/cnxk/roc_nix_inl.h 
b/drivers/common/cnxk/roc_nix_inl.h
index 5eb1a81471..45d349acf4 100644
--- a/drivers/common/cnxk/roc_nix_inl.h
+++ b/drivers/common/cnxk/roc_nix_inl.h
@@ -43,6 +43,11 @@
 /* Alignment of SA Base */
 #define ROC_NIX_INL_SA_BASE_ALIGN BIT_ULL(16)
 
+#define ROC_NIX_INL_REAS_ACTIVE_LIMIT0xFFF
+#define ROC_NIX_INL_REAS_ACTIVE_THRESHOLD 10
+#define ROC_NIX_INL_REAS_ZOMBIE_LIMIT0xFFF
+#define ROC_NIX_INL_REAS_ZOMBIE_THRESHOLD 10
+
 static inline struct roc_onf_ipsec_inb_sa *
 roc_nix_inl_onf_ipsec_inb_sa(uintptr_t base, uint64_t idx)
 {
@@ -152,6 +157,8 @@ struct roc_nix_rq *__roc_api roc_nix_inl_dev_rq(void);
 int __roc_api roc_nix_inl_inb_tag_update(struct roc_nix *roc_nix,
 uint32_t tag_const, uint8_t tt);
 uint64_t __roc_api roc_nix_inl_dev_rq_limit_get(void);
+int __roc_api roc_nix_reassembly_configure(uint32_t max_wait_time,
+   uint16_t max_frags);
 
 /* NIX Inline Outbound API */
 int __roc_api roc_nix_inl_outb_init(struct roc_nix *roc_nix);
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index dbede4aeed..2e8da4c2a7 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/version.map
@@ -206,6 +206,7 @@ INTERNAL {
roc_nix_ptp_tx_ena_dis;
roc_nix_queues_ctx_dump;
roc_nix_ras_intr_ena_dis;
+   roc_nix_reassembly_configure;
roc_nix_register_cq_irqs;
roc_nix_register_queue_irqs;
roc_nix_rq_dump;
-- 
2.25.1

[PATCH v3 2/2] net/cnxk: support IP reassembly

[Akhil Goyal]

From: Vidya Sagar Velumuri 

Add capability and support for inbound reassembly
in cnxk driver.
Register the dynamic field for IPsec reassembly.
Attach the fragments using the dynamic field in case of incomplete
reassembly

Signed-off-by: Vidya Sagar Velumuri 
Signed-off-by: Akhil Goyal 
Signed-off-by: Nithin Dabilpuram 
---
 drivers/event/cnxk/cn10k_worker.h |  16 +-
 drivers/event/cnxk/deq/cn10k/deq_192_207.c|  12 +
 .../event/cnxk/deq/cn10k/deq_192_207_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_192_207_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_192_207_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_192_207_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_192_207_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_192_207_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_192_207_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_192_207_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_192_207_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_192_207_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_192_207_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_208_223.c|  12 +
 .../event/cnxk/deq/cn10k/deq_208_223_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_208_223_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_208_223_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_208_223_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_208_223_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_208_223_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_208_223_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_208_223_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_208_223_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_208_223_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_208_223_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_224_239.c|  12 +
 .../event/cnxk/deq/cn10k/deq_224_239_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_224_239_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_224_239_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_224_239_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_224_239_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_224_239_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_224_239_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_224_239_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_224_239_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_224_239_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_224_239_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/deq/cn10k/deq_240_255.c|  12 +
 .../event/cnxk/deq/cn10k/deq_240_255_burst.c  |  14 +
 drivers/event/cnxk/deq/cn10k/deq_240_255_ca.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_ca_seg.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_seg_burst.c |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_ca_tmo.c |  12 +
 .../cnxk/deq/cn10k/deq_240_255_ca_tmo_burst.c |  14 +
 .../cnxk/deq/cn10k/deq_240_255_ca_tmo_seg.c   |  13 +
 .../deq/cn10k/deq_240_255_ca_tmo_seg_burst.c  |  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_dual.c   |  12 +
 .../event/cnxk/deq/cn10k/deq_240_255_seg.c|  12 +
 .../cnxk/deq/cn10k/deq_240_255_seg_burst.c|  14 +
 .../event/cnxk/deq/cn10k/deq_240_255_tmo.c|  12 +
 .../cnxk/deq/cn10k/deq_240_255_tmo_burst.c|  14 +
 .../cnxk/deq/cn10k/deq_240_255_tmo_seg.c  |  12 +
 .../deq/cn10k/deq_240_255_tmo_seg_burst.c |  14 +
 drivers/event/cnxk/meson.build|  64 ++
 drivers/net/cnxk/cn10k_ethdev.c   |  51 ++
 drivers/net/cnxk/cn10k_ethdev.h   |   2 +
 drivers/net/cnxk/cn10k_ethdev_sec.c   |  14 +
 drivers/net/cnxk/cn10k_rx.c   |  35 +-
 drivers/net/cnxk/cn10k_rx.h   | 672 --
 drivers/net/cnxk/cnxk_ethdev.h|   4 +
 drivers/net/cnxk/meson.build  |  16 +
 drivers/net/cnxk/rx/cn10k/rx_192_207.c|  11 +
 drivers/net/cnxk/rx/cn10k/rx_192_207_mseg.c   |  11 +
 drivers/net/cnxk/rx/cn10k/rx_192_207_vec.c|  11 +
 .../net/cnxk/rx/cn10k/rx_192_207_vec_mseg.c   |  12 +
 drivers/net/cnxk/rx/cn10k/rx_208_223.c|  11 +
 drivers/net/cnxk/rx/cn10k/rx_208_223_mseg.c   |  11 +
 drivers/net/cnxk/rx/cn10k/rx_208_223_vec.c|  11 +
 .../net/cnxk/rx/cn10k/rx_208_22

Re: [PATCH] net/af_xdp: update doc with information on queue setup

[Ferruh Yigit]

On 2/22/2022 2:31 PM, Ciara Loftus wrote:

When an AF_XDP PMD is created without specifying the 'start_queue', the
default Rx queue associated with the socket will be Rx queue 0. A common
scenario encountered by users new to AF_XDP is that they create the
socket on queue 0 however their interface is configured with many more
queues. In this case, traffic might land on for example queue 18 which
means it will never reach the socket.

This commit updates the AF_XDP documentation with instructions on how to
configure the interface to ensure the traffic will land on queue 0 and
thus reach the socket successfully.

Signed-off-by: Ciara Loftus


This is useful, thanks.

Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.

Re: [PATCH v2 2/2] net/txgbe: fix debug log

[Ferruh Yigit]

On 2/23/2022 10:28 AM, Jiawen Wu wrote:

Remove 'DEBUGFUNC' due to too many invalid debug log prints, unify the
DEBUG level macros.

Fixes: 7dc117068a7c ("net/txgbe: support probe and remove")
Cc:sta...@dpdk.org

Signed-off-by: Jiawen Wu
---
  drivers/net/txgbe/base/meson.build|   2 +-
  drivers/net/txgbe/base/txgbe_eeprom.c |  41 ++
  drivers/net/txgbe/base/txgbe_hw.c | 202 ++
  drivers/net/txgbe/base/txgbe_mbx.c|  38 -
  drivers/net/txgbe/base/txgbe_mng.c|  21 +--
  drivers/net/txgbe/base/txgbe_osdep.h  |   1 +
  drivers/net/txgbe/base/txgbe_phy.c|  84 ++-
  drivers/net/txgbe/base/txgbe_vf.c |  12 +-
  drivers/net/txgbe/txgbe_logs.h|   7 +-
  9 files changed, 79 insertions(+), 329 deletions(-)

diff --git a/drivers/net/txgbe/base/meson.build 
b/drivers/net/txgbe/base/meson.build
index 7a30191472..09da79af40 100644
--- a/drivers/net/txgbe/base/meson.build
+++ b/drivers/net/txgbe/base/meson.build
@@ -22,6 +22,6 @@ foreach flag: error_cflags
  endforeach
  
  base_lib = static_library('txgbe_base', sources,

-dependencies: static_rte_eal,
+dependencies: [static_rte_eal, static_rte_ethdev],


Is this because of 'RTE_ETHER_ADDR_PRT_FMT' macro?
If so dependency should be 'static_rte_net', not ethdev.

[PATCH] common/cnxk: adds cn10k specific xstats

[Rahul Bhansali]

This adds cn10k specific rx xstats of bpf, cpt and
ipsecd counters.

Signed-off-by: Rahul Bhansali 
---
 drivers/common/cnxk/hw/nix.h |  1 +
 drivers/common/cnxk/roc_nix_stats.c  | 14 ++
 drivers/common/cnxk/roc_nix_xstats.h | 20 +++-
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/hw/nix.h b/drivers/common/cnxk/hw/nix.h
index 6931f1d1d2..1cc0c8dfb8 100644
--- a/drivers/common/cnxk/hw/nix.h
+++ b/drivers/common/cnxk/hw/nix.h
@@ -419,6 +419,7 @@
 #define NIX_STAT_LF_RX_RX_RC_OCTS_DROP  (0x16ull) /* [CN10K, .) */
 #define NIX_STAT_LF_RX_RX_RC_PKTS_DROP  (0x17ull) /* [CN10K, .) */
 #define NIX_STAT_LF_RX_RX_CPT_DROP_PKTS (0x18ull) /* [CN10K, .) */
+#define NIX_STAT_LF_RX_RX_IPSECD_DROP_PKTS (0x19ull) /* [CN10K, .) */
 
 #define CGX_RX_PKT_CNT  (0x0ull) /* [CN9K, CN10K) */
 #define CGX_RX_OCT_CNT  (0x1ull) /* [CN9K, CN10K) */
diff --git a/drivers/common/cnxk/roc_nix_stats.c 
b/drivers/common/cnxk/roc_nix_stats.c
index 756111fb1c..946cda114d 100644
--- a/drivers/common/cnxk/roc_nix_stats.c
+++ b/drivers/common/cnxk/roc_nix_stats.c
@@ -353,6 +353,13 @@ roc_nix_xstats_get(struct roc_nix *roc_nix, struct 
roc_nix_xstat *xstats,
xstats[count].id = count;
count++;
}
+
+   for (i = 0; i < CNXK_NIX_NUM_CN10K_RX_XSTATS; i++) {
+   xstats[count].value =
+   NIX_RX_STATS(nix_cn10k_rx_xstats[i].offset);
+   xstats[count].id = count;
+   count++;
+   }
}
 
return count;
@@ -422,6 +429,13 @@ roc_nix_xstats_names_get(struct roc_nix *roc_nix,
 nix_tx_xstats_rpm[i].name);
count++;
}
+
+   for (i = 0; i < CNXK_NIX_NUM_CN10K_RX_XSTATS; i++) {
+   snprintf(xstats_names[count].name,
+sizeof(xstats_names[count].name), "%s",
+nix_cn10k_rx_xstats[i].name);
+   count++;
+   }
}
}
 
diff --git a/drivers/common/cnxk/roc_nix_xstats.h 
b/drivers/common/cnxk/roc_nix_xstats.h
index b0eaab78e7..c0a6f693f2 100644
--- a/drivers/common/cnxk/roc_nix_xstats.h
+++ b/drivers/common/cnxk/roc_nix_xstats.h
@@ -34,6 +34,23 @@ static const struct cnxk_nix_xstats_name nix_rx_xstats[] = {
{"rx_drp_l3mcast", NIX_STAT_LF_RX_RX_DRP_L3MCAST},
 };
 
+static const struct cnxk_nix_xstats_name nix_cn10k_rx_xstats[] = {
+   {"rx_gc_octs_pass", NIX_STAT_LF_RX_RX_GC_OCTS_PASSED},
+   {"rx_gc_pkts_pass", NIX_STAT_LF_RX_RX_GC_PKTS_PASSED},
+   {"rx_yc_octs_pass", NIX_STAT_LF_RX_RX_YC_OCTS_PASSED},
+   {"rx_yc_pkts_pass", NIX_STAT_LF_RX_RX_YC_PKTS_PASSED},
+   {"rx_rc_octs_pass", NIX_STAT_LF_RX_RX_RC_OCTS_PASSED},
+   {"rx_rc_pkts_pass", NIX_STAT_LF_RX_RX_RC_PKTS_PASSED},
+   {"rx_gc_octs_drop", NIX_STAT_LF_RX_RX_GC_OCTS_DROP},
+   {"rx_gc_pkts_drop", NIX_STAT_LF_RX_RX_GC_PKTS_DROP},
+   {"rx_yc_octs_drop", NIX_STAT_LF_RX_RX_YC_OCTS_DROP},
+   {"rx_yc_pkts_drop", NIX_STAT_LF_RX_RX_YC_PKTS_DROP},
+   {"rx_rc_octs_drop", NIX_STAT_LF_RX_RX_RC_OCTS_DROP},
+   {"rx_rc_pkts_drop", NIX_STAT_LF_RX_RX_RC_PKTS_DROP},
+   {"rx_cpt_pkts_drop", NIX_STAT_LF_RX_RX_CPT_DROP_PKTS},
+   {"rx_ipsecd_pkts_drop", NIX_STAT_LF_RX_RX_IPSECD_DROP_PKTS},
+};
+
 static const struct cnxk_nix_xstats_name nix_q_xstats[] = {
{"rq_op_re_pkts", NIX_LF_RQ_OP_RE_PKTS},
 };
@@ -173,6 +190,7 @@ static const struct cnxk_nix_xstats_name 
nix_tx_xstats_cgx[] = {
 #define CNXK_NIX_NUM_TX_XSTATS_CGX PLT_DIM(nix_tx_xstats_cgx)
 #define CNXK_NIX_NUM_RX_XSTATS_RPM PLT_DIM(nix_rx_xstats_rpm)
 #define CNXK_NIX_NUM_TX_XSTATS_RPM PLT_DIM(nix_tx_xstats_rpm)
+#define CNXK_NIX_NUM_CN10K_RX_XSTATS PLT_DIM(nix_cn10k_rx_xstats)
 
 #define CNXK_NIX_NUM_XSTATS_REG
\
(CNXK_NIX_NUM_RX_XSTATS + CNXK_NIX_NUM_TX_XSTATS + \
@@ -182,7 +200,7 @@ static const struct cnxk_nix_xstats_name 
nix_tx_xstats_cgx[] = {
 CNXK_NIX_NUM_TX_XSTATS_CGX)
 #define CNXK_NIX_NUM_XSTATS_RPM
\
(CNXK_NIX_NUM_XSTATS_REG + CNXK_NIX_NUM_RX_XSTATS_RPM +\
-CNXK_NIX_NUM_TX_XSTATS_RPM)
+CNXK_NIX_NUM_TX_XSTATS_RPM + CNXK_NIX_NUM_CN10K_RX_XSTATS)
 
 static inline uint64_t
 roc_nix_num_rx_xstats(void)
-- 
2.25.1

RE: [PATCH v2 0/4] net/mlx5: support send scheduling for ConnectX-7

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Slava Ovsiienko 
> Sent: Tuesday, February 22, 2022 12:27 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> 
> Subject: [PATCH v2 0/4] net/mlx5: support send scheduling for ConnectX-7
> 
> Since the ConnectX-6DX the send scheduling capability is provided.
> An application can register the dynamic field and dynamic flags in mbuf for
> timestamp and specify the desired moment of time the packet should sent.
> 
> The send scheduling feature over ConnectX-6DX uses the complicated
> infrastructure with reference Clock Queue and inter-queue synchronizing
> operations. Since ConnectX-7 the new wait descriptor format is introduced
> where the timestamp can be promoted to hardware directly.
> The patchset adds support for this new hardware option in PMD.
> 
> Signed-off-by: Viacheslav Ovsiienko 
> 
> v1: http://patches.dpdk.org/project/dpdk/cover/20220214085655.22648-1-
> viachesl...@nvidia.com/
> v2: - fix compilation issues
> - rebase
> 
> Viacheslav Ovsiienko (4):
>   common/mlx5: add send on time capability check
>   net/mlx5: configure Tx queue with send on time offload
>   net/mlx5: add wait on time support in Tx datapath
>   doc: update send scheduling mlx5 feature description
> 
>  doc/guides/nics/mlx5.rst   |  5 ++
>  doc/guides/rel_notes/release_22_03.rst |  6 +++
>  drivers/common/mlx5/mlx5_devx_cmds.c   |  1 +
>  drivers/common/mlx5/mlx5_devx_cmds.h   |  1 +
>  drivers/common/mlx5/mlx5_prm.h | 27 +-
>  drivers/net/mlx5/linux/mlx5_verbs.c|  4 ++
>  drivers/net/mlx5/mlx5.h|  3 ++
>  drivers/net/mlx5/mlx5_devx.c   |  2 +
>  drivers/net/mlx5/mlx5_tx.h | 75 +++---
>  drivers/net/mlx5/mlx5_txq.c| 18 ++-
>  10 files changed, 131 insertions(+), 11 deletions(-)
> 
> --
> 2.18.1

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Anoob Joseph]

Hi Fan,

Is it possible to just skip these for QAT? You can add a driver name check and 
skip the specific cases. Later, when we add capability, then this check can be 
replaced with capability check.

If we remove the vectors, then a new PMD having the same issues as you reported 
may not declare the capability and would still pass the DPDK UTs. And then any 
application which attempts some of these could hit some issues. Isn't it better 
to have these tested by DPDK UTs? Isn't that the better solution overall?

Thanks,
Anoob

> -Original Message-
> From: Zhang, Roy Fan 
> Sent: Wednesday, February 23, 2022 4:05 PM
> To: Anoob Joseph ; Kusztal, ArkadiuszX
> 
> Cc: Akhil Goyal ; Umesh Kartha
> ; Ramkumar Balu ;
> dev@dpdk.org
> Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> cases
> 
> Hi Anoob,
> 
> You are right QAT doesn't like these test vectors - for the reason Arek stated
> in the patch.
> We are in the same page on updating the capability - we already planned for
> next release.
> Since you also agree these cases are not useful - can we do both instead
> (removing these test vectors in this release and update the capability in the
> next)?
> 
> Regards,
> Fan
> 
> > -Original Message-
> > From: Anoob Joseph 
> > Sent: Wednesday, February 23, 2022 10:09 AM
> > To: Kusztal, ArkadiuszX 
> > Cc: Akhil Goyal ; Zhang, Roy Fan
> > ; Umesh Kartha ;
> > Ramkumar Balu ; dev@dpdk.org
> > Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> > cases
> >
> > Hi Arek,
> >
> > I agree that these cases may not be particularly useful from
> > cryptographic standpoint, but how do we say from what values a PMD
> > "must" support? Are you having some trouble supporting some of these
> > values? Should we consider extending capabilities to help with this
> > rather than just removing the test vectors?
> >
> > Thanks,
> > Anoob
> >
> > > -Original Message-
> > > From: Arek Kusztal 
> > > Sent: Tuesday, February 8, 2022 4:25 PM
> > > To: dev@dpdk.org
> > > Cc: Akhil Goyal ; roy.fan.zh...@intel.com; Arek
> > > Kusztal 
> > > Subject: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> > cases
> > >
> > > External Email
> > >
> > > 
> > > -- Even if mod exp tests cases where modulus is not the biggest
> > > number are mathematically correct and can be computed,
> > > cryptographically it is useless and PMD does not need to support it.
> > >
> > > Signed-off-by: Arek Kusztal 
> > > ---
> > >  app/test/test_cryptodev_mod_test_vectors.h | 501
> > > --
> > --
> > > -
> > >  1 file changed, 501 deletions(-)
> > >
> > > diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> > > b/app/test/test_cryptodev_mod_test_vectors.h
> > > index c66f4b18bc..d108059624 100644
> > > --- a/app/test/test_cryptodev_mod_test_vectors.h
> > > +++ b/app/test/test_cryptodev_mod_test_vectors.h
> > > @@ -167,141 +167,6 @@ modex_test_data modex_test_case[] = {  },  {
> > >   .description = "Modular Exponentiation "
> > > -"(mod=8, base=65, exp=17, res=8)",
> > > - .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> > > - .base = {
> > > - .data = {
> > > - 0x25, 0x74, 0x41, 0xCE, 0xFA, 0x5C, 0x07, 0x2A,
> > > - 0xD1, 0x74, 0xF3, 0x3D, 0xE1, 0xCC, 0xC3, 0x18,
> > > - 0x7E, 0x4A, 0x21, 0x9F, 0x97, 0xA3, 0x26, 0x85,
> > > - 0x85, 0xD9, 0x9B, 0xE3, 0xBA, 0xB3, 0x70, 0xC9,
> > > - 0x26, 0x68, 0xE4, 0xB7, 0x4C, 0x88, 0x48, 0xC1,
> > > - 0x6B, 0xC6, 0x3C, 0x00, 0x8C, 0x6B, 0xC6, 0x11,
> > > - 0xD0, 0xD6, 0x61, 0x5D, 0xEC, 0xAA, 0xBA, 0x3B,
> > > - 0x7D, 0xB3, 0x0D, 0x3F, 0xA5, 0x4D, 0xEE, 0xE4,
> > > - 0xAC
> > > - },
> > > - .len = 65
> > > - },
> > > - .exponent = {
> > > - .data = {
> > > - 0x1C, 0x54, 0x2F, 0xCA, 0xDE, 0x4F, 0x17, 0x38,
> > > - 0x69, 0x87, 0xB4, 0xFF, 0x3A, 0x6C, 0x82, 0x70,
> > > - 0x53
> > > - },
> > > - .len = 17
> > > - },
> > > - .reminder = {
> > > - .data = {
> > > - 0x52, 0x06, 0x1A, 0x35, 0x70, 0x33, 0x78, 0x45
> > > - },
> > > - .len = 8
> > > - },
> > > - .modulus = {
> > > - .data = {
> > > - 0x6B, 0x6D, 0xFA, 0xCB, 0x09, 0x5D, 0x9C, 0xFD
> > > - },
> > > - .len = 8
> > > - },
> > > - .result_len = 8
> > > -},
> > > -{
> > > - .description = "Modular Exponentiation "
> > > -"(mod=100, base=150, exp=192, res=100)",
> > > - .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> > > - .base = {
> > > - .data = {
> > > - 0xC1, 0xA1, 0x04, 0xE4, 0x4D, 0x4A, 0xD3, 0x5C,
> > > - 0xB3, 0xD0, 0x16, 0x51, 0xA7, 0xF4, 0x82, 0x6C,
> > > - 0x22, 0xDD, 0x4D, 0xAA, 0x7

[PATCH] compress/mlx5: support out-of-space status

[Raja Zidane]

When trying to dequeue, an OP may fail due to insufficient space for the
OP output, the compressdev API defines out-of-space for OP status.
The driver can detect out-of-space errors and report them to the user.

Check if hw_error_syndrome specifies out-of-space and set the OP
status accordingly.
Also added an error message for a case of missing B-final flag.

Fixes: f8c97babc9f4 ("compress/mlx5: add data-path functions")
Cc: sta...@dpdk.org

Signed-off-by: Raja Zidane 
---
Acked-by: Matan Azrad ma...@nvidia.com
 drivers/common/mlx5/mlx5_prm.h|  5 +
 drivers/compress/mlx5/mlx5_compress.c | 12 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 495b63191a..fc05734ecd 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -249,6 +249,9 @@
 /* Maximum number of DS in WQE. Limited by 6-bit field. */
 #define MLX5_DSEG_MAX 63
 
+/* The 32 bit syndrome offset in struct mlx5_err_cqe. */
+#define MLX5_ERROR_CQE_SYNDROME_OFFSET 52
+
 /* The completion mode offset in the WQE control segment line 2. */
 #define MLX5_COMP_MODE_OFFSET 2
 
@@ -559,6 +562,8 @@ struct mlx5_rdma_write_wqe {
 #define MLX5_GGA_COMP_LOG_BLOCK_SIZE_MAX 15u
 #define MLX5_GGA_COMP_LOG_DYNAMIC_SIZE_MAX 15u
 #define MLX5_GGA_COMP_LOG_DYNAMIC_SIZE_MIN 0u
+#define MLX5_GGA_COMP_OUT_OF_SPACE_SYNDROME_BE 0x29D0084
+#define MLX5_GGA_COMP_MISSING_BFINAL_SYNDROME_BE 0x29D0011
 
 struct mlx5_wqe_metadata_seg {
uint32_t mmo_control_31_0; /* mmo_control_63_32 is in ctrl_seg.imm */
diff --git a/drivers/compress/mlx5/mlx5_compress.c 
b/drivers/compress/mlx5/mlx5_compress.c
index 7a482c3fbb..fc50b5bde9 100644
--- a/drivers/compress/mlx5/mlx5_compress.c
+++ b/drivers/compress/mlx5/mlx5_compress.c
@@ -562,7 +562,17 @@ mlx5_compress_cqe_err_handle(struct mlx5_compress_qp *qp,
qp->qp.wqes;
volatile struct mlx5_gga_compress_opaque *opaq = qp->opaque_mr.addr;
 
-   op->status = RTE_COMP_OP_STATUS_ERROR;
+   volatile uint32_t *synd_word = RTE_PTR_ADD(cqe, 
MLX5_ERROR_CQE_SYNDROME_OFFSET);
+   switch (*synd_word) {
+   case MLX5_GGA_COMP_OUT_OF_SPACE_SYNDROME_BE:
+   op->status = RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
+   DRV_LOG(DEBUG, "OUT OF SPACE error, output is bigger than dst 
buffer.");
+   break;
+   case MLX5_GGA_COMP_MISSING_BFINAL_SYNDROME_BE:
+   DRV_LOG(DEBUG, "The last compressed block missed the B-final 
flag; maybe the compressed data is not complete or garbaged?");
+   default:
+   op->status = RTE_COMP_OP_STATUS_ERROR;
+   }
op->consumed = 0;
op->produced = 0;
op->output_chksum = 0;
-- 
2.21.0

[PATCH] raw/cnxk_gpio: fix DPDK version in a map file

[Tomasz Duszynski]

PMD driver got merged during 22.03 merge window and number in map file
should reflect that.

Fixes: d0b8a4e19131 ("raw/cnxk_gpio: add GPIO driver skeleton")

Reported-by: Ferruh Yigit 
Signed-off-by: Tomasz Duszynski 
---
 drivers/raw/cnxk_gpio/version.map | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/raw/cnxk_gpio/version.map 
b/drivers/raw/cnxk_gpio/version.map
index 4a76d1d52d..c2e0723b4c 100644
--- a/drivers/raw/cnxk_gpio/version.map
+++ b/drivers/raw/cnxk_gpio/version.map
@@ -1,3 +1,3 @@
-DPDK_21 {
+DPDK_22 {
local: *;
 };
-- 
2.25.1

[PATCH] app/compress-perf: fix cyclecount enqueue ops allocation

[Raja Zidane]

In cyclecount main_loop function, each iteration it tries to enqueue X ops,
in case Y
---
Acked-by: Matan Azrad ma...@nvidia.com
 app/test-compress-perf/comp_perf_test_cyclecount.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-compress-perf/comp_perf_test_cyclecount.c 
b/app/test-compress-perf/comp_perf_test_cyclecount.c
index 1d8e5fe6c2..c215547291 100644
--- a/app/test-compress-perf/comp_perf_test_cyclecount.c
+++ b/app/test-compress-perf/comp_perf_test_cyclecount.c
@@ -273,7 +273,7 @@ main_loop(struct cperf_cyclecount_ctx *ctx, enum 
rte_comp_xform_type type)
/* Allocate compression operations */
if (ops_needed && rte_mempool_get_bulk(
mem->op_pool,
-   (void **)ops,
+   (void **)&ops[ops_unused],
ops_needed) != 0) {
RTE_LOG(ERR, USER1,
  "Could not allocate enough operations\n");
-- 
2.21.0

[PATCH] app/compress-perf: optimize ops pool allocation

[Raja Zidane]

An array of the size of total operations needed for the de/compression is
reserved for ops while enqueueing, although only first burst_size entries
of the array are used.

Reduce the size of the array allocated.

Fixes: b68a82425da4 ("app/compress-perf: add performance measurement")
Cc: sta...@dpdk.org

Signed-off-by: Raja Zidane 
---
Acked-by: Matan Azrad ma...@nvidia.com
 app/test-compress-perf/comp_perf_test_cyclecount.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/test-compress-perf/comp_perf_test_cyclecount.c 
b/app/test-compress-perf/comp_perf_test_cyclecount.c
index c215547291..a3f6404eb2 100644
--- a/app/test-compress-perf/comp_perf_test_cyclecount.c
+++ b/app/test-compress-perf/comp_perf_test_cyclecount.c
@@ -175,7 +175,8 @@ main_loop(struct cperf_cyclecount_ctx *ctx, enum 
rte_comp_xform_type type)
 
/* one array for both enqueue and dequeue */
ops = rte_zmalloc_socket(NULL,
-   2 * mem->total_bufs * sizeof(struct rte_comp_op *),
+   (test_data->burst_sz + mem->total_bufs) *
+   sizeof(struct rte_comp_op *),
0, rte_socket_id());
 
if (ops == NULL) {
@@ -184,7 +185,7 @@ main_loop(struct cperf_cyclecount_ctx *ctx, enum 
rte_comp_xform_type type)
return -1;
}
 
-   deq_ops = &ops[mem->total_bufs];
+   deq_ops = &ops[test_data->burst_sz];
 
if (type == RTE_COMP_COMPRESS) {
xform = (struct rte_comp_xform) {
-- 
2.21.0

[PATCH v2 0/5] Refactor mlx5 guides

[Michael Baum]

Recently [1] all the drivers running over the mlx5 device started
sharing some objects.
This raised the need to create documentation for the common driver that
would contain information relevant to all drivers and in particular:

 - Tutorial for configuration of the device.
 - Instruction for using Mellanox ofed.
 - devargs of the common driver.

This series adds such documentation and reference to it as parts of the
documentation of the other drivers.

[1]
https://patchwork.dpdk.org/project/dpdk/cover/20211019205602.3188203-1-michae...@nvidia.com/

v2: Rebase


Michael Baum (5):
  doc: remove obsolete explanations from mlx5 guide
  doc: replace broken links in mlx5 guide
  doc: correct name of BlueField-2 in mlx5 guide
  doc: add shared guide for mlx5 PMDs
  doc: update doorbell mapping parameter name in mlx5 guide

 doc/guides/compressdevs/mlx5.rst   |  40 +-
 doc/guides/cryptodevs/mlx5.rst |  38 +-
 doc/guides/nics/mlx4.rst   |   4 +-
 doc/guides/nics/mlx5.rst   | 567 +-
 doc/guides/platform/index.rst  |   1 +
 doc/guides/platform/mlx5.rst   | 641 +
 doc/guides/regexdevs/mlx5.rst  |  44 +-
 doc/guides/vdpadevs/mlx5.rst   |  87 +--
 drivers/common/mlx5/linux/mlx5_common_os.c |   2 +-
 drivers/common/mlx5/mlx5_common.c  |  31 +-
 drivers/common/mlx5/mlx5_common_defs.h |   8 +-
 drivers/net/mlx5/linux/mlx5_verbs.c|   2 +-
 drivers/net/mlx5/mlx5_devx.c   |   2 +-
 13 files changed, 747 insertions(+), 720 deletions(-)
 create mode 100644 doc/guides/platform/mlx5.rst

-- 
2.25.1

[PATCH v2 1/5] doc: remove obsolete explanations from mlx5 guide

[Michael Baum]

Vectorized routines were removed in result of Tx datapath refactoring,
and devarg keys documentation was updated.

However, more updating should have been done. In environment variables
doc, there was explanation according to vectorized Tx which isn't
relevant anymore.

This patch removes this irrelevant explanation.

Fixes: a6bd4911ad93 ("net/mlx5: remove Tx implementation")
Cc: sta...@dpdk.org

Signed-off-by: Michael Baum 
Reviewed-by: Raslan Darawsheh 
Acked-by: Viacheslav Ovsiienko 
---
 doc/guides/nics/mlx5.rst | 9 -
 1 file changed, 9 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 6494f4ae39..c21df81717 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -557,15 +557,6 @@ Environment variables
   The register would be flushed to HW usually when the write-combining buffer
   becomes full, but it depends on CPU design.
 
-  Except for vectorized Tx burst routines, a write memory barrier is enforced
-  after updating the register so that the update can be immediately visible to
-  HW.
-
-  When vectorized Tx burst is called, the barrier is set only if the burst size
-  is not aligned to MLX5_VPMD_TX_MAX_BURST. However, setting this environmental
-  variable will bring better latency even though the maximum throughput can
-  slightly decline.
-
 Run-time configuration
 ~~
 
-- 
2.25.1

[PATCH v2 2/5] doc: replace broken links in mlx5 guide

[Michael Baum]

Update links in both mlx4 and mlx5 doc.

Signed-off-by: Michael Baum 
Reviewed-by: Raslan Darawsheh 
Acked-by: Viacheslav Ovsiienko 
---
 doc/guides/nics/mlx4.rst | 4 ++--
 doc/guides/nics/mlx5.rst | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index c81105730d..66493a1157 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -14,7 +14,7 @@ the `Mellanox website `_. Help is 
also provided by
 the `Mellanox community `_.
 
 There is also a `section dedicated to this poll mode driver
-`_.
+`_.
 
 
 Implementation details
@@ -219,7 +219,7 @@ Mellanox OFED as a fallback
 - `Mellanox OFED`_ version: **4.4, 4.5, 4.6**.
 - firmware version: **2.42.5000** and above.
 
-.. _`Mellanox OFED`: 
http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers
+.. _`Mellanox OFED`: 
https://network.nvidia.com/products/infiniband-drivers/linux/mlnx_ofed/
 
 .. note::
 
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index c21df81717..a15f1620ff 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -19,7 +19,7 @@ Information and documentation about these adapters can be 
found on the
 `Mellanox community `__.
 
 There is also a `section dedicated to this poll mode driver
-`__.
+`_.
 
 
 Design
@@ -1381,9 +1381,9 @@ managers on most distributions, this PMD requires 
Ethernet extensions that
 may not be supported at the moment (this is a work in progress).
 
 `Mellanox OFED
-`__ and
+`__ 
and
 `Mellanox EN
-`__
+`__
 include the necessary support and should be used in the meantime. For DPDK,
 only libibverbs, libmlx5, mlnx-ofed-kernel packages and firmware updates are
 required from that distribution.
-- 
2.25.1

[PATCH v2 3/5] doc: correct name of BlueField-2 in mlx5 guide

[Michael Baum]

Update "BlueField 2" -> "BlueField-2" in mlx5 docs.

Signed-off-by: Michael Baum 
Reviewed-by: Raslan Darawsheh 
Acked-by: Viacheslav Ovsiienko 
---
 doc/guides/compressdevs/mlx5.rst | 6 +++---
 doc/guides/cryptodevs/mlx5.rst   | 6 +++---
 doc/guides/nics/mlx5.rst | 2 +-
 doc/guides/regexdevs/mlx5.rst| 8 
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/doc/guides/compressdevs/mlx5.rst b/doc/guides/compressdevs/mlx5.rst
index a4e17f65b3..7f2d6bdfff 100644
--- a/doc/guides/compressdevs/mlx5.rst
+++ b/doc/guides/compressdevs/mlx5.rst
@@ -7,7 +7,7 @@ MLX5 compress driver
 
 
 The MLX5 compress driver library
-(**librte_compress_mlx5**) provides support for **Mellanox BlueField 2**
+(**librte_compress_mlx5**) provides support for **Mellanox BlueField-2**
 families of 25/50/100/200 Gb/s adapters.
 
 Design
@@ -21,7 +21,7 @@ These engines are part of the ARM complex of the BlueField 
chip, and as
 such they do not use NIC related resources (e.g. RX/TX bandwidth).
 They do share the same PCI and memory bandwidth.
 
-So, using the BlueField device (starting from BlueField 2), the compress
+So, using the BlueField device (starting from BlueField-2), the compress
 class operations can be supported in parallel to the net, vDPA and
 RegEx class operations.
 
@@ -95,7 +95,7 @@ Driver options
 Supported NICs
 --
 
-* Mellanox\ |reg| BlueField 2 SmartNIC
+* Mellanox\ |reg| BlueField-2 SmartNIC
 
 Prerequisites
 -
diff --git a/doc/guides/cryptodevs/mlx5.rst b/doc/guides/cryptodevs/mlx5.rst
index e86a6205e8..9936556cc9 100644
--- a/doc/guides/cryptodevs/mlx5.rst
+++ b/doc/guides/cryptodevs/mlx5.rst
@@ -88,7 +88,7 @@ The mlxreg dedicated tool should be used as follows:
   should not be specified.
 
   All the device ports should set it in order to move to operational mode.
-  For BlueField 2, the internal ports in the ARM system should also be set.
+  For BlueField-2, the internal ports in the ARM system should also be set.
 
 - Query CRYPTO_OPERATIONAL register to make sure the device is in Operational
   mode.
@@ -142,7 +142,7 @@ Supported NICs
 --
 
 * Mellanox\ |reg| ConnectX\ |reg|-6 200G MCX654106A-HCAT (2x200G)
-* Mellanox\ |reg| BlueField 2 SmartNIC
+* Mellanox\ |reg| BlueField-2 SmartNIC
 * Mellanox\ |reg| ConnectX\ |reg|-6 Dx
 
 
@@ -162,7 +162,7 @@ FW Prerequisites
 
 
 - xx.31.0328 for ConnectX-6.
-- xx.32.0108 for ConnectX-6 Dx and BlueField 2.
+- xx.32.0108 for ConnectX-6 Dx and BlueField-2.
 
 Linux Prerequisites
 ~~~
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a15f1620ff..9e10a68d6f 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -253,7 +253,7 @@ Limitations
 
 - Flex item:
 
-  - Hardware support: BlueField 2.
+  - Hardware support: BlueField-2.
   - Flex item is supported on PF only.
   - Hardware limits ``header_length_mask_width`` up to 6 bits.
   - Firmware supports 8 global sample fields.
diff --git a/doc/guides/regexdevs/mlx5.rst b/doc/guides/regexdevs/mlx5.rst
index b2bf0afd01..fc2cacba60 100644
--- a/doc/guides/regexdevs/mlx5.rst
+++ b/doc/guides/regexdevs/mlx5.rst
@@ -7,7 +7,7 @@ MLX5 RegEx driver
 =
 
 The MLX5 RegEx (Regular Expression) driver library
-(**librte_regex_mlx5**) provides support for **Mellanox BlueField 2**
+(**librte_regex_mlx5**) provides support for **Mellanox BlueField-2**
 families of 25/50/100/200 Gb/s adapters.
 
 Design
@@ -43,13 +43,13 @@ Features
 Supported NICs
 --
 
-* Mellanox\ |reg| BlueField 2 SmartNIC
+* Mellanox\ |reg| BlueField-2 SmartNIC
 
 Prerequisites
 -
 
-- BlueField 2 running Mellanox supported kernel.
-- Enable the RegEx capabilities using system call from the BlueField 2.
+- BlueField-2 running Mellanox supported kernel.
+- Enable the RegEx capabilities using system call from the BlueField-2.
 - Official support is not yet released.
 
 Limitations
-- 
2.25.1

[PATCH v2 4/5] doc: add shared guide for mlx5 PMDs

[Michael Baum]

Adds new documentation for MLX5 common driver that contains:
 - Its features list (doesn't exist for now).
 - Its devargs description.
 - Device configuration information and tutorial.
 - Quick Start Guide for Mellanox OFED/EN.

Move into this doc all shared information from other MLX5 PMD docs and
add them reference to new common doc.

Signed-off-by: Michael Baum 
Reviewed-by: Raslan Darawsheh 
Acked-by: Viacheslav Ovsiienko 
---
 doc/guides/compressdevs/mlx5.rst |  34 +-
 doc/guides/cryptodevs/mlx5.rst   |  32 +-
 doc/guides/nics/mlx5.rst | 522 ++-
 doc/guides/platform/index.rst|   1 +
 doc/guides/platform/mlx5.rst | 602 +++
 doc/guides/regexdevs/mlx5.rst|  36 +-
 doc/guides/vdpadevs/mlx5.rst |  87 +
 7 files changed, 662 insertions(+), 652 deletions(-)
 create mode 100644 doc/guides/platform/mlx5.rst

diff --git a/doc/guides/compressdevs/mlx5.rst b/doc/guides/compressdevs/mlx5.rst
index 7f2d6bdfff..273251e088 100644
--- a/doc/guides/compressdevs/mlx5.rst
+++ b/doc/guides/compressdevs/mlx5.rst
@@ -3,10 +3,10 @@
 
 .. include:: 
 
-MLX5 compress driver
+MLX5 Compress Driver
 
 
-The MLX5 compress driver library
+The mlx5 compress driver library
 (**librte_compress_mlx5**) provides support for **Mellanox BlueField-2**
 families of 25/50/100/200 Gb/s adapters.
 
@@ -25,30 +25,7 @@ So, using the BlueField device (starting from BlueField-2), 
the compress
 class operations can be supported in parallel to the net, vDPA and
 RegEx class operations.
 
-For security reasons and robustness, this driver only deals with virtual
-memory addresses. The way resources allocations are handled by the kernel,
-combined with hardware specifications that allow to handle virtual memory
-addresses directly, ensure that DPDK applications cannot access random
-physical memory (or memory that does not belong to the current process).
-
-The PMD uses libibverbs and libmlx5 to access the device firmware
-or directly the hardware components.
-There are different levels of objects and bypassing abilities
-to get the best performances:
-
-- Verbs is a complete high-level generic API.
-- Direct Verbs is a device-specific API.
-- DevX allows to access firmware objects.
-
-Enabling librte_compress_mlx5 causes DPDK applications to be linked against
-libibverbs.
-
-Mellanox mlx5 PCI device can be probed by number of different PCI devices,
-for example net / vDPA / RegEx. To select the compress PMD ``class=compress``
-should be specified as device parameter. The compress device can be probed and
-used with other Mellanox classes, by adding more options in the class.
-For example: ``class=net:compress`` will probe both the net PMD and the 
compress
-PMD.
+See :doc:`../../platform/mlx5` guide for more design details.
 
 Features
 
@@ -85,6 +62,9 @@ Limitations
 Driver options
 --
 
+Please refer to :ref:`mlx5 common options `
+for an additional list of options shared with other mlx5 drivers.
+
 - ``log-block-size`` parameter [int]
 
   Log of the Huffman block size in the Deflate algorithm.
@@ -101,4 +81,4 @@ Prerequisites
 -
 
 - Mellanox OFED version: **5.2**
-  see :doc:`../../nics/mlx5` guide for more Mellanox OFED details.
+  See :ref:`mlx5 common prerequisites ` for more 
details.
diff --git a/doc/guides/cryptodevs/mlx5.rst b/doc/guides/cryptodevs/mlx5.rst
index 9936556cc9..ef47aa65dd 100644
--- a/doc/guides/cryptodevs/mlx5.rst
+++ b/doc/guides/cryptodevs/mlx5.rst
@@ -28,23 +28,12 @@ when the MKEY is configured to perform crypto operations.
 
 The encryption does not require text to be aligned to the AES block size 
(128b).
 
-For security reasons and to increase robustness, this driver only deals with 
virtual
-memory addresses. The way resources allocations are handled by the kernel,
-combined with hardware specifications that allow handling virtual memory
-addresses directly, ensure that DPDK applications cannot access random
-physical memory (or memory that does not belong to the current process).
+See :doc:`../../platform/mlx5` guide for more design details.
 
-The PMD uses ``libibverbs`` and ``libmlx5`` to access the device firmware
-or to access the hardware components directly.
-There are different levels of objects and bypassing abilities.
-To get the best performances:
-
-- Verbs is a complete high-level generic API (Linux only).
-- Direct Verbs is a device-specific API (Linux only).
-- DevX allows to access firmware objects.
+Configuration
+-
 
-Enabling ``librte_crypto_mlx5`` causes DPDK applications
-to be linked against libibverbs on Linux OS.
+See the :ref:`mlx5 common configuration `.
 
 In order to move the device to crypto operational mode, credential and KEK
 (Key Encrypting Key) should be set as the first step.
@@ -109,10 +98,8 @@ The mlxreg dedicated tool should be used as follows:
 Driver options
 --
 
-- ``class`` parameter [string]
-
-  Select the class of the 

[PATCH v2 5/5] doc: update doorbell mapping parameter name in mlx5 guide

[Michael Baum]

The "tx_db_nc" devarg forces doorbell register mapping to non-cached
region eliminating the extra write memory barrier. This argument was
used in creating the UAR for Tx and thus affected its performance.

Recently [1] its use has been extended to all UAR creation in all mlx5
drivers, and now its name is no longer so accurate.

This patch changes its name to "sq_db_nc" to suit any send queue that
uses it. The old name will still work for backward compatibility.

[1] commit 5dfa003db53f ("common/mlx5: fix post doorbell barrier")

Signed-off-by: Michael Baum 
Reviewed-by: Raslan Darawsheh 
Acked-by: Viacheslav Ovsiienko 
---
 doc/guides/nics/mlx5.rst   | 34 ++-
 doc/guides/platform/mlx5.rst   | 39 ++
 drivers/common/mlx5/linux/mlx5_common_os.c |  2 +-
 drivers/common/mlx5/mlx5_common.c  | 31 -
 drivers/common/mlx5/mlx5_common_defs.h |  8 ++---
 drivers/net/mlx5/linux/mlx5_verbs.c|  2 +-
 drivers/net/mlx5/mlx5_devx.c   |  2 +-
 7 files changed, 72 insertions(+), 46 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index f94ed90ef0..8956cd1dd8 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -814,37 +814,9 @@ for an additional list of options shared with other mlx5 
drivers.
 
 - ``tx_db_nc`` parameter [int]
 
-  The rdma core library can map doorbell register in two ways, depending on the
-  environment variable "MLX5_SHUT_UP_BF":
-
-  - As regular cached memory (usually with write combining attribute), if the
-variable is either missing or set to zero.
-  - As non-cached memory, if the variable is present and set to not "0" value.
-
-  The type of mapping may slightly affect the Tx performance, the optimal 
choice
-  is strongly relied on the host architecture and should be deduced 
practically.
-
-  If ``tx_db_nc`` is set to zero, the doorbell is forced to be mapped to 
regular
-  memory (with write combining), the PMD will perform the extra write memory 
barrier
-  after writing to doorbell, it might increase the needed CPU clocks per packet
-  to send, but latency might be improved.
-
-  If ``tx_db_nc`` is set to one, the doorbell is forced to be mapped to non
-  cached memory, the PMD will not perform the extra write memory barrier
-  after writing to doorbell, on some architectures it might improve the
-  performance.
-
-  If ``tx_db_nc`` is set to two, the doorbell is forced to be mapped to regular
-  memory, the PMD will use heuristics to decide whether write memory barrier
-  should be performed. For bursts with size multiple of recommended one (64 
pkts)
-  it is supposed the next burst is coming and no need to issue the extra memory
-  barrier (it is supposed to be issued in the next coming burst, at least after
-  descriptor writing). It might increase latency (on some hosts till next
-  packets transmit) and should be used with care.
-
-  If ``tx_db_nc`` is omitted or set to zero, the preset (if any) environment
-  variable "MLX5_SHUT_UP_BF" value is used. If there is no "MLX5_SHUT_UP_BF",
-  the default ``tx_db_nc`` value is zero for ARM64 hosts and one for others.
+  This parameter name is deprecated and ignored.
+  The new name for this parameter is ``sq_db_nc``.
+  See :ref:`common driver options `.
 
 - ``tx_pp`` parameter [int]
 
diff --git a/doc/guides/platform/mlx5.rst b/doc/guides/platform/mlx5.rst
index 0fd5e6604d..d073c213ca 100644
--- a/doc/guides/platform/mlx5.rst
+++ b/doc/guides/platform/mlx5.rst
@@ -600,3 +600,42 @@ and below are the arguments supported by the common mlx5 
layer.
   from system by default, without explicit rte memory flag.
 
   By default, the PMD will set this value to 0.
+
+- ``sq_db_nc`` parameter [int]
+
+  The rdma core library can map doorbell register in two ways,
+  depending on the environment variable "MLX5_SHUT_UP_BF":
+
+  - As regular cached memory (usually with write combining attribute),
+if the variable is either missing or set to zero.
+  - As non-cached memory, if the variable is present and set to not "0" value.
+
+   The same doorbell mapping approach is implemented directly by PMD
+   in UAR generation for queues created with DevX.
+
+  The type of mapping may slightly affect the send queue performance,
+  the optimal choice strongly relied on the host architecture
+  and should be deduced practically.
+
+  If ``sq_db_nc`` is set to zero, the doorbell is forced to be mapped to
+  regular memory (with write combining), the PMD will perform the extra write
+  memory barrier after writing to doorbell, it might increase the needed CPU
+  clocks per packet to send, but latency might be improved.
+
+  If ``sq_db_nc`` is set to one, the doorbell is forced to be mapped to non
+  cached memory, the PMD will not perform the extra write memory barrier after
+  writing to doorbell, on some architectures it might improve the performance.
+
+  If ``sq_db_nc`` is set to two, the doorbell i

Re: more than 64 lcores not properly supported

[Thomas Monjalon]

23/02/2022 12:20, Ferruh Yigit:
> On 2/23/2022 10:42 AM, Morten Brørup wrote:
> > +Thomas, you may be interested in this discussion about applications using 
> > an uint64_t bit mask to identify active lcores.
> > 
> >> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> >> Sent: Wednesday, 23 February 2022 11.03
> >>
> >> On 2/23/2022 7:17 AM, Morten Brørup wrote:
>  From: Stephen Hemminger [mailto:step...@networkplumber.org]
>  Sent: Tuesday, 22 February 2022 17.03
> > 
> > [...]
> > 
> 
>  DPDK now supports > 64 lcores. So all code using/assuming a 64 bit
> >> mask
>  is broken.
> 
> >>>
> >>> Good point. Is there a TODO-list where such a general review request
> >> can be filed, or should we just file it as a system-wide bug in
> >> Bugzilla?
> >>>
> >>> Nonetheless, I think this one-line fix should be accepted as a short
> >> term solution.
> >>>
> >>
> >> Hi Morten,
> >>
> >> I suspect there can be more places that testpmd assumes
> >> max core number is 64, someone needs to spend time to
> >> analyze and fix it.
> > 
> > My point exactly. Someone needs to spend time to analyze all DPDK libraries 
> > and applications, and fix it where appropriate. Where do we register this 
> > required effort, so it can be picked up by someone?
> > 
> 
> testpmd is an application and it has its own restrictions,
> I *assumed* libraries are safe and restriction is only in
> testpmd, but may be better to verify this as well.
> 
> > Also, it should probably be mentioned as a known bug in the 22.03 release 
> > notes.

There are known bugs and things to verify.
Known bugs should be in bugzilla + release notes.
Verification tasks are difficult to track because there is no point
where we can be sure that things are fully verified.
Instead I think such kind of verification should be managed
as permanent tasks. Do you have a tool or process in mind?

Re: [PATCH] raw/cnxk_gpio: fix DPDK version in a map file

[Ferruh Yigit]

On 2/23/2022 1:32 PM, Tomasz Duszynski wrote:

PMD driver got merged during 22.03 merge window and number in map file
should reflect that.

Fixes: d0b8a4e19131 ("raw/cnxk_gpio: add GPIO driver skeleton")

Reported-by: Ferruh Yigit 
Signed-off-by: Tomasz Duszynski 


Acked-by: Ferruh Yigit 

Re: [PATCH v2 2/2] net/txgbe: fix debug log

[Ferruh Yigit]

On 2/23/2022 12:49 PM, Ferruh Yigit wrote:

On 2/23/2022 10:28 AM, Jiawen Wu wrote:

Remove 'DEBUGFUNC' due to too many invalid debug log prints, unify the
DEBUG level macros.

Fixes: 7dc117068a7c ("net/txgbe: support probe and remove")
Cc:sta...@dpdk.org

Signed-off-by: Jiawen Wu
---
  drivers/net/txgbe/base/meson.build    |   2 +-
  drivers/net/txgbe/base/txgbe_eeprom.c |  41 ++
  drivers/net/txgbe/base/txgbe_hw.c | 202 ++
  drivers/net/txgbe/base/txgbe_mbx.c    |  38 -
  drivers/net/txgbe/base/txgbe_mng.c    |  21 +--
  drivers/net/txgbe/base/txgbe_osdep.h  |   1 +
  drivers/net/txgbe/base/txgbe_phy.c    |  84 ++-
  drivers/net/txgbe/base/txgbe_vf.c |  12 +-
  drivers/net/txgbe/txgbe_logs.h    |   7 +-
  9 files changed, 79 insertions(+), 329 deletions(-)

diff --git a/drivers/net/txgbe/base/meson.build 
b/drivers/net/txgbe/base/meson.build
index 7a30191472..09da79af40 100644
--- a/drivers/net/txgbe/base/meson.build
+++ b/drivers/net/txgbe/base/meson.build
@@ -22,6 +22,6 @@ foreach flag: error_cflags
  endforeach
  base_lib = static_library('txgbe_base', sources,
-    dependencies: static_rte_eal,
+    dependencies: [static_rte_eal, static_rte_ethdev],


Is this because of 'RTE_ETHER_ADDR_PRT_FMT' macro?
If so dependency should be 'static_rte_net', not ethdev.


fixed in next-net while merging.

Re: [PATCH v2 0/2] Wangxun log fixes

[Ferruh Yigit]

On 2/23/2022 10:28 AM, Jiawen Wu wrote:

Remove redundant debug logs and unify the log format.

v2:
- Fix compile error.
- Merge broken log message lines.
- Use 'RTE_ETHER_ADDR_PRT_FMT' for MAC format.

Jiawen Wu (2):
   net/ngbe: fix debug log
   net/txgbe: fix debug log



Series applied to dpdk-next-net/main, thanks.

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Zhang, Roy Fan]

Hi Anoob,

Make sense. Will do ASAP.

Regards,
Fan

> -Original Message-
> From: Anoob Joseph 
> Sent: Wednesday, February 23, 2022 1:29 PM
> To: Zhang, Roy Fan ; Kusztal, ArkadiuszX
> 
> Cc: Akhil Goyal ; Umesh Kartha
> ; Ramkumar Balu ;
> dev@dpdk.org
> Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> cases
> 
> Hi Fan,
> 
> Is it possible to just skip these for QAT? You can add a driver name check and
> skip the specific cases. Later, when we add capability, then this check can be
> replaced with capability check.
> 
> If we remove the vectors, then a new PMD having the same issues as you
> reported may not declare the capability and would still pass the DPDK UTs.
> And then any application which attempts some of these could hit some
> issues. Isn't it better to have these tested by DPDK UTs? Isn't that the 
> better
> solution overall?
> 
> Thanks,
> Anoob
> 
> > -Original Message-
> > From: Zhang, Roy Fan 
> > Sent: Wednesday, February 23, 2022 4:05 PM
> > To: Anoob Joseph ; Kusztal, ArkadiuszX
> > 
> > Cc: Akhil Goyal ; Umesh Kartha
> > ; Ramkumar Balu ;
> > dev@dpdk.org
> > Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> > cases
> >
> > Hi Anoob,
> >
> > You are right QAT doesn't like these test vectors - for the reason Arek
> stated
> > in the patch.
> > We are in the same page on updating the capability - we already planned
> for
> > next release.
> > Since you also agree these cases are not useful - can we do both instead
> > (removing these test vectors in this release and update the capability in 
> > the
> > next)?
> >
> > Regards,
> > Fan
> >
> > > -Original Message-
> > > From: Anoob Joseph 
> > > Sent: Wednesday, February 23, 2022 10:09 AM
> > > To: Kusztal, ArkadiuszX 
> > > Cc: Akhil Goyal ; Zhang, Roy Fan
> > > ; Umesh Kartha ;
> > > Ramkumar Balu ; dev@dpdk.org
> > > Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> > > cases
> > >
> > > Hi Arek,
> > >
> > > I agree that these cases may not be particularly useful from
> > > cryptographic standpoint, but how do we say from what values a PMD
> > > "must" support? Are you having some trouble supporting some of these
> > > values? Should we consider extending capabilities to help with this
> > > rather than just removing the test vectors?
> > >
> > > Thanks,
> > > Anoob
> > >
> > > > -Original Message-
> > > > From: Arek Kusztal 
> > > > Sent: Tuesday, February 8, 2022 4:25 PM
> > > > To: dev@dpdk.org
> > > > Cc: Akhil Goyal ; roy.fan.zh...@intel.com; Arek
> > > > Kusztal 
> > > > Subject: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> > > cases
> > > >
> > > > External Email
> > > >
> > > > 
> > > > -- Even if mod exp tests cases where modulus is not the biggest
> > > > number are mathematically correct and can be computed,
> > > > cryptographically it is useless and PMD does not need to support it.
> > > >
> > > > Signed-off-by: Arek Kusztal 
> > > > ---
> > > >  app/test/test_cryptodev_mod_test_vectors.h | 501
> > > > --
> > > --
> > > > -
> > > >  1 file changed, 501 deletions(-)
> > > >
> > > > diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> > > > b/app/test/test_cryptodev_mod_test_vectors.h
> > > > index c66f4b18bc..d108059624 100644
> > > > --- a/app/test/test_cryptodev_mod_test_vectors.h
> > > > +++ b/app/test/test_cryptodev_mod_test_vectors.h
> > > > @@ -167,141 +167,6 @@ modex_test_data modex_test_case[] = {  },  {
> > > > .description = "Modular Exponentiation "
> > > > -  "(mod=8, base=65, exp=17, res=8)",
> > > > -   .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> > > > -   .base = {
> > > > -   .data = {
> > > > -   0x25, 0x74, 0x41, 0xCE, 0xFA, 0x5C, 0x07, 0x2A,
> > > > -   0xD1, 0x74, 0xF3, 0x3D, 0xE1, 0xCC, 0xC3, 0x18,
> > > > -   0x7E, 0x4A, 0x21, 0x9F, 0x97, 0xA3, 0x26, 0x85,
> > > > -   0x85, 0xD9, 0x9B, 0xE3, 0xBA, 0xB3, 0x70, 0xC9,
> > > > -   0x26, 0x68, 0xE4, 0xB7, 0x4C, 0x88, 0x48, 0xC1,
> > > > -   0x6B, 0xC6, 0x3C, 0x00, 0x8C, 0x6B, 0xC6, 0x11,
> > > > -   0xD0, 0xD6, 0x61, 0x5D, 0xEC, 0xAA, 0xBA, 0x3B,
> > > > -   0x7D, 0xB3, 0x0D, 0x3F, 0xA5, 0x4D, 0xEE, 0xE4,
> > > > -   0xAC
> > > > -   },
> > > > -   .len = 65
> > > > -   },
> > > > -   .exponent = {
> > > > -   .data = {
> > > > -   0x1C, 0x54, 0x2F, 0xCA, 0xDE, 0x4F, 0x17, 0x38,
> > > > -   0x69, 0x87, 0xB4, 0xFF, 0x3A, 0x6C, 0x82, 0x70,
> > > > -   0x53
> > > > -   },
> > > > -   .len = 17
> > > > -   },
> > > > -   .reminder = {
> > > > -   .data = {
> > > > -   

RE: [PATCH v2 0/5] Refactor mlx5 guides

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Michael Baum 
> Sent: Wednesday, February 23, 2022 3:48 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Slava Ovsiienko 
> Subject: [PATCH v2 0/5] Refactor mlx5 guides
> 
> Recently [1] all the drivers running over the mlx5 device started sharing some
> objects.
> This raised the need to create documentation for the common driver that
> would contain information relevant to all drivers and in particular:
> 
>  - Tutorial for configuration of the device.
>  - Instruction for using Mellanox ofed.
>  - devargs of the common driver.
> 
> This series adds such documentation and reference to it as parts of the
> documentation of the other drivers.
> 
> [1]
> https://patchwork.dpdk.org/project/dpdk/cover/20211019205602.3188203-
> 1-michae...@nvidia.com/
> 
> v2: Rebase
> 
> 
> Michael Baum (5):
>   doc: remove obsolete explanations from mlx5 guide
>   doc: replace broken links in mlx5 guide
>   doc: correct name of BlueField-2 in mlx5 guide
>   doc: add shared guide for mlx5 PMDs
>   doc: update doorbell mapping parameter name in mlx5 guide
> 
>  doc/guides/compressdevs/mlx5.rst   |  40 +-
>  doc/guides/cryptodevs/mlx5.rst |  38 +-
>  doc/guides/nics/mlx4.rst   |   4 +-
>  doc/guides/nics/mlx5.rst   | 567 +-
>  doc/guides/platform/index.rst  |   1 +
>  doc/guides/platform/mlx5.rst   | 641 +
>  doc/guides/regexdevs/mlx5.rst  |  44 +-
>  doc/guides/vdpadevs/mlx5.rst   |  87 +--
>  drivers/common/mlx5/linux/mlx5_common_os.c |   2 +-
>  drivers/common/mlx5/mlx5_common.c  |  31 +-
>  drivers/common/mlx5/mlx5_common_defs.h |   8 +-
>  drivers/net/mlx5/linux/mlx5_verbs.c|   2 +-
>  drivers/net/mlx5/mlx5_devx.c   |   2 +-
>  13 files changed, 747 insertions(+), 720 deletions(-)  create mode 100644
> doc/guides/platform/mlx5.rst
> 
> --
> 2.25.1

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Akhil Goyal]

Hi Anoob/Fan,
We no more add driver specific checks in test app. Everything comes from 
capabilities.
We may defer this patch to next release till we have something in capability or 
some other way.

> Hi Anoob,
> 
> Make sense. Will do ASAP.
> 
> Regards,
> Fan
> 

RE: [PATCH v1] drivers: fix incorrect E-Switch manager vport ID

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Shun Hao 
> Sent: Tuesday, February 22, 2022 5:07 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; or...@nvidia.com ; tho...@monjalon.net ;
> Xueming(Steven) Li 
> Cc: dev@dpdk.org ; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH v1] drivers: fix incorrect E-Switch manager vport ID
> 
> One of the E-Switch vports plays the special role - it is assigned as 
> "E-Switch
> manager" and has some special exclusive rights and duties - it maintains all
> the representors, manages FDB domain flows, etc. By default, the E-Switch
> vport index was supposed to be zero on standalone NICs (regular ConnectX)
> and 0xFFFE SmartNIC (BlueField), but that was not always correct - this index
> can be assigned with any value by kernel/hypervisor.
> 
> Currently the E-Switch manager vport id is supposed to be default - 0 for
> standalone NICs, and 0xFFFE for the SmartNICs, and is deduced from the
> device PCI id.
> 
> To handle this and do not suggest any default values, can use DevX API to
> query E-Switch manager vport ID directly from the firmware during
> initialization, and use that value by default. If the new method is not
> provided (legacy firmware), fallback to use the PCI id approach.
> 
> Fixes: a564038699f9 ("net/mlx5: support E-Switch manager egress traffic
> match")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Shun Hao 
> Acked-by: Viacheslav Ovsiienko 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus cases

[Zhang, Roy Fan]

Hi Akhil,

Currently these tests will fail on QAT - is it possible to merge this patch so 
that QAT won't fail and we can add them back after the capability check is 
added in the next release?

Regards,
Fan

> -Original Message-
> From: Akhil Goyal 
> Sent: Wednesday, February 23, 2022 2:38 PM
> To: Zhang, Roy Fan ; Anoob Joseph
> ; Kusztal, ArkadiuszX 
> Cc: Umesh Kartha ; Ramkumar Balu
> ; dev@dpdk.org
> Subject: RE: [EXT] [PATCH] test/crypto: remove mod exp smaller modulus
> cases
> 
> Hi Anoob/Fan,
> We no more add driver specific checks in test app. Everything comes from
> capabilities.
> We may defer this patch to next release till we have something in capability
> or some other way.
> 
> > Hi Anoob,
> >
> > Make sense. Will do ASAP.
> >
> > Regards,
> > Fan
> >