Re: [PATCH v2] eal: fix memory initialization deadlock

[Dmitry Kozlyuk]

2023-09-04 11:24 (UTC+0300), Artemy Kovalyov:
> diff --git a/lib/eal/common/eal_common_dynmem.c 
> b/lib/eal/common/eal_common_dynmem.c
> index bdbbe233a0..0d5da40096 100644
> --- a/lib/eal/common/eal_common_dynmem.c
> +++ b/lib/eal/common/eal_common_dynmem.c
> @@ -251,7 +251,10 @@ eal_dynmem_hugepage_init(void)
>*/
>   memset(&dummy, 0, sizeof(dummy));
>   dummy.hugepage_sz = hpi->hugepage_sz;
> - if (rte_memseg_list_walk(hugepage_count_walk, &dummy) < 0)
> + /*  memory_hotplug_lock is taken in rte_eal_init(), so it's
> +  *  safe to call thread-unsafe version.
> +  */

Nit: the lock is really taken in rte_eal_memory_init().
Probably "The lock is held during initialization, so..."
would more robust against code changes and differences between platforms.

Acked-by: Dmitry Kozlyuk 

RE: [PATCH v2 07/12] net/cpfl: create port representor

[Liu, Mingxia]

> -Original Message-
> From: Xing, Beilei 
> Sent: Wednesday, August 16, 2023 11:06 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
> ; Zhang, Qi Z 
> Subject: [PATCH v2 07/12] net/cpfl: create port representor
> 
> From: Beilei Xing 
> 
> Track representor request in a whitelist.
> Representor will only be created for active vport.
> 
> Signed-off-by: Jingjing Wu 
> Signed-off-by: Qi Zhang 
> Signed-off-by: Beilei Xing 
> ---
>  drivers/net/cpfl/cpfl_ethdev.c  | 107 ---
>  drivers/net/cpfl/cpfl_ethdev.h  |  34 +++
>  drivers/net/cpfl/cpfl_representor.c | 448 
> drivers/net/cpfl/cpfl_representor.h |  26 ++
>  drivers/net/cpfl/meson.build|   1 +
>  5 files changed, 573 insertions(+), 43 deletions(-)  create mode 100644
> drivers/net/cpfl/cpfl_representor.c
>  create mode 100644 drivers/net/cpfl/cpfl_representor.h
> 
> diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h 
> index
> 9c4d8d3ea1..d4d9727a80 100644
> --- a/drivers/net/cpfl/cpfl_ethdev.h
> +++ b/drivers/net/cpfl/cpfl_ethdev.h
> @@ -21,6 +21,7 @@
> 
>  #include "cpfl_logs.h"
>  #include "cpfl_cpchnl.h"
> +#include "cpfl_representor.h"
> 
>  /* Currently, backend supports up to 8 vports */
>  #define CPFL_MAX_VPORT_NUM   8
> @@ -60,11 +61,32 @@
>  #define IDPF_DEV_ID_CPF  0x1453
>  #define VIRTCHNL2_QUEUE_GROUP_P2P0x100
> 
> +#define CPFL_HOST_ID_NUM 2
> +#define CPFL_PF_TYPE_NUM 2
>  #define CPFL_HOST_ID_HOST0
>  #define CPFL_HOST_ID_ACC 1
>  #define CPFL_PF_TYPE_APF 0
>  #define CPFL_PF_TYPE_CPF 1
> 
[Liu, Mingxia] Better to use enum.

> +/* Function IDs on IMC side */
> +#define HOST0_APF0
> +#define HOST1_APF1
> +#define HOST2_APF2
> +#define HOST3_APF3
> +#define ACC_APF_ID   4
> +#define IMC_APF_ID   5
> +#define HOST0_NVME_ID6
> +#define ACC_NVME_ID  7
> +#define HOST0_CPF_ID 8
> +#define HOST1_CPF_ID 9
> +#define HOST2_CPF_ID 10
> +#define HOST3_CPF_ID 11
> +#define ACC_CPF_ID   12
> +#define IMC_IPF_ID   13
> +#define ATE_CPF_ID   14
> +#define ACC_LCE_ID   15
[Liu, Mingxia] Better to use enum.

> +#define IMC_MBX_EFD_ID   0
> +
>  struct cpfl_vport_param {
>   struct cpfl_adapter_ext *adapter;
>   uint16_t devarg_id; /* arg id from user */ @@ -136,6 +158,13 @@
> struct cpfl_vport {
>   bool p2p_manual_bind;
>  };
> 

[PATCH v2] net/ice: fix tm configuration cannot be cleared

[Kaiwen Deng]

When the device is stopped, DPDK resets the commit flag so that
we can update the hierarchy configuration. The commit flag is also
used to determine if the hierarchy configuration needs to be cleared.
When DPDK exits, it always stops the device first and also resets
the commit flag result in the hierarchy configuration is not cleared.

This commit changes DPDK to not reset the commit flag when the
device is stopped. And we prevent additional commit when device is
running by only checking the stop flag.

Fixes: f5ec6a3a1987 ("net/ice: fix TM hierarchy commit flag reset")
Cc: sta...@dpdk.org

Signed-off-by: Kaiwen Deng 
---
Changes since v1:
- Prevent additional commit when device is running.
---
---
 drivers/net/ice/ice_dcf_ethdev.c |  2 --
 drivers/net/ice/ice_dcf_sched.c  | 14 --
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 30ad18d8fc..065ec728c2 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -670,7 +670,6 @@ ice_dcf_dev_stop(struct rte_eth_dev *dev)
struct ice_dcf_adapter *dcf_ad = dev->data->dev_private;
struct rte_intr_handle *intr_handle = dev->intr_handle;
struct ice_adapter *ad = &dcf_ad->parent;
-   struct ice_dcf_hw *hw = &dcf_ad->real_hw;
 
if (ad->pf.adapter_stopped == 1) {
PMD_DRV_LOG(DEBUG, "Port is already stopped");
@@ -697,7 +696,6 @@ ice_dcf_dev_stop(struct rte_eth_dev *dev)
 
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
ad->pf.adapter_stopped = 1;
-   hw->tm_conf.committed = false;
 
return 0;
 }
diff --git a/drivers/net/ice/ice_dcf_sched.c b/drivers/net/ice/ice_dcf_sched.c
index a231c1e60b..b08bc5f1de 100644
--- a/drivers/net/ice/ice_dcf_sched.c
+++ b/drivers/net/ice/ice_dcf_sched.c
@@ -237,6 +237,7 @@ ice_dcf_node_add(struct rte_eth_dev *dev, uint32_t node_id,
enum ice_dcf_tm_node_type node_type = ICE_DCF_TM_NODE_TYPE_MAX;
struct ice_dcf_tm_shaper_profile *shaper_profile = NULL;
struct ice_dcf_adapter *adapter = dev->data->dev_private;
+   struct ice_adapter *ad = &adapter->parent;
struct ice_dcf_hw *hw = &adapter->real_hw;
struct ice_dcf_tm_node *parent_node;
struct ice_dcf_tm_node *tm_node;
@@ -246,10 +247,10 @@ ice_dcf_node_add(struct rte_eth_dev *dev, uint32_t 
node_id,
if (!params || !error)
return -EINVAL;
 
-   /* if already committed */
-   if (hw->tm_conf.committed) {
+   /* if port is running */
+   if (!ad->pf.adapter_stopped) {
error->type = RTE_TM_ERROR_TYPE_UNSPECIFIED;
-   error->message = "already committed";
+   error->message = "port is running";
return -EINVAL;
}
 
@@ -400,16 +401,17 @@ ice_dcf_node_delete(struct rte_eth_dev *dev, uint32_t 
node_id,
 {
enum ice_dcf_tm_node_type node_type = ICE_DCF_TM_NODE_TYPE_MAX;
struct ice_dcf_adapter *adapter = dev->data->dev_private;
+   struct ice_adapter *ad = &adapter->parent;
struct ice_dcf_hw *hw = &adapter->real_hw;
struct ice_dcf_tm_node *tm_node;
 
if (!error)
return -EINVAL;
 
-   /* if already committed */
-   if (hw->tm_conf.committed) {
+   /* if port is running */
+   if (!ad->pf.adapter_stopped) {
error->type = RTE_TM_ERROR_TYPE_UNSPECIFIED;
-   error->message = "already committed";
+   error->message = "port is running";
return -EINVAL;
}
 
-- 
2.25.1

RE: [PATCH] net/iavf: fix port stats not cleared

[Liao, TingtingX]

> -Original Message-
> From: Yiding Zhou  
> Sent: 2023年8月30日 14:55
> To: dev@dpdk.org
> Cc: Zhou, YidingX ; sta...@dpdk.org; Xu, KuanX 
> 
> Subject: [PATCH] net/iavf: fix port stats not cleared
>
> Call 'iavf_dev_stats_reset' during the initialization of the VF in order to 
> clear any statistics that may exist from the last use of the VF and to avoid 
> statistics errors.
>
> Fixes: 22b123a36d07 ("net/avf: initialize PMD")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kuan Xu 
> Signed-off-by: Yiding Zhou 
> 
Tested-by: Tingting Liao 

RE: [PATCH] net/ice: fix tm configuration cannot be clear

[Deng, KaiwenX]

> -Original Message-
> From: Zhang, Qi Z 
> Sent: Friday, September 1, 2023 1:39 PM
> To: Deng, KaiwenX ; dev@dpdk.org
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
> ; Xu, Ting 
> Subject: RE: [PATCH] net/ice: fix tm configuration cannot be clear
> 
> 
> 
> > -Original Message-
> > From: Deng, KaiwenX 
> > Sent: Tuesday, August 29, 2023 2:24 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; Yang, Qiming ; Zhou,
> > YidingX ; Deng, KaiwenX
> > ; Zhang, Qi Z ; Xu, Ting
> > 
> > Subject: [PATCH] net/ice: fix tm configuration cannot be clear
> >
> > When the device is stopped, DPDK resets the commit flag so that we can
> > update the hierarchy configuration.
> 
> Why we need to reset commit flag when device is stopped?
> If the commit flag indicate all tm configure has been committed, stop device
> does not change the status, its confusing to reset it.
> 
> Can we simply prevent additional commit when device is running by only
> checking the stop flag? And why we reject a commit if its already committed?
>>Thanks for your review, I submitted a new patch that changes DPDK to not
>>reset the commit flag when the device is stopped. And we prevent additional 
>>commit when device is running by only checking the stop flag.
> 
> > The commit flag is also used to determine if the hierarchy
> > configuration needs to be cleared.
> > When DPDK exits, it always stops the device first and also resets the
> > commit flag result in the hierarchy configuration is not cleared.
> >
> > This patch adds a new flag "need_clear" to determine if the hierarchy
> > configuration needs to be cleared.
> >
> > Fixes: 3a6bfc37eaf4 ("net/ice: support QoS config VF bandwidth in
> > DCF")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Kaiwen Deng 
> > ---

RE: [RFC] lib/st_ring: add single thread ring

[Konstantin Ananyev]

> > > Add a single thread safe and multi-thread unsafe ring data structure.
> > > This library provides an simple and efficient alternative to
> > > multi-thread safe ring when multi-thread safety is not required.
> >
> > Just a thought: do we really need whole new library for that?
> > From what I understand all we need right now just one extra function:
> > rte_ring_mt_unsafe_prod_deque(...)
> > Sorry for ugly name :)
> > To dequeue N elems from prod.tail.
> > Or you think there would be some extra advantages in ST version of the ring:
> > extra usages, better performance, etc.?
> There are multiple implementations of the ST ring being used in other parts 
> of DPDK. Mattias Ronnblom pointed out some (distributed
> scheduler, eth RX adapter, cmdline) [1] existing ones which will be replaced 
> by this one.
> This implementation will not use atomic instructions, head and tail indices 
> will be in the same cache line and it will be a double ended
> queue. So, I am expecting better perf and more use cases (some might not be 
> applicable currently).

Yep, I do understand that we can skip sync logic for ST case.
Ok, if we do have multiple use-cases it might be plausible to have a separate 
API for it.

> 
> [1] https://mails.dpdk.org/archives/dev/2023-August/275003.html
> 
> >
> > >
> > > Signed-off-by: Honnappa Nagarahalli 
> > > ---
> > > v1:
> > > 1) The code is very prelimnary and is not even compiled
> > > 2) This is intended to show the APIs and some thoughts on
> > > implementation
> > > 3) More APIs and the rest of the implementation will come in subsequent
> > >versions
> > >
> > >  lib/st_ring/rte_st_ring.h | 567
> > > ++
> > >  1 file changed, 567 insertions(+)
> > >  create mode 100644 lib/st_ring/rte_st_ring.h
> > >
> > > diff --git a/lib/st_ring/rte_st_ring.h b/lib/st_ring/rte_st_ring.h new
> > > file mode 100644 index 00..8cb8832591
> > > --- /dev/null
> > > +++ b/lib/st_ring/rte_st_ring.h
> > > @@ -0,0 +1,567 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2023 Arm Limited
> > > + */
> > > +
> > > +#ifndef _RTE_ST_RING_H_
> > > +#define _RTE_ST_RING_H_
> > > +
> > > +/**
> > > + * @file
> > > + * RTE Signle Thread Ring (ST Ring)
> > > + *
> > > + * The ST Ring is a fixed-size queue intended to be accessed
> > > + * by one thread at a time. It does not provide concurrent access to
> > > + * multiple threads. If there are multiple threads accessing the ST
> > > +ring,
> > > + * then the threads have to use locks to protect the ring from
> > > + * getting corrupted.
> > > + *
> > > + * - FIFO (First In First Out)
> > > + * - Maximum size is fixed; the pointers are stored in a table.
> > > + * - Consumer and producer part of same thread.
> > > + * - Multi-thread producers and consumers need locking.
> > > + * - Single/Bulk/burst dequeue at Tail or Head
> > > + * - Single/Bulk/burst enqueue at Head or Tail
> > > + *
> > > + */
> > > +
> > > +#ifdef __cplusplus
> > > +extern "C" {
> > > +#endif
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +/**
> > > + * Calculate the memory size needed for a ST ring
> > > + *
> > > + * This function returns the number of bytes needed for a ST ring,
> > > +given
> > > + * the number of elements in it. This value is the sum of the size of
> > > + * the structure rte_st_ring and the size of the memory needed by the
> > > + * elements. The value is aligned to a cache line size.
> > > + *
> > > + * @param count
> > > + *   The number of elements in the ring (must be a power of 2).
> > > + * @return
> > > + *   - The memory size needed for the ST ring on success.
> > > + *   - -EINVAL if count is not a power of 2.
> > > + */
> > > +ssize_t rte_st_ring_get_memsize(unsigned int count);
> > > +
> > > +/**
> > > + * Initialize a ST ring structure.
> > > + *
> > > + * Initialize a ST ring structure in memory pointed by "r". The size
> > > +of the
> > > + * memory area must be large enough to store the ring structure and
> > > +the
> > > + * object table. It is advised to use rte_st_ring_get_memsize() to
> > > +get the
> > > + * appropriate size.
> > > + *
> > > + * The ST ring size is set to *count*, which must be a power of two.
> > > + * The real usable ring size is *count-1* instead of *count* to
> > > + * differentiate a full ring from an empty ring.
> > > + *
> > > + * The ring is not added in RTE_TAILQ_ST_RING global list. Indeed,
> > > +the
> > > + * memory given by the caller may not be shareable among dpdk
> > > + * processes.
> > > + *
> > > + * @param r
> > > + *   The pointer to the ring structure followed by the elements table.
> > > + * @param name
> > > + *   The name of the ring.
> > > + * @param count
> > > + *   The number of elements in the ring (must be a power of 2,
> > > + *   unless RTE_ST_RING_F_EXACT_SZ is set in flags).
> > > + * @param flags
> > > + *   An OR of the following:
> > > + *   - RTE_ST_RING_F_EXACT_SZ: If this flag is set, the ring will hold
> > > + 

RE: [PATCH v2 07/12] net/cpfl: create port representor

[Liu, Mingxia]

> -Original Message-
> From: Xing, Beilei 
> Sent: Wednesday, August 16, 2023 11:06 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
> ; Zhang, Qi Z 
> Subject: [PATCH v2 07/12] net/cpfl: create port representor
> 
> From: Beilei Xing 
> 
> Track representor request in a whitelist.
> Representor will only be created for active vport.
> 
> Signed-off-by: Jingjing Wu 
> Signed-off-by: Qi Zhang 
> Signed-off-by: Beilei Xing 
> ---
>  drivers/net/cpfl/cpfl_ethdev.c  | 107 ---
>  drivers/net/cpfl/cpfl_ethdev.h  |  34 +++
>  drivers/net/cpfl/cpfl_representor.c | 448 
> drivers/net/cpfl/cpfl_representor.h |  26 ++
>  drivers/net/cpfl/meson.build|   1 +
>  5 files changed, 573 insertions(+), 43 deletions(-)  create mode 100644
> drivers/net/cpfl/cpfl_representor.c
>  create mode 100644 drivers/net/cpfl/cpfl_representor.h
> 
> +static int
> +cpfl_repr_init(struct rte_eth_dev *eth_dev, void *init_param) {
> + struct cpfl_repr *repr = CPFL_DEV_TO_REPR(eth_dev);
> + struct cpfl_repr_param *param = init_param;
> + struct cpfl_adapter_ext *adapter = param->adapter;
> +
> + repr->repr_id = param->repr_id;
> + repr->vport_info = param->vport_info;
> + repr->itf.type = CPFL_ITF_TYPE_REPRESENTOR;
> + repr->itf.adapter = adapter;
> + repr->itf.data = eth_dev->data;
> +
> + eth_dev->dev_ops = &cpfl_repr_dev_ops;
> +
> + eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
> + /* bit[15:14] type
> +  * bit[13] xeon/acc
> +  * bit[12] apf/cpf
> +  * bit[11:0] vf
> +  */
> + eth_dev->data->representor_id =
> + (uint16_t)(repr->repr_id.type << 14 |
> +repr->repr_id.host_id << 13 |
> +repr->repr_id.pf_id << 12 |
> +repr->repr_id.vf_id);
> +
[Liu, Mingxia]  how about use the macro variable ?
#define CPFL_REPRESENTOR_ID(type, host_id, pf_id, vf_id)\
  type) & 0x3) << 14) + (((host_id) & 0x1) << 13) + (((pf_id) & 0x1) << 12) 
+ ((vf_id) & 0xfff))

> +
> +static bool
> +match_repr_with_vport(const struct cpfl_repr_id *repr_id,
> +   struct cpchnl2_vport_info *info) {
> + int func_id;
> +
> + if (repr_id->type == RTE_ETH_REPRESENTOR_PF &&
> + info->func_type == 0) {
> + func_id = cpfl_func_id_get(repr_id->host_id, repr_id->pf_id);
> + if (func_id < 0)
> + return false;
> + else
> + return true;
> + } else if (repr_id->type == RTE_ETH_REPRESENTOR_VF &&
> +info->func_type == 1) {
[Liu, Mingxia] For good readability, func_type value 0 and 1 are better to be 
replaced by macro variables.

Re: 22.11.3 patches review and test

[Kevin Traynor]

On 05/09/2023 02:51, Zeng, ZhichaoX wrote:



Regards
Zhichao

-Original Message-
From: Kevin Traynor 
Sent: Monday, September 4, 2023 10:15 PM
To: Zeng, ZhichaoX ; Xu, HailinX
; Xueming Li ;
sta...@dpdk.org; Wu, Jingjing ; Xing, Beilei
; Xu, Ke1 ; Zhang, Qi Z

Cc: xuemi...@nvdia.com; dev@dpdk.org; Stokes, Ian ;
Mcnamara, John ; Luca Boccassi
; Xu, Qian Q ; Thomas Monjalon
; Peng, Yuan ; Chen,
Zhaoyan 
Subject: Re: 22.11.3 patches review and test

On 04/09/2023 10:32, Kevin Traynor wrote:

On 01/09/2023 04:23, Zeng, ZhichaoX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, August 31, 2023 8:18 PM
To: Xu, HailinX ; Xueming Li
; sta...@dpdk.org; Wu, Jingjing
; Xing, Beilei ; Xu,
Ke1 ; Zeng, ZhichaoX ;
Zhang, Qi Z 
Cc: xuemi...@nvdia.com; dev@dpdk.org; Stokes, Ian
; Mcnamara, John ;
Luca Boccassi ; Xu, Qian Q ;
Thomas Monjalon ; Peng, Yuan
; Chen, Zhaoyan 
Subject: Re: 22.11.3 patches review and test

On 30/08/2023 17:25, Kevin Traynor wrote:

On 29/08/2023 09:22, Xu, HailinX wrote:

-Original Message-
From: Xueming Li 
Sent: Thursday, August 17, 2023 2:14 PM
To: sta...@dpdk.org
Cc: xuemi...@nvdia.com; dev@dpdk.org; Abhishek Marathe
; Ali Alnubani
; Walker, Benjamin
; David Christensen
; Hemant Agrawal

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John

;

Ju-Hyoung Lee ; Kevin Traynor
; Luca Boccassi ; Pei
Zhang ; Xu, Qian Q ;
Raslan Darawsheh ; Thomas Monjalon
; Yanghang Liu ;

Peng,

Yuan ; Chen, Zhaoyan



Subject: 22.11.3 patches review and test

Hi all,

Here is a list of patches targeted for stable release 22.11.3.

The planned date for the final release is 31th August.

Please help with testing and validation of your use cases and
report any issues/results with reply-all to this mail. For the
final release the fixes and reported validations will be added to
the release

notes.


A release candidate tarball can be found at:

 https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.3-rc1

These patches are located at branch 22.11 of dpdk-stable repo:
 https://dpdk.org/browse/dpdk-stable/

Thanks.


We are conducting DPDK testing and have found two issues.

1. The startup speed of testpmd is significantly slower in the os of SUSE
   This issue fix patch has been merged into main, But it has
not backported

to 22.11.3.

   Fix patch commit id on DPDK main:
7e7b6762eac292e78c77ad37ec0973c0c944b845

2. The SCTP tunnel packet of iavf cannot be forwarded in avx512
mode


Need to clarify this sentence. It looks like it is not a functional
bug where
avx512 mode is selected and then an SCTP tunnel packet cannot be sent.
Instead, it is a possible performance issue that avx512 mode will
not be selected where it might have been due to unneeded additions
(RTE_ETH_TX_OFFLOAD_*_TNL_TSO) to IAVF_TX_NO_VECTOR_FLAGS.

@IAVF maintainers - please confirm my analysis is correct ?

In that case, as it is a possible performance issue in a specific
case for a single driver I think it is non-critical for 21.11 and we
can just revert the patch on the branch and wait for 21.11.6 release in

December.


Hi Kevin,

Since the LTS version of the IAVF driver does not support avx512
checksum offload, the scalar path should be selected, but this patch
makes it incorrectly select the
avx512 path, and the SCTP tunnel packets can't be forwarded properly.



ok, let's take a look at the patch and usage.

diff --git a/drivers/net/iavf/iavf_rxtx.h
b/drivers/net/iavf/iavf_rxtx.h index 8d4a77271a..605ea3f824 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -32,4 +32,8 @@
   RTE_ETH_TX_OFFLOAD_MULTI_SEGS |  \
   RTE_ETH_TX_OFFLOAD_TCP_TSO | \
+   RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |   \
+   RTE_ETH_TX_OFFLOAD_GRE_TNL_TSO | \
+   RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO |\
+   RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO |  \
   RTE_ETH_TX_OFFLOAD_SECURITY)



So we now have:
#define IAVF_TX_NO_VECTOR_FLAGS (\
RTE_ETH_TX_OFFLOAD_VLAN_INSERT | \
RTE_ETH_TX_OFFLOAD_QINQ_INSERT | \
RTE_ETH_TX_OFFLOAD_MULTI_SEGS |  \
RTE_ETH_TX_OFFLOAD_TCP_TSO | \
RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |   \
RTE_ETH_TX_OFFLOAD_GRE_TNL_TSO | \
RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO |\
RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO |  \
RTE_ETH_TX_OFFLOAD_SECURITY)





Hi Kevin,

This patch also removes two flags from IAVF_TX_NO_VECTOR_FLAGS, 
RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM
and RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM.


static inline int
iavf_tx_vec_queue_default(struct iavf_tx_queue *txq) {
if (!txq)
return -1;

if (txq->rs_thresh < IAVF_VPMD_TX_MAX_BURST ||
txq->rs_thresh > IAVF_VPMD_TX_MAX_FREE_BUF)

[Bug 1282] [openssl] dpdk-test-crypto-perf got stuck for multiple segments

[bugzilla]

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

Bug ID: 1282
   Summary: [openssl] dpdk-test-crypto-perf got stuck for multiple
segments
   Product: DPDK
   Version: unspecified
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: cryptodev
  Assignee: dev@dpdk.org
  Reporter: sbad...@nvidia.com
  Target Milestone: ---

Created attachment 260
  --> https://bugs.dpdk.org/attachment.cgi?id=260&action=edit
test_aes_gcm.data file

dpdk-test-crypto-perf got stuck when using openssl driver with multiple
segments.


To repro the issue, follow the steps below:

* To run the app, use the following command:

/download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff --vdev
crypto_openssl,max_nb_queue_pairs=14 --  --ptest pmd-cyclecount --aead-op
encrypt --optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data
--test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12
--aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 32
--devtype crypto_openssl --silent --csv-friendly

startup log:


EAL: Detected CPU lcores: 16
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
CRYPTODEV: Creating cryptodev crypto_openssl
CRYPTODEV: Initialisation parameters - name: crypto_openssl,socket id: 0, max
queue pairs: 14
Allocated pool "sess_mp_0" on socket 0

and the app got stuck.



While for mlx driver:

app command:

/download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff -a
:03:00.0,class=crypto,algo=1 --  --ptest pmd-cyclecount --aead-op encrypt
--optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data
--test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12
--aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 32
--devtype mlx5_pci --silent --csv-friendly
startup log:

EAL: Detected CPU lcores: 16
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: Probe PCI driver: mlx5_pci (15b3:a2dc) device: :03:00.0 (socket -1)
CRYPTODEV: Creating cryptodev mlx5_0
CRYPTODEV: Initialisation parameters - name: mlx5_0,socket id: -1, max queue
pairs: 8
Allocated pool "sess_mp_0" on socket 0
# lcore id,Buf Size,Burst Size,Enqueued,Dequeued,Enq Retries,Deq
Retries,Cycles/Op,Cycles/Enq,Cycles/Deq
 2,   256,32,837134,837134,0,533741119,4.285,132.728,3266.640
 5,   256,32,837134,837134,0,474591992,4.187,131.554,3267.847
 1,   256,32,837134,837134,0,534222454,4.188,132.515,3267.158
14,   256,32,837134,837134,0,534253999,4.290,134.163,3266.250
 8,   256,32,837134,837134,0,533930935,4.183,131.477,3268.442
10,   256,32,837134,837134,0,530621045,4.270,138.768,3261.594
 7,   256,32,837134,837134,0,533981498,4.198,137.662,3263.727
 3,   256,32,837134,837134,0,534203541,4.285,140.712,3258.738
 9,   256,32,837134,837134,0,532553766,4.433,135.760,3262.361
 4,   256,32,837134,837134,0,532835430,4.189,136.872,3263.587
11,   256,32,837134,837134,0,535932003,4.186,133.716,3265.873
12,   256,32,837134,837134,0,532764050,4.320,144.503,3254.523
13,   256,32,837134,837134,0,532940094,4.262,134.450,3264.728
 6,   256,32,837134,837134,0,2301821,4.278,109.988,14.931


and it works fine when using a single segment with openssl driver:

app command:

/download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff --vdev
crypto_openssl,max_nb_queue_pairs=14 --  --ptest pmd-cyclecount --aead-op
encrypt --optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data
--test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12
--aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 272
--devtype crypto_openssl --silent --csv-friendly--silent 
startup log:

EAL: Detected CPU lcores: 16
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
CRYPTODEV: Creating cryptodev crypto_openssl
CRYPTODEV: Initialisation parameters - name: crypto_openssl,socket id: 0, max
queue pairs: 14
Allocated pool "sess_mp_0" on socket 0
# lcore id,Buf Size,Burst Size,Enqueued,Dequeued,Enq Retries,Deq
Retries,Cycles/Op,Cycles/Enq,Cycles/Deq
14,   256,32,837134,837134,408,0,2.392,753.011,1.399
13,   256,32,837134,837134,408,0,2.380,805.099,1.418
12,   256,32,837134,837134,408,0,2.403,805.045,1.371
 9,   256,32,837134,837134,408,0,2.394,805.847,1.357
 8,   256,32,837134,837134,408,0,2.393,809.166,1.392
 4,   256,32,837134,837134,408,0,2.389,816.142,1.320
 5,   256,32,837134,83713

RE: [PATCH v2] eal: fix memory initialization deadlock

[Artemy Kovalyov]

> > +   /*  memory_hotplug_lock is taken in rte_eal_init(), so it's
> > +*  safe to call thread-unsafe version.
> > +*/
>
> Nit: the lock is really taken in rte_eal_memory_init().
> Probably "The lock is held during initialization, so..."
> would more robust against code changes and differences between platforms.

It was previously located differently, but in the current version, it has been 
shifted to rte_eal_init(). It might be worth noting this to ensure that if 
there are further code changes in the future, the locking problem becomes more 
apparent. We had discussed this in the bug report.

RE: 22.11.3 patches review and test

[Xueming(Steven) Li]

> -Original Message-
> From: Kevin Traynor 
> Sent: 9/5/2023 16:50
> To: Zeng, ZhichaoX ; Xu, HailinX
> ; Xueming(Steven) Li ;
> sta...@dpdk.org; Wu, Jingjing ; Xing, Beilei
> ; Xu, Ke1 ; Zhang, Qi Z
> 
> Cc: xuemi...@nvdia.com; dev@dpdk.org; Stokes, Ian ;
> Mcnamara, John ; Luca Boccassi
> ; Xu, Qian Q ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Peng, Yuan
> ; Chen, Zhaoyan ; Yang,
> Qiming ; Zhou, YidingX ;
> Cui, KaixinX 
> Subject: Re: 22.11.3 patches review and test
> 
> On 05/09/2023 02:51, Zeng, ZhichaoX wrote:
> >
> >
> > Regards
> > Zhichao
> >> -Original Message-
> >> From: Kevin Traynor 
> >> Sent: Monday, September 4, 2023 10:15 PM
> >> To: Zeng, ZhichaoX ; Xu, HailinX
> >> ; Xueming Li ;
> >> sta...@dpdk.org; Wu, Jingjing ; Xing, Beilei
> >> ; Xu, Ke1 ; Zhang, Qi Z
> >> 
> >> Cc: xuemi...@nvdia.com; dev@dpdk.org; Stokes, Ian
> >> ; Mcnamara, John ;
> >> Luca Boccassi ; Xu, Qian Q ;
> >> Thomas Monjalon ; Peng, Yuan
> >> ; Chen, Zhaoyan 
> >> Subject: Re: 22.11.3 patches review and test
> >>
> >> On 04/09/2023 10:32, Kevin Traynor wrote:
> >>> On 01/09/2023 04:23, Zeng, ZhichaoX wrote:
> > -Original Message-
> > From: Kevin Traynor 
> > Sent: Thursday, August 31, 2023 8:18 PM
> > To: Xu, HailinX ; Xueming Li
> > ; sta...@dpdk.org; Wu, Jingjing
> > ; Xing, Beilei ; Xu,
> > Ke1 ; Zeng, ZhichaoX ;
> > Zhang, Qi Z 
> > Cc: xuemi...@nvdia.com; dev@dpdk.org; Stokes, Ian
> > ; Mcnamara, John
> ;
> > Luca Boccassi ; Xu, Qian Q
> > ; Thomas Monjalon ;
> > Peng, Yuan ; Chen, Zhaoyan
> > 
> > Subject: Re: 22.11.3 patches review and test
> >
> > On 30/08/2023 17:25, Kevin Traynor wrote:
> >> On 29/08/2023 09:22, Xu, HailinX wrote:
>  -Original Message-
>  From: Xueming Li 
>  Sent: Thursday, August 17, 2023 2:14 PM
>  To: sta...@dpdk.org
>  Cc: xuemi...@nvdia.com; dev@dpdk.org; Abhishek Marathe
>  ; Ali Alnubani
>  ; Walker, Benjamin
>  ; David Christensen
>  ; Hemant Agrawal
> > ;
>  Stokes, Ian ; Jerin Jacob
>  ; Mcnamara, John
> >> ;
>  Ju-Hyoung Lee ; Kevin Traynor
>  ; Luca Boccassi ; Pei
>  Zhang ; Xu, Qian Q ;
>  Raslan Darawsheh ; Thomas Monjalon
>  ; Yanghang Liu ;
> >> Peng,
>  Yuan ; Chen, Zhaoyan
> > 
>  Subject: 22.11.3 patches review and test
> 
>  Hi all,
> 
>  Here is a list of patches targeted for stable release 22.11.3.
> 
>  The planned date for the final release is 31th August.
> 
>  Please help with testing and validation of your use cases and
>  report any issues/results with reply-all to this mail. For the
>  final release the fixes and reported validations will be added
>  to the release
> > notes.
> 
>  A release candidate tarball can be found at:
> 
> 
>  https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.3-rc1
> 
>  These patches are located at branch 22.11 of dpdk-stable repo:
>   https://dpdk.org/browse/dpdk-stable/
> 
>  Thanks.
> >>>
> >>> We are conducting DPDK testing and have found two issues.
> >>>
> >>> 1. The startup speed of testpmd is significantly slower in the os of
> SUSE
> >>>This issue fix patch has been merged into main, But it
> >>> has not backported
> > to 22.11.3.
> >>>Fix patch commit id on DPDK main:
> >>> 7e7b6762eac292e78c77ad37ec0973c0c944b845
> >>>
> >>> 2. The SCTP tunnel packet of iavf cannot be forwarded in avx512
> >>> mode
> >
> > Need to clarify this sentence. It looks like it is not a
> > functional bug where
> > avx512 mode is selected and then an SCTP tunnel packet cannot be
> sent.
> > Instead, it is a possible performance issue that avx512 mode will
> > not be selected where it might have been due to unneeded additions
> > (RTE_ETH_TX_OFFLOAD_*_TNL_TSO) to IAVF_TX_NO_VECTOR_FLAGS.
> >
> > @IAVF maintainers - please confirm my analysis is correct ?
> >
> > In that case, as it is a possible performance issue in a specific
> > case for a single driver I think it is non-critical for 21.11 and
> > we can just revert the patch on the branch and wait for 21.11.6
> > release in
> >> December.
> 
>  Hi Kevin,
> 
>  Since the LTS version of the IAVF driver does not support avx512
>  checksum offload, the scalar path should be selected, but this
>  patch makes it incorrectly select the
>  avx512 path, and the SCTP tunnel packets can't be forwarded properly.
> 
> >>>
> >>> ok, let's take a look at the patch and usage.
> >>>
> >>> diff --git a/drivers/net/iavf/iavf_rxtx.h
> >>> b/drivers/net/iavf/iavf_rxtx.h index 8d4a77271a..605ea3f824 100644
> >>> --- a/drivers/net/iavf/i

Re: [PATCH v2] eal: fix memory initialization deadlock

[David Marchand]

On Tue, Sep 5, 2023 at 11:05 AM Artemy Kovalyov  wrote:
>
> > > +   /*  memory_hotplug_lock is taken in rte_eal_init(), so it's
> > > +*  safe to call thread-unsafe version.
> > > +*/
> >
> > Nit: the lock is really taken in rte_eal_memory_init().
> > Probably "The lock is held during initialization, so..."
> > would more robust against code changes and differences between platforms.
>
> It was previously located differently, but in the current version, it has 
> been shifted to rte_eal_init(). It might be worth noting this to ensure that 
> if there are further code changes in the future, the locking problem becomes 
> more apparent. We had discussed this in the bug report.

One option to explore is lock annotations.

One note thought: those annotations do not get inherited in called code.
So some special care is needed to maintain/annotate all code leading
to the locations where the locks do matter.

Quick example with rte_memseg_list_walk:
https://github.com/david-marchand/dpdk/commit/mem_annotations

And clang catches a deadlock:
https://github.com/david-marchand/dpdk/actions/runs/6082842080/job/16501450978#step:19:816


-- 
David Marchand

[PATCH v4 0/2] Add Digest Encrypted to aesni_mb PMD

[Brian Dooley]

This series adds the Digest Encrypted feature to the AESNI_MB PMD.
It also fixes an issue where IV data in SNOW3G and ZUC algorithms
were incorrect and are required to be non-zero length.

v2:
Fixed CHECKPATCH warning
v3:
Add Digest encrypted support to docs
v4:
add comments and refactor

Brian Dooley (2):
  crypto/ipsec_mb: add digest encrypted feature
  test/crypto: fix IV in some vectors

 app/test/test_cryptodev_mixed_test_vectors.h |   8 +-
 doc/guides/cryptodevs/features/aesni_mb.ini  |   1 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c   | 107 ++-
 3 files changed, 109 insertions(+), 7 deletions(-)

-- 
2.25.1

[PATCH v4 1/2] crypto/ipsec_mb: add digest encrypted feature

[Brian Dooley]

AESNI_MB PMD does not support Digest Encrypted. This patch adds a check and
support for this feature.

Signed-off-by: Brian Dooley 
---
v2:
Fixed CHECKPATCH warning
v3:
Add Digest encrypted support to docs
v4:
add comments and refactor
---
 doc/guides/cryptodevs/features/aesni_mb.ini |   1 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 109 +++-
 2 files changed, 105 insertions(+), 5 deletions(-)

diff --git a/doc/guides/cryptodevs/features/aesni_mb.ini 
b/doc/guides/cryptodevs/features/aesni_mb.ini
index e4e965c35a..8df5fa2c85 100644
--- a/doc/guides/cryptodevs/features/aesni_mb.ini
+++ b/doc/guides/cryptodevs/features/aesni_mb.ini
@@ -20,6 +20,7 @@ OOP LB  In LB  Out = Y
 CPU crypto = Y
 Symmetric sessionless  = Y
 Non-Byte aligned data  = Y
+Digest encrypted   = Y
 
 ;
 ; Supported crypto algorithms of the 'aesni_mb' crypto driver.
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 9e298023d7..552d1f16b5 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1438,6 +1438,54 @@ set_gcm_job(IMB_MGR *mb_mgr, IMB_JOB *job, const uint8_t 
sgl,
return 0;
 }
 
+/** Check if conditions are met for digest-appended operations */
+static uint8_t *
+aesni_mb_digest_appended_in_src(struct rte_crypto_op *op, IMB_JOB *job,
+   uint32_t oop)
+{
+   unsigned int auth_size, cipher_size;
+   uint8_t *end_cipher;
+   uint8_t *start_cipher;
+
+   if (job->cipher_mode == IMB_CIPHER_NULL)
+   return NULL;
+
+   if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3 ||
+   job->cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN ||
+   job->cipher_mode == IMB_CIPHER_KASUMI_UEA1_BITLEN) {
+   cipher_size = (op->sym->cipher.data.offset >> 3) +
+   (op->sym->cipher.data.length >> 3);
+   } else {
+   cipher_size = (op->sym->cipher.data.offset) +
+   (op->sym->cipher.data.length);
+   }
+   if (job->hash_alg == IMB_AUTH_ZUC_EIA3_BITLEN ||
+   job->hash_alg == IMB_AUTH_SNOW3G_UIA2_BITLEN ||
+   job->hash_alg == IMB_AUTH_KASUMI_UIA1 ||
+   job->hash_alg == IMB_AUTH_ZUC256_EIA3_BITLEN) {
+   auth_size = (op->sym->auth.data.offset >> 3) +
+   (op->sym->auth.data.length >> 3);
+   } else {
+   auth_size = (op->sym->auth.data.offset) +
+   (op->sym->auth.data.length);
+   }
+
+   if (!oop) {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_src, uint8_t *);
+   } else {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_dst, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_dst, uint8_t *);
+   }
+
+   if (start_cipher < op->sym->auth.digest.data &&
+   op->sym->auth.digest.data < end_cipher) {
+   return rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
auth_size);
+   } else {
+   return NULL;
+   }
+}
+
 /**
  * Process a crypto operation and complete a IMB_JOB job structure for
  * submission to the multi buffer library for processing.
@@ -1580,9 +1628,12 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
} else {
if (aead)
job->auth_tag_output = op->sym->aead.digest.data;
-   else
-   job->auth_tag_output = op->sym->auth.digest.data;
-
+   else {
+   job->auth_tag_output = 
aesni_mb_digest_appended_in_src(op, job, oop);
+   if (job->auth_tag_output == NULL) {
+   job->auth_tag_output = 
op->sym->auth.digest.data;
+   }
+   }
if (session->auth.req_digest_len !=
job->auth_tag_output_len_in_bytes) {
job->auth_tag_output =
@@ -1917,6 +1968,7 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
struct aesni_mb_session *sess = NULL;
uint8_t *linear_buf = NULL;
int sgl = 0;
+   uint8_t oop = 0;
uint8_t is_docsis_sec = 0;
 
if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
@@ -1962,8 +2014,54 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
op->sym->auth.digest.data,
sess->auth.req_digest_len,
&op->status);
-   } else
+   } else {
+   if (!op->sym->m_dst || op->sym->m_dst == 
op->sym->m_src) {
+   /* in-place operation */
+   oop = 0;
+  

[PATCH v4 2/2] test/crypto: fix IV in some vectors

[Brian Dooley]

SNOW3G and ZUC algorithms require non-zero length IVs.

Fixes: c6c267a00a92 ("test/crypto: add mixed encypted-digest")
Cc: adamx.dybkow...@intel.com

Signed-off-by: Brian Dooley 
---
 app/test/test_cryptodev_mixed_test_vectors.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_mixed_test_vectors.h 
b/app/test/test_cryptodev_mixed_test_vectors.h
index 161e2d905f..9c4313185e 100644
--- a/app/test/test_cryptodev_mixed_test_vectors.h
+++ b/app/test/test_cryptodev_mixed_test_vectors.h
@@ -478,8 +478,10 @@ struct mixed_cipher_auth_test_data 
auth_aes_cmac_cipher_snow_test_case_1 = {
},
.cipher_iv = {
.data = {
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
-   .len = 0,
+   .len = 16,
},
.cipher = {
.len_bits = 516 << 3,
@@ -917,8 +919,10 @@ struct mixed_cipher_auth_test_data 
auth_aes_cmac_cipher_zuc_test_case_1 = {
},
.cipher_iv = {
.data = {
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
-   .len = 0,
+   .len = 16,
},
.cipher = {
.len_bits = 516 << 3,
-- 
2.25.1

Re: [PATCH 1/2] use abstracted bit count functions

[David Marchand]

On Fri, Aug 25, 2023 at 12:18 PM David Marchand
 wrote:
>
> Now that DPDK provides such bit count functions, make use of them.
>
> This patch was prepared with a "brutal" commandline:
>
> $ old=__builtin_clzll; new=rte_clz64;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
> $ old=__builtin_clz; new=rte_clz32;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
>
> $ old=__builtin_ctzll; new=rte_ctz64;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
> $ old=__builtin_ctz; new=rte_ctz32;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
>
> $ old=__builtin_popcountll; new=rte_popcount64;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
> $ old=__builtin_popcount; new=rte_popcount32;
>   git grep -lw $old :^lib/eal/include/rte_bitops.h |
>   xargs sed -i -e "s#\<$old\>#$new#g"
>
> Then inclusion of rte_bitops.h was added were necessary.
>
> Signed-off-by: David Marchand 

Series applied.


-- 
David Marchand

Re: [PATCH v6 0/8] [v6]drivers/net Add Support mucse N10 Pmd Driver

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> For This patchset just to support the basic chip init work
> and user can just found the eth_dev, but can't control more.
>

Hi Wenbo,

After this patch, driver doesn't implement any of the dev_ops (struct
eth_dev_ops), so I assume it is not functional at all.

But meanwhile patchset has devargs parsing, fw_update, LSC interrupts,
implemented etc.
I think it makes testing/reviewing harder to add more code before basic
device functionality is missing.

What about implementing following main dev_ops and implement a simple
datapath, to have minimum working driver, later add features on top of it:
dev_configure
dev_start
dev_stop
dev_close
dev_infos_get
rx_queue_setup
tx_queue_setup


Also I have comment on putting 'mac_ops' on process_private, I suspect
there is a design problem there, please check details in relevant patch.


Thanks,
Ferruh

> For Now just support 2*10g nic,the chip can support
> 2*10g,4*10g,4*1g,8*1g,8*10g.
> The Feature rx side can support rx-cksum-offload,rss,vlan-filter
> flow_clow,uncast_filter,mcast_filter,1588,Jumbo-frame
> The Feature tx side can supprt tx-cksum-offload,tso,vxlan-tso 
> flow director base on ntuple pattern of tcp/udp/ip/ eth_hdr->type
> for sriov is also support.
> 
> Because of the chip desgin defect, for multiple-port mode
> one pci-bdf will have multiple-port (max can have four ports)
> so this code must be care of one bdf init multiple-port.
> 
> v6:
>   * fixed the doc(rst) format problem advise by Thomas Monjalon
> 
> v5:
>   * fixed the symbol name require by the style documentation
> rx_queue_setup
> v4:
>   * one patch has been forgot to upload :(
> 
> v3:
>   * fixed http://dpdk.org/patch/129830 FreeBSD 13 compile Issue
>   * change iobar type to void suggest by Stephen Hemminger
>   * add KMOD_DEP support for vfio-pci
>   * change run-cmd argument parse check for invalid extra_args
> 
> v2:
>   * fixed MAINTAIN maillist fullname format
>   * fixed driver/net/meson the order issue of new driver to driver list
>   * improve virtual point function usage suggest by Stephen Hemminger
> 
> 
> Wenbo Cao (8):
>   net/rnp: add skeleton
>   net/rnp: add ethdev probe and remove
>   net/rnp: add device init and uninit
>   net/rnp: add mbx basic api feature
>   net/rnp add reset code for Chip Init process
>   net/rnp add port info resource init
>   net/rnp add devargs runtime parsing functions
>   net/rnp handle device interrupts
> 

> 

Re: [PATCH v6 1/8] net/rnp: add skeleton

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> Add Basic PMD library and doc build infrastructure
> Update maintainers file to claim responsibility.
> 
> Signed-off-by: Wenbo Cao 

<...>

> diff --git a/doc/guides/nics/rnp.rst b/doc/guides/nics/rnp.rst
> new file mode 100644
> index 00..0eb8f2d415
> --- /dev/null
> +++ b/doc/guides/nics/rnp.rst
> @@ -0,0 +1,38 @@
> +..  SPADIX-License-Identifier: BSD-3-Clause

s/SPADIX/SPDX/

> +Copyright(c) 2023 Mucse IC Design Ltd.
> +
> +RNP Poll Mode driver
> +
> +
> +The RNP ETHDEV PMD (**librte_net_rnp**) provides poll mode ethdev
> +driver support for the inbuilt network device found in the **Mucse RNP**
> +
> +Prerequisites
> +-
> +More information can be found at `Mucse, Official Website
> +`_.
> +
> +Supported Chipsets and NICs
> +---
> +
> +- MUCSE Ethernet Controller N10 Series for 10GbE or 40GbE (Dual-port)
> +

Can you provide a link for the product, and if there is an English
version it can reach to more people?

> +Limitations or Known issues
> +---
> +
> +Build with ICC is not supported yet.
>

I know this is documented in other PMDs too, but at this stage ICC is
supported with best effort, and I am not sure if anybody testing with
it, so I think it is OK to drop this as limitation.


> +BSD are not supported yet.
>

FreeBSD is not supported.
Also Windows seems not supported, you may document that too.

> +
> +CRC stripping
> +~
> +
> +The RNP Soc family Nic strip the CRC for every packets coming into the

s/Soc/SoC/
s/Nic/NIC/

> +host interface irrespective of the offload configuration.
> +When you want to disable CRC_OFFLOAD the operate will influence the rxCksum 
> offload.
>

I didn't understand the second sentences, from first one I understand
'RTE_ETH_RX_OFFLOAD_KEEP_CRC' is not supported by the PMD, but can you
please clarify more?


> +
> +VLAN Strip/Filter
> +~
> +
> +For VLAN strip/filter, RNP just support vlan is CVLAN(0x8100).If the outvlan 
> type is SVLAN(0X88a8)

s/vlan/VLAN/
Please put space, " ", after '.' in documentation. Same comment for all
document.

> +VLAN filter or strip will not effort for this packet.It will bypass filter 
> to the host default queue,
> +whatever the other filter rule is.
>

VLAN strip/filter doesn't work for double-tag (QinQ), it only works for
single VLAN tag, is this correct? If so can you please update above
sentences to clarify this?

Re: [PATCH v6 2/8] net/rnp: add ethdev probe and remove

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> Add basic PCIe ethdev probe and remove.
> 
> Signed-off-by: Wenbo Cao 
> ---
>  drivers/net/rnp/rnp.h| 13 ++
>  drivers/net/rnp/rnp_ethdev.c | 83 
>  2 files changed, 96 insertions(+)
>  create mode 100644 drivers/net/rnp/rnp.h
> 
> diff --git a/drivers/net/rnp/rnp.h b/drivers/net/rnp/rnp.h
> new file mode 100644
> index 00..76d281cc0a
> --- /dev/null
> +++ b/drivers/net/rnp/rnp.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Mucse IC Design Ltd.
> + */
> +#ifndef __RNP_H__
> +#define __RNP_H__
> +
> +#define PCI_VENDOR_ID_MUCSE  (0x8848)
> +#define RNP_DEV_ID_N10G  (0x1000)
> +
> +struct rnp_eth_port {
> +} __rte_cache_aligned;
> +

Is the struct needs to be cache aligned?

> +#endif /* __RNP_H__ */
> diff --git a/drivers/net/rnp/rnp_ethdev.c b/drivers/net/rnp/rnp_ethdev.c
> index 9ce3c0b497..390f2e7743 100644
> --- a/drivers/net/rnp/rnp_ethdev.c
> +++ b/drivers/net/rnp/rnp_ethdev.c
> @@ -1,3 +1,86 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2023 Mucse IC Design Ltd.
>   */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "rnp.h"
> +
> +static int
> +rnp_eth_dev_init(struct rte_eth_dev *eth_dev)
> +{
> + RTE_SET_USED(eth_dev);
> +
> + return -ENODEV;
> +}
> +
> +static int
> +rnp_eth_dev_uninit(struct rte_eth_dev *eth_dev)
> +{
> + RTE_SET_USED(eth_dev);
> +
> + return -ENODEV;
> +}
> +
> +static int
> +rnp_pci_remove(struct rte_pci_device *pci_dev)
> +{
> + struct rte_eth_dev *eth_dev;
> + int rc;
> +
> + eth_dev = rte_eth_dev_allocated(pci_dev->device.name);
> +
> + if (eth_dev) {
> + /* Cleanup eth dev */
> + rc = rte_eth_dev_pci_generic_remove(pci_dev,
> + rnp_eth_dev_uninit);
> + if (rc)
> + return rc;
> + }
> + /* Nothing to be done for secondary processes */
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> + return 0;
> +

Primary also don't do anything after this stage, I suggest adding this
code when primary & secondary diverges.

> + return 0;
> +}
> +
> +static int
> +rnp_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
> +{
> + int rc;
> +
> + RTE_SET_USED(pci_drv);
> +
> + rc = rte_eth_dev_pci_generic_probe(pci_dev, sizeof(struct rnp_eth_port),
> +rnp_eth_dev_init);
> +
> + /* On error on secondary, recheck if port exists in primary or
> +  * in mid of detach state.
> +  */
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY && rc)
> + if (!rte_eth_dev_allocated(pci_dev->device.name))
> + return 0;

Why this additional secondary check is required?
'rte_eth_dev_pci_generic_probe()' should be dealing with
primary/secondary process case.

drivers use of service cores

[Thomas Monjalon]

Hello,

I think we can improve the developer experience for using service cores
from a driver, like finding or allocating a service core.
We may take some code and ideas from sfc and nfp drivers,
like in these functions:
nfp_map_service()
sfc_mae_counter_service_register()
sfc_get_service_lcore()

If it is not possible to use a service core,
we could default to using a control thread.
So the driver would never fail because of a thread initialization.

What do you think about proposing such a high level API
in order to get more drivers using it?

Re: [PATCH v6 3/8] net/rnp: add device init and uninit

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> Add basic init and uninit function
> 
> Signed-off-by: Wenbo Cao 
> ---
>  drivers/net/rnp/base/rnp_hw.h |  19 
>  drivers/net/rnp/meson.build   |   1 +
>  drivers/net/rnp/rnp.h |  25 +
>  drivers/net/rnp/rnp_ethdev.c  | 196 +-
>  drivers/net/rnp/rnp_logs.h|  34 ++
>  drivers/net/rnp/rnp_osdep.h   |  30 ++
>  6 files changed, 300 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/net/rnp/base/rnp_hw.h
>  create mode 100644 drivers/net/rnp/rnp_logs.h
>  create mode 100644 drivers/net/rnp/rnp_osdep.h
> 

'rnp_osdep.h' not used at all in the patch, can you move it where it is
used?

> diff --git a/drivers/net/rnp/base/rnp_hw.h b/drivers/net/rnp/base/rnp_hw.h
> new file mode 100644
> index 00..d80d23f4b4
> --- /dev/null
> +++ b/drivers/net/rnp/base/rnp_hw.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Mucse IC Design Ltd.
> + */
> +#ifndef __RNP_HW_H__
> +#define __RNP_HW_H__
> +
> +struct rnp_eth_adapter;
> +struct rnp_hw {
> + struct rnp_eth_adapter *back;
> + void *iobar0;
> + uint32_t iobar0_len;
> + void *iobar4;
> + uint32_t iobar4_len;
> +
> + uint16_t device_id;
> + uint16_t vendor_id;
> +} __rte_cache_aligned;
> +

All structs seems alligned to the cache, although it may not hurt, it is
better to align ones that is necessary for performance.

<...>

> +
> +static struct rte_eth_dev *
> +rnp_alloc_eth_port(struct rte_pci_device *primary_pci, char *name)

Why variable name is 'primary_pci', are there different pci device types?

> +{
> + struct rnp_eth_port *port;
> + struct rte_eth_dev *eth_dev;
> +
> + eth_dev = rte_eth_dev_allocate(name);
> + if (!eth_dev) {
> + RNP_PMD_DRV_LOG(ERR, "Could not allocate "
> + "eth_dev for %s\n", name);

Please don't split the log message, instead can do:
RNP_PMD_DRV_LOG(ERR,
"Could not allocate eth_dev for %s\n",
name);

Same for all log messages.

> + return NULL;
> + }
> + port = rte_zmalloc_socket(name,
> + sizeof(*port),
> + RTE_CACHE_LINE_SIZE,
> + primary_pci->device.numa_node);
> + if (!port) {
> + RNP_PMD_DRV_LOG(ERR, "Could not allocate "
> + "rnp_eth_port for %s\n", name);
> + return NULL;

Should 'eth_dev' released here?

> + }
> + eth_dev->data->dev_private = port;
> + eth_dev->process_private = calloc(1, sizeof(struct rnp_share_ops));
> + if (!eth_dev->process_private) {
> + RNP_PMD_DRV_LOG(ERR, "Could not calloc "
> + "for Process_priv\n");
> + goto fail_calloc;
> + }
> + return eth_dev;
> +fail_calloc:
> + rte_free(port);
> + rte_eth_dev_release_port(eth_dev);
> +
> + return NULL;
> +}
> +
> +static int
> +rnp_eth_dev_init(struct rte_eth_dev *dev)
> +{
> + struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> + struct rnp_eth_adapter *adapter = NULL;
> + char name[RTE_ETH_NAME_MAX_LEN] = " ";
> + struct rnp_eth_port *port = NULL;
> + struct rte_eth_dev *eth_dev;
> + struct rnp_hw *hw = NULL;
> + int32_t p_id;
> + int ret;
> +
> + PMD_INIT_FUNC_TRACE();
> +
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> + return 0;
> + memset(name, 0, sizeof(name));
> + snprintf(name, sizeof(name), "rnp_adapter_%d", dev->data->port_id);
> + adapter = rte_zmalloc(name, sizeof(struct rnp_eth_adapter), 0);
> + if (!adapter) {
> + RNP_PMD_DRV_LOG(ERR, "zmalloc for adapter failed\n");
> + return -ENOMEM;
> + }
> + hw = &adapter->hw;
> + adapter->pdev = pci_dev;
> + adapter->eth_dev = dev;
> + adapter->num_ports = 1;

This is hardcoded value, so no need the loop below but perhaps it is for
future.

> + hw->back = adapter;
> + hw->iobar4 = pci_dev->mem_resource[RNP_CFG_BAR].addr;
> + hw->iobar0 = pci_dev->mem_resource[RNP_PF_INFO_BAR].addr;
> + hw->iobar4_len = pci_dev->mem_resource[RNP_CFG_BAR].len;
> + hw->iobar0_len = pci_dev->mem_resource[RNP_PF_INFO_BAR].len;
> + hw->device_id = pci_dev->id.device_id;
> + hw->vendor_id = pci_dev->id.vendor_id;
> + hw->device_id = pci_dev->id.device_id;
> + for (p_id = 0; p_id < adapter->num_ports; p_id++) {
> + /* port 0 resource has been allocated When Probe */

Why 'When' & 'Probe' starts with uppercase, similar usage exists many
places, although that is not an issue, just catches eye, can you please
fix them if there is no specific reason.

> + if (!p_id) {
> + eth_dev = dev;
> + } else {
> + snprintf(name, sizeof(name), "%s_%d",
> + adapter->pdev->device.name,
> +   

Re: [PATCH v6 4/8] net/rnp: add mbx basic api feature

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> mbx base code is for communicate with the firmware
> 

I assume mbx is mailbox, can you please use full name in the patch title
and commit log.

How the parties get notified about new messages, is the interrupt
support enabled or polling, can you please elabore the support in the
commit log?

> Signed-off-by: Wenbo Cao 
> Suggested-by: Stephen Hemminger 
> ---
>  drivers/net/rnp/base/rnp_api.c  |  23 ++
>  drivers/net/rnp/base/rnp_api.h  |   7 +
>  drivers/net/rnp/base/rnp_cfg.h  |   7 +
>  drivers/net/rnp/base/rnp_dma_regs.h |  73 
>  drivers/net/rnp/base/rnp_eth_regs.h | 124 +++
>  drivers/net/rnp/base/rnp_hw.h   | 112 +-

Why there is no meson file in base folder?

>  drivers/net/rnp/meson.build |   1 +
>  drivers/net/rnp/rnp.h   |  35 ++
>  drivers/net/rnp/rnp_ethdev.c|  70 +++-
>  drivers/net/rnp/rnp_logs.h  |   9 +
>  drivers/net/rnp/rnp_mbx.c   | 522 
>  drivers/net/rnp/rnp_mbx.h   | 139 
>  drivers/net/rnp/rnp_mbx_fw.c| 271 +++
>  drivers/net/rnp/rnp_mbx_fw.h|  22 ++

Should 'rnp_mbx*' files also go under base folder? I can see they use
some 'u8' like typedef, making me think they are shared between other
platforms, if so base folder suits better.

>  14 files changed, 1412 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/rnp/base/rnp_api.c
>  create mode 100644 drivers/net/rnp/base/rnp_api.h
>  create mode 100644 drivers/net/rnp/base/rnp_cfg.h
>  create mode 100644 drivers/net/rnp/base/rnp_dma_regs.h
>  create mode 100644 drivers/net/rnp/base/rnp_eth_regs.h
>  create mode 100644 drivers/net/rnp/rnp_mbx.c
>  create mode 100644 drivers/net/rnp/rnp_mbx.h
>  create mode 100644 drivers/net/rnp/rnp_mbx_fw.c
>  create mode 100644 drivers/net/rnp/rnp_mbx_fw.h
> 
> diff --git a/drivers/net/rnp/base/rnp_api.c b/drivers/net/rnp/base/rnp_api.c
> new file mode 100644
> index 00..550da6217d
> --- /dev/null
> +++ b/drivers/net/rnp/base/rnp_api.c
> @@ -0,0 +1,23 @@
> +#include "rnp.h"
> +#include "rnp_api.h"
> +
> +int
> +rnp_init_hw(struct rte_eth_dev *dev)
> +{
>

Base code is mostly for works as HAL and you don't need to pass "struct
rte_eth_dev" in this level, but mostly adapte (struct rnp_eth_adapter)
or hw (struct rnp_hw) should be sufficient.

I assume you are passing "struct rte_eth_dev" because "struct
rnp_mac_api" is stored in 'process_private', this part I am not clear.

Why need 'mac_ops' pointers for secondary process?
Primary process should be doing all hw initialization, otherwise both
primary and secondar(y|ies) trying to configure the MAC can cause
unexpected results.

Seconday process is only for datapath, which can access to the queues
and do packet processing.

Needing "mac_ops" in the secondary can be bad design desicion, can you
please double check it?

<...>

> diff --git a/drivers/net/rnp/rnp.h b/drivers/net/rnp/rnp.h
> index cab1b8e85d..6e12885877 100644
> --- a/drivers/net/rnp/rnp.h
> +++ b/drivers/net/rnp/rnp.h
> @@ -3,6 +3,7 @@
>   */
>  #ifndef __RNP_H__
>  #define __RNP_H__
> +#include 
>  
>  #include "base/rnp_hw.h"
>  
> @@ -14,14 +15,17 @@
>  
>  struct rnp_eth_port {
>   struct rnp_eth_adapter *adapt;
> + struct rnp_hw *hw;

adapter already has the 'hw', is there a specific reason not to access
it via 'port->adapt->hw'

>   struct rte_eth_dev *eth_dev;
>  } __rte_cache_aligned;
>  
>  struct rnp_share_ops {
> + const struct rnp_mbx_api *mbx_api;
>  } __rte_cache_aligned;
>  
>  struct rnp_eth_adapter {
>   struct rnp_hw hw;
> + uint16_t max_vfs;
>   struct rte_pci_device *pdev;
>   struct rte_eth_dev *eth_dev; /* primary eth_dev */
>   struct rnp_eth_port *ports[RNP_MAX_PORT_OF_PF];
> @@ -34,5 +38,36 @@ struct rnp_eth_adapter {
>   (((struct rnp_eth_port *)((eth_dev)->data->dev_private)))
>  #define RNP_DEV_TO_ADAPTER(eth_dev) \
>   ((struct rnp_eth_adapter *)(RNP_DEV_TO_PORT(eth_dev)->adapt))
> +#define RNP_DEV_TO_HW(eth_dev) \
> + (&((struct rnp_eth_adapter *)(RNP_DEV_TO_PORT((eth_dev))->adapt))->hw)
> +#define RNP_DEV_PP_PRIV_TO_MBX_OPS(dev) \
> + (((struct rnp_share_ops *)(dev)->process_private)->mbx_api)
> +#define RNP_DEV_TO_MBX_OPS(dev)  RNP_DEV_PP_PRIV_TO_MBX_OPS(dev)
>  
> +static inline void rnp_reg_offset_init(struct rnp_hw *hw)
> +{
> + uint16_t i;
> +
> + if (hw->device_id == RNP_DEV_ID_N10G && hw->mbx.pf_num) {
> + hw->iobar4 = (void *)((uint8_t *)hw->iobar4 + 0x10);
> + hw->msix_base = (void *)((uint8_t *)hw->iobar4 + 0xa4000);
> + hw->msix_base = (void *)((uint8_t *)hw->msix_base + 0x200);
> + } else {
> + hw->msix_base = (void *)((uint8_t *)hw->iobar4 + 0xa4000);
> + }
> + /* === dma status/config== */
> + hw->link_sync = (void *)((uint8_t *)hw->iobar4 + 0x000c);
> + hw->dma_axi_en = (void *)((uint8_t *)hw->iobar4 + 0x001

Re: [PATCH v6 5/8] net/rnp add reset code for Chip Init process

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> we must get the shape info of nic from Firmware for

What is "shape info"?

> reset. so the related codes is first get firmware info
> and then reset the chip
> 

Is there a specific reason to have "Chip Init" start with uppercase, if
not please make all lowercase, also ':' after domain, like "net/rnp:'.

Re: [PATCH v6 7/8] net/rnp add devargs runtime parsing functions

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> add various runtime devargs command line options
> supported by this driver.
> 
> Signed-off-by: Wenbo Cao 

<...>

>  
> +#define RNP_HW_MAC_LOOPBACK_ARG  "hw_loopback"
> +#define RNP_FW_UPDATE"fw_update"
> +#define RNP_RX_FUNC_SELECT   "rx_func_sec"
> +#define RNP_TX_FUNC_SELECT   "tx_func_sec"
> +#define RNP_FW_4X10G_10G_1G_DET  "fw_4x10g_10g_1g_auto_det"
> +#define RNP_FW_FORCE_SPEED_1G"fw_force_1g_speed"
> +

Please document these runtime arguments in the device document.

Also please add 'RTE_PMD_REGISTER_PARAM_STRING()' macros to document
argument for pmdinfogen, please see samples in existing code.

<...>

> +
> +static int
> +rnp_parse_io_select_func(const char *key, const char *value, void 
> *extra_args)
> +{
> + uint8_t select = RNP_IO_FUNC_USE_NONE;
> +
> + RTE_SET_USED(key);
> +
> + if (strcmp(value, "vec") == 0)
> + select = RNP_IO_FUNC_USE_VEC;
> + else if (strcmp(value, "simple") == 0)
> + select = RNP_IO_FUNC_USE_SIMPLE;
> + else if (strcmp(value, "common") == 0)
> + select = RNP_IO_FUNC_USE_COMMON;
> +

There is already an generic eal argument that lets you select between
vector and scalar datapath implementation:
--force-max-simd-bitwidth=

<...>

> +static int rnp_post_handle(struct rnp_eth_adapter *adapter)
> +{
> + bool on = false;
> +
> + if (!adapter->eth_dev)
> + return -ENOMEM;
> + if (adapter->do_fw_update && adapter->fw_path) {
> + rnp_fw_update(adapter);
> + adapter->do_fw_update = 0;

This patch also enables FW upgrade, can you please detail this in the
commit log? Or even you can consider to split this part into separate patch.

Re: [PATCH v4 2/2] dma/cnxk: rewrite DMA fastpath

[Jerin Jacob]

On Thu, Aug 31, 2023 at 11:15 AM  wrote:
>
> From: Pavan Nikhilesh 
>
> Rewrite DMA fastpath to use NEON instructions and reduce number
> of words read from config.
>
> Signed-off-by: Pavan Nikhilesh 

Please fix

### [PATCH] dma/cnxk: use mempool for DMA chunk pool

Warning in drivers/common/cnxk/roc_platform.c:
Using RTE_LOG_REGISTER, prefer RTE_LOG_REGISTER_(DEFAULT|SUFFIX)

Re: [PATCH v2 1/5] ethdev: support setting and querying RSS algorithm

[Ajit Khaparde]

> >> How the algorithms support combinations in rss_hf?
> > I will spend a little more time on this tomorrow.
> > Can you update testpmd also to display the info as a part of show rss.
> >
> Hi, Ajit Khaparde,
>
> Displaying RSS hash algorithms with testpmd is in progress.
> However, there are some opinions on the implementation,
> whether to add commands or display them in existing commands.
>
> way 1: show port 0 rss-hash func
> RSS algorithms:
>   symmetric_toeplitz
Option 1 looks good enough. Thanks

>
> way 2: show port 0 rss-hash
> RSS functions:
>   ipv4  ipv4-frag  ipv4-other  ipv6  ipv6-frag  ipv6-other
> RSS algorithms:
>  symmetric_toeplitz
>
> I hope you can give some comments or suggestions.
>
> Thanks,
> Jie Hai
> >>
> >>


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH v5 1/2] dma/cnxk: use mempool for DMA chunk pool

[pbhagavatula]

From: Pavan Nikhilesh 

Use rte_mempool for DMA chunk pool to allow using mempool cache.
Convert logtype register macro for all cnxk drivers to
RTE_LOG_REGISTER_DEFAULT.

Signed-off-by: Pavan Nikhilesh 
---
Depends-on: 29324

 v5 Changes:
 - Use RTE_LOG_REGISTER_DEFAULT for registering logging.
 v4 Changes:
 - Fix clang build.
 v3 Changes:
 - Fix build.

 drivers/common/cnxk/roc_dpi.c  |  95 +
 drivers/common/cnxk/roc_dpi.h  |  28 +---
 drivers/common/cnxk/roc_dpi_priv.h |   3 -
 drivers/common/cnxk/roc_platform.c |  21 +++---
 drivers/common/cnxk/roc_platform.h |   2 +
 drivers/common/cnxk/version.map|   1 +
 drivers/dma/cnxk/cnxk_dmadev.c | 108 +
 drivers/dma/cnxk/cnxk_dmadev.h |  10 ++-
 8 files changed, 120 insertions(+), 148 deletions(-)

diff --git a/drivers/common/cnxk/roc_dpi.c b/drivers/common/cnxk/roc_dpi.c
index 0e2f803077..9cb479371a 100644
--- a/drivers/common/cnxk/roc_dpi.c
+++ b/drivers/common/cnxk/roc_dpi.c
@@ -1,14 +1,14 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(C) 2021 Marvell.
  */
+
+#include "roc_api.h"
+#include "roc_priv.h"
 #include 
 #include 
 #include 
 #include 

-#include "roc_api.h"
-#include "roc_priv.h"
-
 #define DPI_PF_MBOX_SYSFS_ENTRY "dpi_device_config"

 static inline int
@@ -52,17 +52,12 @@ roc_dpi_disable(struct roc_dpi *dpi)
 }

 int
-roc_dpi_configure(struct roc_dpi *roc_dpi)
+roc_dpi_configure(struct roc_dpi *roc_dpi, uint32_t chunk_sz, uint64_t aura, 
uint64_t chunk_base)
 {
struct plt_pci_device *pci_dev;
-   const struct plt_memzone *dpi_mz;
dpi_mbox_msg_t mbox_msg;
-   struct npa_pool_s pool;
-   struct npa_aura_s aura;
-   int rc, count, buflen;
-   uint64_t aura_handle;
-   plt_iova_t iova;
-   char name[32];
+   uint64_t reg;
+   int rc;

if (!roc_dpi) {
plt_err("roc_dpi is NULL");
@@ -70,80 +65,31 @@ roc_dpi_configure(struct roc_dpi *roc_dpi)
}

pci_dev = roc_dpi->pci_dev;
-   memset(&pool, 0, sizeof(struct npa_pool_s));
-   pool.nat_align = 1;
-
-   memset(&aura, 0, sizeof(aura));
-   rc = roc_npa_pool_create(&aura_handle, DPI_CMD_QUEUE_SIZE,
-DPI_CMD_QUEUE_BUFS, &aura, &pool, 0);
-   if (rc) {
-   plt_err("Failed to create NPA pool, err %d\n", rc);
-   return rc;
-   }
-
-   snprintf(name, sizeof(name), "dpimem%d:%d:%d:%d", pci_dev->addr.domain, 
pci_dev->addr.bus,
-pci_dev->addr.devid, pci_dev->addr.function);
-   buflen = DPI_CMD_QUEUE_SIZE * DPI_CMD_QUEUE_BUFS;
-   dpi_mz = plt_memzone_reserve_aligned(name, buflen, 0, 
DPI_CMD_QUEUE_SIZE);
-   if (dpi_mz == NULL) {
-   plt_err("dpi memzone reserve failed");
-   rc = -ENOMEM;
-   goto err1;
-   }
-
-   roc_dpi->mz = dpi_mz;
-   iova = dpi_mz->iova;
-   for (count = 0; count < DPI_CMD_QUEUE_BUFS; count++) {
-   roc_npa_aura_op_free(aura_handle, 0, iova);
-   iova += DPI_CMD_QUEUE_SIZE;
-   }
-
-   roc_dpi->chunk_base = (void *)roc_npa_aura_op_alloc(aura_handle, 0);
-   if (!roc_dpi->chunk_base) {
-   plt_err("Failed to alloc buffer from NPA aura");
-   rc = -ENOMEM;
-   goto err2;
-   }

-   roc_dpi->chunk_next = (void *)roc_npa_aura_op_alloc(aura_handle, 0);
-   if (!roc_dpi->chunk_next) {
-   plt_err("Failed to alloc buffer from NPA aura");
-   rc = -ENOMEM;
-   goto err2;
-   }
-
-   roc_dpi->aura_handle = aura_handle;
-   /* subtract 2 as they have already been alloc'ed above */
-   roc_dpi->pool_size_m1 = (DPI_CMD_QUEUE_SIZE >> 3) - 2;
+   roc_dpi_disable(roc_dpi);
+   reg = plt_read64(roc_dpi->rbase + DPI_VDMA_SADDR);
+   while (!(reg & BIT_ULL(63)))
+   reg = plt_read64(roc_dpi->rbase + DPI_VDMA_SADDR);

plt_write64(0x0, roc_dpi->rbase + DPI_VDMA_REQQ_CTL);
-   plt_write64(((uint64_t)(roc_dpi->chunk_base) >> 7) << 7,
-   roc_dpi->rbase + DPI_VDMA_SADDR);
+   plt_write64(chunk_base, roc_dpi->rbase + DPI_VDMA_SADDR);
mbox_msg.u[0] = 0;
mbox_msg.u[1] = 0;
/* DPI PF driver expects vfid starts from index 0 */
mbox_msg.s.vfid = roc_dpi->vfid;
mbox_msg.s.cmd = DPI_QUEUE_OPEN;
-   mbox_msg.s.csize = DPI_CMD_QUEUE_SIZE;
-   mbox_msg.s.aura = roc_npa_aura_handle_to_aura(aura_handle);
+   mbox_msg.s.csize = chunk_sz;
+   mbox_msg.s.aura = aura;
mbox_msg.s.sso_pf_func = idev_sso_pffunc_get();
mbox_msg.s.npa_pf_func = idev_npa_pffunc_get();

rc = send_msg_to_pf(&pci_dev->addr, (const char *)&mbox_msg,
sizeof(dpi_mbox_msg_t));
-   if (rc < 0) {
+   if (rc < 0)
plt_err("Failed to send mbox message %d to DPI PF, err %d",
mbox_msg

[PATCH v5 2/2] dma/cnxk: rewrite DMA fastpath

[pbhagavatula]

From: Pavan Nikhilesh 

Rewrite DMA fastpath to use NEON instructions and reduce number
of words read from config.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/dma/cnxk/cnxk_dmadev.c| 454 +++--
 drivers/dma/cnxk/cnxk_dmadev.h|  89 +-
 drivers/dma/cnxk/cnxk_dmadev_fp.c | 455 ++
 drivers/dma/cnxk/meson.build  |   9 +-
 4 files changed, 577 insertions(+), 430 deletions(-)
 create mode 100644 drivers/dma/cnxk/cnxk_dmadev_fp.c

diff --git a/drivers/dma/cnxk/cnxk_dmadev.c b/drivers/dma/cnxk/cnxk_dmadev.c
index 35c2b79156..465290ce7a 100644
--- a/drivers/dma/cnxk/cnxk_dmadev.c
+++ b/drivers/dma/cnxk/cnxk_dmadev.c
@@ -2,19 +2,6 @@
  * Copyright (C) 2021 Marvell International Ltd.
  */
 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #include 
 
 static int cnxk_stats_reset(struct rte_dma_dev *dev, uint16_t vchan);
@@ -166,22 +153,9 @@ cnxk_dmadev_configure(struct rte_dma_dev *dev, const 
struct rte_dma_conf *conf,
return rc;
 }
 
-static int
-cnxk_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t vchan,
-   const struct rte_dma_vchan_conf *conf, uint32_t conf_sz)
+static void
+cn9k_dmadev_setup_hdr(union cnxk_dpi_instr_cmd *header, const struct 
rte_dma_vchan_conf *conf)
 {
-   struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
-   struct cnxk_dpi_conf *dpi_conf = &dpivf->conf[vchan];
-   union dpi_instr_hdr_s *header = &dpi_conf->hdr;
-   uint16_t max_desc;
-   uint32_t size;
-   int i;
-
-   RTE_SET_USED(conf_sz);
-
-   if (dpivf->flag & CNXK_DPI_DEV_START)
-   return 0;
-
header->cn9k.pt = DPI_HDR_PT_ZBW_CA;
 
switch (conf->direction) {
@@ -217,57 +191,11 @@ cnxk_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t 
vchan,
header->cn9k.fport = conf->dst_port.pcie.coreid;
header->cn9k.pvfe = 0;
};
-
-   /* Free up descriptor memory before allocating. */
-   cnxk_dmadev_vchan_free(dpivf, vchan);
-
-   max_desc = conf->nb_desc;
-   if (!rte_is_power_of_2(max_desc))
-   max_desc = rte_align32pow2(max_desc);
-
-   if (max_desc > DPI_MAX_DESC)
-   max_desc = DPI_MAX_DESC;
-
-   size = (max_desc * sizeof(struct cnxk_dpi_compl_s *));
-   dpi_conf->c_desc.compl_ptr = rte_zmalloc(NULL, size, 0);
-
-   if (dpi_conf->c_desc.compl_ptr == NULL) {
-   plt_err("Failed to allocate for comp_data");
-   return -ENOMEM;
-   }
-
-   for (i = 0; i < max_desc; i++) {
-   dpi_conf->c_desc.compl_ptr[i] =
-   rte_zmalloc(NULL, sizeof(struct cnxk_dpi_compl_s), 0);
-   if (!dpi_conf->c_desc.compl_ptr[i]) {
-   plt_err("Failed to allocate for descriptor memory");
-   return -ENOMEM;
-   }
-
-   dpi_conf->c_desc.compl_ptr[i]->cdata = DPI_REQ_CDATA;
-   }
-
-   dpi_conf->c_desc.max_cnt = (max_desc - 1);
-
-   return 0;
 }
 
-static int
-cn10k_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t vchan,
-const struct rte_dma_vchan_conf *conf, uint32_t 
conf_sz)
+static void
+cn10k_dmadev_setup_hdr(union cnxk_dpi_instr_cmd *header, const struct 
rte_dma_vchan_conf *conf)
 {
-   struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
-   struct cnxk_dpi_conf *dpi_conf = &dpivf->conf[vchan];
-   union dpi_instr_hdr_s *header = &dpi_conf->hdr;
-   uint16_t max_desc;
-   uint32_t size;
-   int i;
-
-   RTE_SET_USED(conf_sz);
-
-   if (dpivf->flag & CNXK_DPI_DEV_START)
-   return 0;
-
header->cn10k.pt = DPI_HDR_PT_ZBW_CA;
 
switch (conf->direction) {
@@ -303,6 +231,29 @@ cn10k_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t 
vchan,
header->cn10k.fport = conf->dst_port.pcie.coreid;
header->cn10k.pvfe = 0;
};
+}
+
+static int
+cnxk_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t vchan,
+   const struct rte_dma_vchan_conf *conf, uint32_t conf_sz)
+{
+   struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
+   struct cnxk_dpi_conf *dpi_conf = &dpivf->conf[vchan];
+   union cnxk_dpi_instr_cmd *header;
+   uint16_t max_desc;
+   uint32_t size;
+   int i;
+
+   RTE_SET_USED(conf_sz);
+
+   header = (union cnxk_dpi_instr_cmd *)&dpi_conf->cmd.u;
+   if (dpivf->flag & CNXK_DPI_DEV_START)
+   return 0;
+
+   if (dpivf->is_cn10k)
+   cn10k_dmadev_setup_hdr(header, conf);
+   else
+   cn9k_dmadev_setup_hdr(header, conf);
 
/* Free up descriptor memory before allocating. */
cnxk_dmadev_vchan_free(dpivf, vchan);
@@ -329,6 +280,7 @@ cn10k_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t 
vchan,
plt_err("Fai

[PATCH v5 0/2] Add Digest Encrypted to aesni_mb PMD

[Brian Dooley]

This series adds the Digest Encrypted feature to the AESNI_MB PMD.
It also fixes an issue where IV data in SNOW3G and ZUC algorithms
were incorrect and are required to be non-zero length.

v2:
Fixed CHECKPATCH warning
v3:
Add Digest encrypted support to docs
v4:
add comments and refactor
v5:
Fix checkpatch warnings

Brian Dooley (2):
  crypto/ipsec_mb: add digest encrypted feature
  test/crypto: fix IV in some vectors

 app/test/test_cryptodev_mixed_test_vectors.h |   8 +-
 doc/guides/cryptodevs/features/aesni_mb.ini  |   1 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c   | 107 ++-
 3 files changed, 109 insertions(+), 7 deletions(-)

-- 
2.25.1

[PATCH v5 1/2] crypto/ipsec_mb: add digest encrypted feature

[Brian Dooley]

AESNI_MB PMD does not support Digest Encrypted. This patch adds a check and
support for this feature.

Signed-off-by: Brian Dooley 
---
v2:
Fixed CHECKPATCH warning
v3:
Add Digest encrypted support to docs
v4:
Add comments and small refactor
v5:
Fix checkpatch warnings
---
 doc/guides/cryptodevs/features/aesni_mb.ini |   1 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 109 +++-
 2 files changed, 105 insertions(+), 5 deletions(-)

diff --git a/doc/guides/cryptodevs/features/aesni_mb.ini 
b/doc/guides/cryptodevs/features/aesni_mb.ini
index e4e965c35a..8df5fa2c85 100644
--- a/doc/guides/cryptodevs/features/aesni_mb.ini
+++ b/doc/guides/cryptodevs/features/aesni_mb.ini
@@ -20,6 +20,7 @@ OOP LB  In LB  Out = Y
 CPU crypto = Y
 Symmetric sessionless  = Y
 Non-Byte aligned data  = Y
+Digest encrypted   = Y
 
 ;
 ; Supported crypto algorithms of the 'aesni_mb' crypto driver.
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 9e298023d7..7f61065939 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1438,6 +1438,54 @@ set_gcm_job(IMB_MGR *mb_mgr, IMB_JOB *job, const uint8_t 
sgl,
return 0;
 }
 
+/** Check if conditions are met for digest-appended operations */
+static uint8_t *
+aesni_mb_digest_appended_in_src(struct rte_crypto_op *op, IMB_JOB *job,
+   uint32_t oop)
+{
+   unsigned int auth_size, cipher_size;
+   uint8_t *end_cipher;
+   uint8_t *start_cipher;
+
+   if (job->cipher_mode == IMB_CIPHER_NULL)
+   return NULL;
+
+   if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3 ||
+   job->cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN ||
+   job->cipher_mode == IMB_CIPHER_KASUMI_UEA1_BITLEN) {
+   cipher_size = (op->sym->cipher.data.offset >> 3) +
+   (op->sym->cipher.data.length >> 3);
+   } else {
+   cipher_size = (op->sym->cipher.data.offset) +
+   (op->sym->cipher.data.length);
+   }
+   if (job->hash_alg == IMB_AUTH_ZUC_EIA3_BITLEN ||
+   job->hash_alg == IMB_AUTH_SNOW3G_UIA2_BITLEN ||
+   job->hash_alg == IMB_AUTH_KASUMI_UIA1 ||
+   job->hash_alg == IMB_AUTH_ZUC256_EIA3_BITLEN) {
+   auth_size = (op->sym->auth.data.offset >> 3) +
+   (op->sym->auth.data.length >> 3);
+   } else {
+   auth_size = (op->sym->auth.data.offset) +
+   (op->sym->auth.data.length);
+   }
+
+   if (!oop) {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_src, uint8_t *);
+   } else {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_dst, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_dst, uint8_t *);
+   }
+
+   if (start_cipher < op->sym->auth.digest.data &&
+   op->sym->auth.digest.data < end_cipher) {
+   return rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
auth_size);
+   } else {
+   return NULL;
+   }
+}
+
 /**
  * Process a crypto operation and complete a IMB_JOB job structure for
  * submission to the multi buffer library for processing.
@@ -1580,9 +1628,12 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
} else {
if (aead)
job->auth_tag_output = op->sym->aead.digest.data;
-   else
-   job->auth_tag_output = op->sym->auth.digest.data;
-
+   else {
+   job->auth_tag_output = 
aesni_mb_digest_appended_in_src(op, job, oop);
+   if (job->auth_tag_output == NULL) {
+   job->auth_tag_output = 
op->sym->auth.digest.data;
+   }
+   }
if (session->auth.req_digest_len !=
job->auth_tag_output_len_in_bytes) {
job->auth_tag_output =
@@ -1917,6 +1968,7 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
struct aesni_mb_session *sess = NULL;
uint8_t *linear_buf = NULL;
int sgl = 0;
+   uint8_t oop = 0;
uint8_t is_docsis_sec = 0;
 
if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
@@ -1962,8 +2014,54 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
op->sym->auth.digest.data,
sess->auth.req_digest_len,
&op->status);
-   } else
+   } else {
+   if (!op->sym->m_dst || op->sym->m_dst == 
op->sym->m_src) {
+   /* in-place operation */
+ 

[PATCH v5 2/2] test/crypto: fix IV in some vectors

[Brian Dooley]

SNOW3G and ZUC algorithms require non-zero length IVs.

Fixes: c6c267a00a92 ("test/crypto: add mixed encypted-digest")
Cc: adamx.dybkow...@intel.com

Signed-off-by: Brian Dooley 
---
 app/test/test_cryptodev_mixed_test_vectors.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_mixed_test_vectors.h 
b/app/test/test_cryptodev_mixed_test_vectors.h
index 161e2d905f..9c4313185e 100644
--- a/app/test/test_cryptodev_mixed_test_vectors.h
+++ b/app/test/test_cryptodev_mixed_test_vectors.h
@@ -478,8 +478,10 @@ struct mixed_cipher_auth_test_data 
auth_aes_cmac_cipher_snow_test_case_1 = {
},
.cipher_iv = {
.data = {
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
-   .len = 0,
+   .len = 16,
},
.cipher = {
.len_bits = 516 << 3,
@@ -917,8 +919,10 @@ struct mixed_cipher_auth_test_data 
auth_aes_cmac_cipher_zuc_test_case_1 = {
},
.cipher_iv = {
.data = {
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
-   .len = 0,
+   .len = 16,
},
.cipher = {
.len_bits = 516 << 3,
-- 
2.25.1

RE: [PATCH 3/5] app/proc-info: fix never show RSS info

[Pattan, Reshma]

> -Original Message-
> + uint8_t *rss_key;

Instead of pointer can you just take key of type below, so u no need to do 
dynamic memory allocation using malloc and free .
 
Ex: uint8_t hash_key[RSS_HASH_KEY_LENGTH];

And then do below ?
rss_conf.rss_key = hash_key;

[PATCH 2/3] event/cnxk: remove checks from op release

[pbhagavatula]

From: Pavan Nikhilesh 

Remove expensive fastpath checks from op release, remove
explicit release in CN9K tx routine.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/cnxk/cn9k_worker.h | 17 -
 drivers/event/cnxk/cnxk_worker.h |  6 --
 2 files changed, 23 deletions(-)

diff --git a/drivers/event/cnxk/cn9k_worker.h b/drivers/event/cnxk/cn9k_worker.h
index 9ddab095ac..ee659e80d6 100644
--- a/drivers/event/cnxk/cn9k_worker.h
+++ b/drivers/event/cnxk/cn9k_worker.h
@@ -156,15 +156,6 @@ cn9k_sso_hws_dual_forward_event(struct cn9k_sso_hws_dual 
*dws, uint64_t base,
}
 }
 
-static __rte_always_inline void
-cn9k_sso_tx_tag_flush(uint64_t base)
-{
-   if (unlikely(CNXK_TT_FROM_TAG(plt_read64(base + SSOW_LF_GWS_TAG)) ==
-SSO_TT_EMPTY))
-   return;
-   plt_write64(0, base + SSOW_LF_GWS_OP_SWTAG_FLUSH);
-}
-
 static __rte_always_inline void
 cn9k_wqe_to_mbuf(uint64_t wqe, const uint64_t mbuf, uint8_t port_id,
 const uint32_t tag, const uint32_t flags,
@@ -727,7 +718,6 @@ cn9k_sso_hws_event_tx(uint64_t base, struct rte_event *ev, 
uint64_t *cmd,
  uint64_t *txq_data, const uint32_t flags)
 {
struct rte_mbuf *m = ev->mbuf;
-   uint16_t ref_cnt = m->refcnt;
struct cn9k_eth_txq *txq;
 
/* Perform header writes before barrier for TSO */
@@ -800,13 +790,6 @@ cn9k_sso_hws_event_tx(uint64_t base, struct rte_event *ev, 
uint64_t *cmd,
}
 
 done:
-   if (flags & NIX_TX_OFFLOAD_MBUF_NOFF_F) {
-   if (ref_cnt > 1)
-   return 1;
-   }
-
-   cn9k_sso_tx_tag_flush(base);
-
return 1;
 }
 
diff --git a/drivers/event/cnxk/cnxk_worker.h b/drivers/event/cnxk/cnxk_worker.h
index 2bd41f8a5e..0e0d728ba4 100644
--- a/drivers/event/cnxk/cnxk_worker.h
+++ b/drivers/event/cnxk/cnxk_worker.h
@@ -54,12 +54,6 @@ cnxk_sso_hws_swtag_untag(uintptr_t swtag_untag_op)
 static __rte_always_inline void
 cnxk_sso_hws_swtag_flush(uint64_t base)
 {
-   /* Ensure that there is no previous flush is pending. */
-   while (plt_read64(base + SSOW_LF_GWS_PENDSTATE) & BIT_ULL(56))
-   ;
-   if (CNXK_TT_FROM_TAG(plt_read64(base + SSOW_LF_GWS_TAG)) ==
-   SSO_TT_EMPTY)
-   return;
plt_write64(0, base + SSOW_LF_GWS_OP_SWTAG_FLUSH);
 }
 
-- 
2.41.0

[PATCH 1/3] cnxk/event: invalidate GWC on port reset

[pbhagavatula]

From: Pavan Nikhilesh 

Invalidate GWC on event port i.e., HWS reset to prevent
invalid response from SSO.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/common/cnxk/roc_sso.c   | 31 +
 drivers/common/cnxk/roc_sso.h   |  2 ++
 drivers/common/cnxk/version.map |  1 +
 drivers/event/cnxk/cn10k_eventdev.c | 19 +-
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_sso.c b/drivers/common/cnxk/roc_sso.c
index a5f48d5bbc..1ea0761531 100644
--- a/drivers/common/cnxk/roc_sso.c
+++ b/drivers/common/cnxk/roc_sso.c
@@ -357,6 +357,37 @@ roc_sso_hws_stats_get(struct roc_sso *roc_sso, uint8_t hws,
return rc;
 }
 
+void
+roc_sso_hws_gwc_invalidate(struct roc_sso *roc_sso, uint8_t *hws,
+  uint8_t nb_hws)
+{
+   struct sso *sso = roc_sso_to_sso_priv(roc_sso);
+   struct ssow_lf_inv_req *req;
+   struct dev *dev = &sso->dev;
+   struct mbox *mbox;
+   int i;
+
+   if (!nb_hws)
+   return;
+
+   mbox = mbox_get(dev->mbox);
+   req = mbox_alloc_msg_sso_ws_cache_inv(mbox);
+   if (req == NULL) {
+   mbox_process(mbox);
+   req = mbox_alloc_msg_sso_ws_cache_inv(mbox);
+   if (req == NULL) {
+   mbox_put(mbox);
+   return;
+   }
+   }
+   req->hdr.ver = SSOW_INVAL_SELECTIVE_VER;
+   req->nb_hws = nb_hws;
+   for (i = 0; i < nb_hws; i++)
+   req->hws[i] = hws[i];
+   mbox_process(mbox);
+   mbox_put(mbox);
+}
+
 int
 roc_sso_hwgrp_stats_get(struct roc_sso *roc_sso, uint8_t hwgrp,
struct roc_sso_hwgrp_stats *stats)
diff --git a/drivers/common/cnxk/roc_sso.h b/drivers/common/cnxk/roc_sso.h
index a2bb6fcb22..8ee62afb9a 100644
--- a/drivers/common/cnxk/roc_sso.h
+++ b/drivers/common/cnxk/roc_sso.h
@@ -100,6 +100,8 @@ int __roc_api roc_sso_hwgrp_free_xaq_aura(struct roc_sso 
*roc_sso,
 int __roc_api roc_sso_hwgrp_stash_config(struct roc_sso *roc_sso,
 struct roc_sso_hwgrp_stash *stash,
 uint16_t nb_stash);
+void __roc_api roc_sso_hws_gwc_invalidate(struct roc_sso *roc_sso, uint8_t 
*hws,
+ uint8_t nb_hws);
 
 /* Debug */
 void __roc_api roc_sso_dump(struct roc_sso *roc_sso, uint8_t nb_hws,
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index 8c71497df8..cfb7efbdc7 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/version.map
@@ -475,6 +475,7 @@ INTERNAL {
roc_sso_hws_base_get;
roc_sso_hws_link;
roc_sso_hws_stats_get;
+   roc_sso_hws_gwc_invalidate;
roc_sso_hws_unlink;
roc_sso_ns_to_gw;
roc_sso_rsrc_fini;
diff --git a/drivers/event/cnxk/cn10k_eventdev.c 
b/drivers/event/cnxk/cn10k_eventdev.c
index 499a3aace7..56482c20a1 100644
--- a/drivers/event/cnxk/cn10k_eventdev.c
+++ b/drivers/event/cnxk/cn10k_eventdev.c
@@ -118,6 +118,7 @@ static int
 cn10k_sso_hws_flush_events(void *hws, uint8_t queue_id, uintptr_t base,
   cnxk_handle_event_t fn, void *arg)
 {
+   struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(arg);
uint64_t retry = CNXK_SSO_FLUSH_RETRY_MAX;
struct cn10k_sso_hws *ws = hws;
uint64_t cq_ds_cnt = 1;
@@ -128,6 +129,7 @@ cn10k_sso_hws_flush_events(void *hws, uint8_t queue_id, 
uintptr_t base,
 
plt_write64(0, base + SSO_LF_GGRP_QCTL);
 
+   roc_sso_hws_gwc_invalidate(&dev->sso, &ws->hws_id, 1);
plt_write64(0, ws->base + SSOW_LF_GWS_OP_GWC_INVAL);
req = queue_id; /* GGRP ID */
req |= BIT_ULL(18); /* Grouped */
@@ -162,6 +164,7 @@ cn10k_sso_hws_flush_events(void *hws, uint8_t queue_id, 
uintptr_t base,
return -EAGAIN;
 
plt_write64(0, ws->base + SSOW_LF_GWS_OP_GWC_INVAL);
+   roc_sso_hws_gwc_invalidate(&dev->sso, &ws->hws_id, 1);
rte_mb();
 
return 0;
@@ -181,6 +184,7 @@ cn10k_sso_hws_reset(void *arg, void *hws)
uint8_t pend_tt;
bool is_pend;
 
+   roc_sso_hws_gwc_invalidate(&dev->sso, &ws->hws_id, 1);
plt_write64(0, ws->base + SSOW_LF_GWS_OP_GWC_INVAL);
/* Wait till getwork/swtp/waitw/desched completes. */
is_pend = false;
@@ -237,6 +241,7 @@ cn10k_sso_hws_reset(void *arg, void *hws)
}
 
plt_write64(0, base + SSOW_LF_GWS_OP_GWC_INVAL);
+   roc_sso_hws_gwc_invalidate(&dev->sso, &ws->hws_id, 1);
rte_mb();
 }
 
@@ -670,7 +675,9 @@ cn10k_sso_configure_queue_stash(struct rte_eventdev 
*event_dev)
 static int
 cn10k_sso_start(struct rte_eventdev *event_dev)
 {
-   int rc;
+   struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
+   uint8_t hws[RTE_EVENT_MAX_PORTS_PER_DEV];
+   int rc, i;
 
rc = cn10k_sso_updt_tx_adptr_data(event_dev);
if (rc < 0)
@@ -682,6 +689,9 @

[PATCH 3/3] common/cnxk: use local labels in asm intrinsic

[pbhagavatula]

From: Pavan Nikhilesh 

Using labels in asm generates them as regular function and shades
callstack in tools like gdb or perf.
Use local label instead for better visibility.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/common/cnxk/roc_sso_dp.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/common/cnxk/roc_sso_dp.h b/drivers/common/cnxk/roc_sso_dp.h
index 9d30286d2f..03c5bdf7ee 100644
--- a/drivers/common/cnxk/roc_sso_dp.h
+++ b/drivers/common/cnxk/roc_sso_dp.h
@@ -13,13 +13,13 @@ roc_sso_hws_head_wait(uintptr_t base)
 
 #if defined(__aarch64__)
asm volatile(PLT_CPU_FEATURE_PREAMBLE
-"  ldr %[tag], [%[tag_op]] \n"
-"  tbnz %[tag], 35, done%= \n"
+"  ldr %[tag], [%[tag_op]] \n"
+"  tbnz %[tag], 35, .Ldone%=   \n"
 "  sevl\n"
-"rty%=:wfe \n"
-"  ldr %[tag], [%[tag_op]] \n"
-"  tbz %[tag], 35, rty%=   \n"
-"done%=:   \n"
+".Lrty%=:  wfe \n"
+"  ldr %[tag], [%[tag_op]] \n"
+"  tbz %[tag], 35, .Lrty%= \n"
+".Ldone%=: \n"
 : [tag] "=&r"(tag)
 : [tag_op] "r"(tag_op));
 #else
-- 
2.41.0

Re: [PATCH v6 6/8] net/rnp add port info resource init

[Ferruh Yigit]

On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> Add Api For FW Mac Info, Port Resoucre info init Code
> For Different Shape Of Nic
> 
> Signed-off-by: Wenbo Cao 

<...>

> @@ -47,11 +104,53 @@ rnp_init_port_resource(struct rnp_eth_adapter *adapter,
>  uint8_t p_id)
>  {
>   struct rnp_eth_port *port = RNP_DEV_TO_PORT(dev);
> + struct rte_pci_device *pci_dev = adapter->pdev;
> + struct rnp_hw *hw = &adapter->hw;
>  
> + port->adapt = adapter;
> + port->s_mode = adapter->s_mode;
> + port->port_stopped = 1;
> + port->hw = hw;
>   port->eth_dev = dev;
> - adapter->ports[p_id] = port;
> +
> + dev->device = &pci_dev->device;
> + rte_eth_copy_pci_info(dev, pci_dev);
>   dev->dev_ops = &rnp_eth_dev_ops;
> - RTE_SET_USED(name);
> + dev->rx_queue_count   = rnp_dev_rx_queue_count;
> + dev->rx_descriptor_status = rnp_dev_rx_descriptor_status;
> + dev->tx_descriptor_status = rnp_dev_tx_descriptor_status;
> + dev->rx_pkt_burst = rnp_recv_pkts;
> + dev->tx_pkt_burst = rnp_xmit_pkts;
> + dev->tx_pkt_prepare = rnp_prep_pkts;
> +
> + rnp_setup_port_attr(port, dev, adapter->num_ports, p_id);
> + rnp_init_filter_setup(port, adapter->num_ports);
> + rnp_get_mac_addr(dev, port->mac_addr);
> + dev->data->mac_addrs = rte_zmalloc(name, sizeof(struct rte_ether_addr) *
> + port->attr.max_mac_addrs, 0);
> + if (!dev->data->mac_addrs) {
> + RNP_PMD_DRV_LOG(ERR, "Memory allocation "
> + "for MAC failed! Exiting.\n");
> + return -ENOMEM;
> + }
> + /* Allocate memory for storing hash filter MAC addresses */
> + dev->data->hash_mac_addrs = rte_zmalloc(name,
> + RTE_ETHER_ADDR_LEN * port->attr.max_uc_mac_hash, 0);
> + if (dev->data->hash_mac_addrs == NULL) {
> + RNP_PMD_INIT_LOG(ERR, "Failed to allocate %d bytes "
> + "needed to store MAC addresses",
> + RTE_ETHER_ADDR_LEN * 
> port->attr.max_uc_mac_hash);
> + return -ENOMEM;

Should free 'dev->data->mac_addrs' here, or even better can be to
implement 'rnp_dev_close()' to free device resources.


> + }
> +
> + rnp_set_default_mac(dev, port->mac_addr);

I guess the 'port->mac_addr' got from device via 'rnp_get_mac_addr()'
above, but if 'rnp_get_mac_addr()' fails what will be the value. Should
there be check and set a random mac if required?

> + rte_ether_addr_copy((const struct rte_ether_addr *)port->mac_addr,
> + dev->data->mac_addrs);
> + /* MTU */
> + dev->data->mtu = RTE_ETHER_MAX_LEN -
> + RTE_ETHER_HDR_LEN - RTE_ETHER_CRC_LEN;
> + adapter->ports[p_id] = port;
> + rte_eth_dev_probing_finish(dev);
>  

rte_eth_dev_probing_finish() is not required, as
'rte_eth_dev_pci_generic_probe()' calls it if dev_init() returns success.

<...>

> +static int32_t rnp_get_mac_addr_pf(struct rnp_eth_port *port,
> +uint8_t lane,
> +uint8_t *macaddr)
> +{
> + struct rnp_hw *hw = RNP_DEV_TO_HW(port->eth_dev);
> +
> + return rnp_fw_get_macaddr(port->eth_dev, hw->pf_vf_num, macaddr, lane);
> +}
> +

These are mac_ops functions, normally the reason to have mac_ops is to
support different HW that behaves slightly different and this difference
managed by different function pointers per device. Is this your usecase?

And since these are mac_ops, defined in the base folder header, it suits
better to have separate .c file for them which is under base file, what
do you think? Or am I getting these mac_ops wrong?

> +static int32_t
> +rnp_set_default_mac_pf(struct rnp_eth_port *port,
> +uint8_t *mac)
> +{
> + struct rnp_eth_adapter *adap = RNP_PORT_TO_ADAPTER(port);
> + uint16_t max_vfs;
> +
> + if (port->s_mode == RNP_SHARE_INDEPENDENT)
> + return rnp_set_rafb(port->eth_dev, (uint8_t *)mac,
> + UINT8_MAX, 0);
> +
> + max_vfs = adap->max_vfs;
> +
> + return rnp_set_rafb(port->eth_dev, mac, max_vfs, 0);
> +}
> +
>  const struct rnp_mac_api rnp_mac_ops = {
>   .reset_hw   = rnp_reset_hw_pf,
> - .init_hw= rnp_init_hw_pf
> + .init_hw= rnp_init_hw_pf,
> + .get_mac_addr   = rnp_get_mac_addr_pf,
> + .set_default_mac = rnp_set_default_mac_pf,
> + .set_rafb   = rnp_set_mac_addr_pf,
> + .clear_rafb = rnp_clear_mac_addr_pf
>  };
>  
>  static void
> @@ -228,7 +434,11 @@ rnp_common_ops_init(struct rnp_eth_adapter *adapter)
>  static int
>  rnp_special_ops_init(struct rte_eth_dev *eth_dev)
>  {
> - RTE_SET_USED(eth_dev);
> + struct rnp_eth_adapter *adapter = RNP_DEV_TO_ADAPTER(eth_dev);
> + struct rnp_share_ops *share_priv;
> +
> + share_priv = adapter->share_priv;
> + share_priv->mac_api = &rnp_mac_ops;
>  

Can you please describe why this 'rnp_spec

RE: [PATCH 5/5] app/proc-info: support querying RSS hash algorithm

[Pattan, Reshma]

> -Original Message-
> From: Jie Hai 
> 
> +static const char *
> +rss_func_to_str(enum rte_eth_hash_function func) {
> + switch (func) {
> + case RTE_ETH_HASH_FUNCTION_SIMPLE_XOR:
> + return "simple_xor";
> + case RTE_ETH_HASH_FUNCTION_TOEPLITZ:
> + return "toeplitz";
> + case RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ:
> + return "symmetric_toeplitz";
> + case RTE_ETH_HASH_FUNCTION_DEFAULT:
> + return "default";
> + default:
> + return "unknown";
> + }
> +}
> +


Instead of above function you can declare const array of strings as below to 
map hash function names.

static const char * const hf_names[] = {
[RTE_ETH_HASH_FUNCTION_SIMPLE_XOR] = " simple_xor ",
[RTE_ETH_HASH_FUNCTION_TOEPLITZ] = " toeplitz ",
[RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ] = " symmetric_toeplitz ",
[RTE_ETH_HASH_FUNCTION_DEFAULT] = "default"
};


> + printf("\t  -- hash algorithm : %s\n",
> + rss_func_to_str(rss_conf.func));
>   }
> 

And then print  as below ?
printf("\t  -- hash algorithm : %s\n", hf_names [rss_conf.func]);

RE: [PATCH v2 0/5] bbdev: API extension for 23.11

[Chautru, Nicolas]

Hi Maxime, Hemant, 

Can we please get some extra review/ack for this bbdev serie. I would be good 
to apply on the baseband repo soon towards 23.11. 
Much appreciated!
Nic

> -Original Message-
> From: Vargas, Hernan 
> Sent: Friday, August 4, 2023 9:14 AM
> To: Chautru, Nicolas ; dev@dpdk.org;
> maxime.coque...@redhat.com
> Cc: Rix, Tom ; hemant.agra...@nxp.com;
> david.march...@redhat.com
> Subject: RE: [PATCH v2 0/5] bbdev: API extension for 23.11
> 
> Hi Maxime,
> 
> Kind reminder to get a review on this series:
> https://patchwork.dpdk.org/project/dpdk/list/?series=28544
> 
> Thanks,
> Hernan
> 
> > -Original Message-
> > From: Chautru, Nicolas 
> > Sent: Monday, July 17, 2023 5:29 PM
> > To: dev@dpdk.org; maxime.coque...@redhat.com
> > Cc: Rix, Tom ; hemant.agra...@nxp.com;
> > david.march...@redhat.com; Vargas, Hernan
> 
> > Subject: RE: [PATCH v2 0/5] bbdev: API extension for 23.11
> >
> > Hi Maxime, Hemant,
> > Can I get some review/ack for this serie please.
> > Thanks
> > Nic
> >
> > > -Original Message-
> > > From: Chautru, Nicolas 
> > > Sent: Thursday, June 15, 2023 9:49 AM
> > > To: dev@dpdk.org; maxime.coque...@redhat.com
> > > Cc: Rix, Tom ; hemant.agra...@nxp.com;
> > > david.march...@redhat.com; Vargas, Hernan
> ;
> > > Chautru, Nicolas 
> > > Subject: [PATCH v2 0/5] bbdev: API extension for 23.11
> > >
> > > v2: moving the new mld functions at the end of struct rte_bbdev to
> > > avoid ABI offset changes based on feedback with Maxime.
> > > Adding a commit to waive the FFT ABI warning since that experimental
> > > function could break ABI (let me know if preferred to be merged with
> > > the FFT commit causing the FFT change).
> > >
> > >
> > > Including v1 for extending the bbdev api for 23.11.
> > > The new MLD-TS is expected to be non ABI compatible, the other ones
> > > should not break ABI.
> > > I will send a deprecation notice in parallel.
> > >
> > > This introduces a new operation (on top of FEC and FFT) to support
> > > equalization for MLD-TS. There also more modular API extension for
> > > existing FFT and FEC operation.
> > >
> > > Thanks
> > > Nic
> > >
> > >
> > > Nicolas Chautru (5):
> > >   bbdev: add operation type for MLDTS procession
> > >   bbdev: add new capabilities for FFT processing
> > >   bbdev: add new capability for FEC 5G UL processing
> > >   bbdev: improving error handling for queue configuration
> > >   devtools: ignore changes into bbdev experimental API
> > >
> > >  devtools/libabigail.abignore|   4 +-
> > >  doc/guides/prog_guide/bbdev.rst |  83 ++
> > >  lib/bbdev/rte_bbdev.c   |  26 +++---
> > >  lib/bbdev/rte_bbdev.h   |  76 +
> > >  lib/bbdev/rte_bbdev_op.h| 143
> > > +++-
> > >  lib/bbdev/version.map   |   5 ++
> > >  6 files changed, 323 insertions(+), 14 deletions(-)
> > >
> > > --
> > > 2.34.1

Reminder - New Link! - DPDK Techboard Meeting - tomorrow, Wed. Sep. 6, 2023 @ 8am Pacific/11am Eastern/1500h UTC

[Nathan Southern]

Good evening,

This is a reminder that the DPDK Tech Board meets tomorrow and is using a
new meeting management tool. We will be using LFX Zoom, not Jitsi.

Below  are the instructions and corresponding link.

I will reiterate that you do *not *need to go through the process of
registering for an LF ID and password. Per the attached screenshot, you can
go to the community join link and just put in your name and email.

As always we'll use framapad for an agenda. Here is a read-only link:

https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db



I'll be at the old jitsi link to redirect anyone who does not receive this.

See you tomorrow.

Thanks,

Nathan

Ways to join meeting: 1. Join from PC, Mac, iPad, or Android
https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb

2. Join via audio One tap mobile: US: +12532158782,,96459488340# or
+13462487799,,96459488340 Or dial: US: +1 253 215 8782 or +1 346 248 7799
or +1 669 900 6833 or +1 301 715 8592 or +1 312 626 6799 or +1 646 374 8656
or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free) Canada: +1 647 374
4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272 7920 or +1 438 809
7799 or +1 587 328 1099 or 855 703 8985 (Toll Free) Meeting ID: 96459488340
Meeting Passcode: 699526 International numbers: https://zoom.us/u/alwnPIaVT

[PATCH] hash: fix SSE comparison

[Jieqiang Wang]

__mm_cmpeq_epi16 returns 0x if the corresponding 16-bit elements are
equal. In original SSE2 implementation for function compare_signatures,
it utilizes _mm_movemask_epi8 to create mask from the MSB of each 8-bit
element, while we should only care about the MSB of lower 8-bit in each
16-bit element.
For example, if the comparison result is all equal, SSE2 path returns
0x while NEON and default scalar path return 0x.
Although this bug is not causing any negative effects since the caller
function solely examines the trailing zeros of each match mask, we
recommend this fix to ensure consistency with NEON and default scalar
code behaviors.

Fixes: c7d93df552c2 ("hash: use partial-key hashing")
Cc: yipeng1.w...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Feifei Wang 
Signed-off-by: Jieqiang Wang 
Reviewed-by: Ruifeng Wang 
---
 lib/hash/rte_cuckoo_hash.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index d92a903bb3..acaa8b74bd 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -1862,17 +1862,19 @@ compare_signatures(uint32_t *prim_hash_matches, 
uint32_t *sec_hash_matches,
/* For match mask the first bit of every two bits indicates the match */
switch (sig_cmp_fn) {
 #if defined(__SSE2__)
-   case RTE_HASH_COMPARE_SSE:
+   case RTE_HASH_COMPARE_SSE: {
/* Compare all signatures in the bucket */
-   *prim_hash_matches = _mm_movemask_epi8(_mm_cmpeq_epi16(
-   _mm_load_si128(
+   __m128i shift_mask = _mm_set1_epi16(0x0080);
+   __m128i prim_cmp = _mm_cmpeq_epi16(_mm_load_si128(
(__m128i const *)prim_bkt->sig_current),
-   _mm_set1_epi16(sig)));
+   _mm_set1_epi16(sig));
+   *prim_hash_matches = _mm_movemask_epi8(_mm_and_si128(prim_cmp, 
shift_mask));
/* Compare all signatures in the bucket */
-   *sec_hash_matches = _mm_movemask_epi8(_mm_cmpeq_epi16(
-   _mm_load_si128(
+   __m128i sec_cmp = _mm_cmpeq_epi16(_mm_load_si128(
(__m128i const *)sec_bkt->sig_current),
-   _mm_set1_epi16(sig)));
+   _mm_set1_epi16(sig));
+   *sec_hash_matches = _mm_movemask_epi8(_mm_and_si128(sec_cmp, 
shift_mask));
+   }
break;
 #elif defined(__ARM_NEON)
case RTE_HASH_COMPARE_NEON: {
-- 
2.25.1

RE: [PATCH v2 09/12] net/cpfl: update vport info before creating representor

[Liu, Mingxia]

> -Original Message-
> From: Xing, Beilei 
> Sent: Wednesday, August 16, 2023 11:06 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
> 
> Subject: [PATCH v2 09/12] net/cpfl: update vport info before creating 
> representor
> 
> From: Beilei Xing 
> 
> Get port representor's vport list and update vport_map_hash before creating 
> the
> port representor.
> 
> Signed-off-by: Beilei Xing 
> ---
>  drivers/net/cpfl/cpfl_ethdev.c  |   2 +-
>  drivers/net/cpfl/cpfl_ethdev.h  |   3 +
>  drivers/net/cpfl/cpfl_representor.c | 124 
>  3 files changed, 128 insertions(+), 1 deletion(-)

>  int
>  cpfl_repr_create(struct rte_pci_device *pci_dev, struct cpfl_adapter_ext
> *adapter)  { @@ -375,8 +455,14 @@ cpfl_repr_create(struct rte_pci_device
> *pci_dev, struct cpfl_adapter_ext *adapte
>   uint32_t iter = 0;
>   const struct cpfl_repr_id *repr_id;
>   const struct cpfl_vport_id *vp_id;
> + struct cpchnl2_get_vport_list_response *vlist_resp;
> + struct cpchnl2_get_vport_info_response vinfo_resp;
>   int ret;
> 
> + vlist_resp = rte_zmalloc(NULL, IDPF_DFLT_MBX_BUF_SIZE, 0);
> + if (vlist_resp == NULL)
> + return -ENOMEM;
> +
>   rte_spinlock_lock(&adapter->repr_lock);
> 
>   while (rte_hash_iterate(adapter->repr_allowlist_hash,
> @@ -385,6 +471,7 @@ cpfl_repr_create(struct rte_pci_device *pci_dev, struct
> cpfl_adapter_ext *adapte
>   char name[RTE_ETH_NAME_MAX_LEN];
>   uint32_t iter_iter = 0;
>   bool matched;
> + int i;
> 
>   /* skip representor already be created */
>   if (dev != NULL)
> @@ -402,6 +489,41 @@ cpfl_repr_create(struct rte_pci_device *pci_dev, struct
> cpfl_adapter_ext *adapte
>repr_id->host_id,
>repr_id->pf_id);
> 
> + /* get vport list for the port representor */
> + ret = cpfl_repr_vport_list_query(adapter, repr_id, vlist_resp);
> + if (ret != 0) {
> + PMD_INIT_LOG(ERR, "Failed to get host%d pf%d vf%d's
> vport list",
> +  repr_id->host_id, repr_id->pf_id, repr_id-
> >vf_id);
> + rte_spinlock_unlock(&adapter->repr_lock);
> + rte_free(vlist_resp);
> + return ret;
> + }
> +
> + /* get all vport info for the port representor */
> + for (i = 0; i < vlist_resp->nof_vports; i++) {
> + ret = cpfl_repr_vport_info_query(adapter, repr_id,
> +  &vlist_resp->vports[i],
> &vinfo_resp);
> + if (ret != 0) {
> + PMD_INIT_LOG(ERR, "Failed to get host%d
> pf%d vf%d vport[%d]'s info",
> +  repr_id->host_id, repr_id->pf_id,
> repr_id->vf_id,
> +  vlist_resp->vports[i].vport_id);
> + rte_spinlock_unlock(&adapter->repr_lock);
> + rte_free(vlist_resp);
> + return ret;
> + }
> +
> + ret = cpfl_repr_vport_map_update(adapter, repr_id,
> +  vlist_resp->vports[i].vport_id,
> &vinfo_resp);
> + if (ret != 0) {
> + PMD_INIT_LOG(ERR, "Failed to update  host%d
> pf%d vf%d vport[%d]'s info to vport_map_hash",
> +  repr_id->host_id, repr_id->pf_id,
> repr_id->vf_id,
> +  vlist_resp->vports[i].vport_id);
> + rte_spinlock_unlock(&adapter->repr_lock);
> + rte_free(vlist_resp);
> + return ret;
> + }
> + }
> +
>   /* find a matched vport */
>   rte_spinlock_lock(&adapter->vport_map_lock);
> 
> @@ -428,6 +550,7 @@ cpfl_repr_create(struct rte_pci_device *pci_dev, struct
> cpfl_adapter_ext *adapte
>   PMD_INIT_LOG(ERR, "Failed to create
> representor %s", name);
>   rte_spinlock_unlock(&adapter-
> >vport_map_lock);
>   rte_spinlock_unlock(&adapter->repr_lock);
> + rte_free(vlist_resp);
>   return ret;
>   }
>   break;
> @@ -443,6 +566,7 @@ cpfl_repr_create(struct rte_pci_device *pci_dev, struct
> cpfl_adapter_ext *adapte
>   }
> 
>   rte_spinlock_unlock(&adapter->repr_lock);
> + rte_free(vlist_resp);
> 
[Liu, Mingxia] There are several exit point that do the common clean work
rte_spinlock_unlock(&adapter->repr_lock);
rte_free(vlist_resp);

RE: [PATCH v2 12/12] net/cpfl: support Rx/Tx queue setup for representor

[Liu, Mingxia]

> -Original Message-
> From: Xing, Beilei 
> Sent: Wednesday, August 16, 2023 11:06 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
> 
> Subject: [PATCH v2 12/12] net/cpfl: support Rx/Tx queue setup for representor
> 
> From: Beilei Xing 
> 
> Add dummy Rx/Tx queue setup functions for representor.
> 
> Signed-off-by: Jingjing Wu 
> Signed-off-by: Beilei Xing 
> ---
>  drivers/net/cpfl/cpfl_representor.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/net/cpfl/cpfl_representor.c
> b/drivers/net/cpfl/cpfl_representor.c
> index 5b5c959727..58e0d91d97 100644
> --- a/drivers/net/cpfl/cpfl_representor.c
> +++ b/drivers/net/cpfl/cpfl_representor.c
> @@ -285,6 +285,29 @@ cpfl_repr_dev_stop(struct rte_eth_dev *dev)
>   return 0;
>  }
> 
> +static int
> +idpf_repr_rx_queue_setup(__rte_unused struct rte_eth_dev *dev,
> +  __rte_unused uint16_t queue_id,
> +  __rte_unused uint16_t nb_desc,
> +  __rte_unused unsigned int socket_id,
> +  __rte_unused const struct rte_eth_rxconf *conf,
> +  __rte_unused struct rte_mempool *pool) {
> + /* Dummy */
> + return 0;
> +}
> +
> +static int
> +idpf_repr_tx_queue_setup(__rte_unused struct rte_eth_dev *dev,
> +  __rte_unused uint16_t queue_id,
> +  __rte_unused uint16_t nb_desc,
> +  __rte_unused unsigned int socket_id,
> +  __rte_unused const struct rte_eth_txconf *conf) {
> + /* Dummy */
> + return 0;
> +}
> +
>  static int
>  cpfl_repr_link_update(struct rte_eth_dev *ethdev,
> __rte_unused int wait_to_complete) @@ -309,6 +332,9 @@
> static const struct eth_dev_ops cpfl_repr_dev_ops = {
>   .dev_close  = cpfl_repr_dev_close,
>   .dev_infos_get  = cpfl_repr_dev_info_get,
> 
> + .rx_queue_setup = idpf_repr_rx_queue_setup,
> + .tx_queue_setup = idpf_repr_tx_queue_setup,
> +
[Liu, Mingxia] How about using function name cpfl_repr_xxx() ?

>   .link_update= cpfl_repr_link_update,
>  };
> 
> --
> 2.34.1

RE: [PATCH v2] net/ice: fix tm configuration cannot be cleared

[Zhang, Qi Z]

> -Original Message-
> From: Deng, KaiwenX 
> Sent: Tuesday, September 5, 2023 3:35 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
> ; Deng, KaiwenX ;
> Zhang, Qi Z ; Xu, Ting 
> Subject: [PATCH v2] net/ice: fix tm configuration cannot be cleared
> 
> When the device is stopped, DPDK resets the commit flag so that we can

This is not a DPDK general implementation, its all about the ice PMD, please 
use "the PMD" to replace the "DPDK".

RE: [PATCH] net/iavf: unregister intr handler before FD close

[Zhang, Qi Z]

> -Original Message-
> From: Saurabh Singhal 
> Sent: Monday, September 4, 2023 9:01 PM
> To: Thomas Monjalon ; Wu, Jingjing
> ; Xing, Beilei 
> Cc: dev@dpdk.org; Singhal, Saurabh 
> Subject: [PATCH] net/iavf: unregister intr handler before FD close
> 
> Unregister VFIO interrupt handler before the interrupt fd gets closed in case
> iavf_dev_init() returns an error.
> 
> dpdk creates a standalone thread named eal-intr-thread for processing
> interrupts for the PCI devices. The interrupt handler callbacks are registered
> by the VF driver(iavf, in this case).
> 
> When we do a PCI probe of the network interfaces, we register an interrupt
> handler, open a vfio-device fd using ioctl, and an eventfd in dpdk. These
> interrupt sources are registered in a global linked list that the 
> eal-intr-thread
> keeps iterating over for handling the interrupts. In our internal testing, we 
> see
> eal-intr-thread crash in these two ways:
> 
> Error adding fd 660 epoll_ctl, Operation not permitted
> 
> or
> 
> Error adding fd 660 epoll_ctl, Bad file descriptor
> 
> epoll_ctl() returns EPERM if the target fd does not support poll.
> It returns EBADF when the epoll fd itself is closed or the target fd is 
> closed.
> 
> When the first type of crash happens, we see that the fd 660 is
> anon_inode:[vfio-device] which does not support poll.
> 
> When the second type of crash happens, we could see from the fd map of
> the crashing process that the fd 660 was already closed.
> 
> This means the said fd has been closed and in certain cases may have been
> reassigned to a different device by the operating system but the eal-intr-
> thread does not know about it.
> 
> We observed that these crashes were always accompanied by an error in
> iavf_dev_init() after rte_intr_callback_register() and
> iavf_enable_irq0() have already happened. In the error path, the
> intr_handle_fd was being closed but the interrupt handler wasn't being
> unregistered.
> 
> The fix is to unregister the interrupt handle in the
> iavf_dev_init() error path.

Thanks for all these explanations!

> 
> Signed-off-by: Saurabh Singhal 
> ---
>  .mailmap   |  1 +
>  drivers/net/iavf/iavf_ethdev.c | 15 +++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/.mailmap b/.mailmap
> index 864d33ee46..4dac53011b 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -1227,6 +1227,7 @@ Satananda Burla   Satha Rao
>Satheesh
> Paul   Sathesh Edara 
> +Saurabh Singhal 
>  Savinay Dharmappa   Scott Branden
>   Scott Daniels 
> diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
> index f2fc5a5621..df87a553db 100644
> --- a/drivers/net/iavf/iavf_ethdev.c
> +++ b/drivers/net/iavf/iavf_ethdev.c
> @@ -133,6 +133,8 @@ static int iavf_dev_rx_queue_intr_enable(struct
> rte_eth_dev *dev,
>   uint16_t queue_id);
>  static int iavf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,
>uint16_t queue_id);
> +static void iavf_dev_interrupt_handler(void *param); static inline void
> +iavf_disable_irq0(struct iavf_hw *hw);
>  static int iavf_dev_flow_ops_get(struct rte_eth_dev *dev,
>const struct rte_flow_ops **ops);
>  static int iavf_set_mc_addr_list(struct rte_eth_dev *dev, @@ -2490,9
> +2492,22 @@ iavf_uninit_vf(struct rte_eth_dev *dev)  {
>   struct iavf_hw *hw = IAVF_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
>   struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data-
> >dev_private);
> + struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> + struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
> 
>   iavf_shutdown_adminq(hw);
> 
> + if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_WB_ON_ITR) {
> + /* disable uio intr before callback unregiser */
> + rte_intr_disable(intr_handle);
> +
> + /* unregister callback func from eal lib */
> + rte_intr_callback_unregister(intr_handle,
> +  iavf_dev_interrupt_handler, dev);
> + } else {
> + rte_eal_alarm_cancel(iavf_dev_alarm_handler, dev);
> + }
> +

I assume the error handling should follow the reversed order.

So, can we move above code right after the goto label "flow_init_err", like 
below?



iavf_enable_irq0(hw);

ret = iavf_flow_init(adapter);
if (ret) {
PMD_INIT_LOG(ERR, "Failed to initialize flow");
goto flow_init_err;
}

...

flow_init_err:

iavf_disable_irq0(hw)

if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_WB_ON_ITR) {
...
}

Btw, I saw missing error handling in iavf_ipsec_crypto_supported branch which 
should be fixed, if you are hesitating to apply above fix because this 
inconsistent, please ignore this.

Thanks
Qi


>   rte_free(vf->vf_res);
>   vf->vsi_res = NULL;
>   vf->vf_res = NULL;
> --
> 2.41.0

Re: [PATCH v2 5/5] devtools: ignore changes into bbdev experimental API

[Hemant Agrawal]

On 15-Jun-23 10:19 PM, Nicolas Chautru wrote:

Caution: This is an external email. Please take care when clicking links or 
opening attachments. When in doubt, report the message using the 'Report this 
email' button


Developpers are warned that the related fft experimental functions
do not preserve ABI, hence these can be waived.

%s/Developpers/Developers


Signed-off-by: Nicolas Chautru 
---
  devtools/libabigail.abignore | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..09b8f156b5 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -30,7 +30,9 @@
  [suppress_type]
  type_kind = enum
  changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, 
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
-
+; Ignore changes to bbdev FFT API which is experimental
+[suppress_type]
+name = rte_bbdev_fft_op
  
  ; Temporary exceptions till next major ABI version ;
  
--
2.34.1

Re: [PATCH v2 0/5] bbdev: API extension for 23.11

[Hemant Agrawal]

Hi Nic,

    One small comment in the commit message.

Acked-by: Hemant Agrawal 

Regards

Hemant

On 15-Jun-23 10:18 PM, Nicolas Chautru wrote:

Caution: This is an external email. Please take care when clicking links or 
opening attachments. When in doubt, report the message using the 'Report this 
email' button


v2: moving the new mld functions at the end of struct rte_bbdev to avoid
ABI offset changes based on feedback with Maxime.
Adding a commit to waive the FFT ABI warning since that experimental function
could break ABI (let me know if preferred to be merged with the FFT
commit causing the FFT change).


Including v1 for extending the bbdev api for 23.11.
The new MLD-TS is expected to be non ABI compatible, the other ones
should not break ABI.
I will send a deprecation notice in parallel.

This introduces a new operation (on top of FEC and FFT) to support
equalization for MLD-TS. There also more modular API extension for
existing FFT and FEC operation.

Thanks
Nic


Nicolas Chautru (5):
   bbdev: add operation type for MLDTS procession
   bbdev: add new capabilities for FFT processing
   bbdev: add new capability for FEC 5G UL processing
   bbdev: improving error handling for queue configuration
   devtools: ignore changes into bbdev experimental API

  devtools/libabigail.abignore|   4 +-
  doc/guides/prog_guide/bbdev.rst |  83 ++
  lib/bbdev/rte_bbdev.c   |  26 +++---
  lib/bbdev/rte_bbdev.h   |  76 +
  lib/bbdev/rte_bbdev_op.h| 143 +++-
  lib/bbdev/version.map   |   5 ++
  6 files changed, 323 insertions(+), 14 deletions(-)

--
2.34.1