Re: [PATCH 1/1] net/cnxk: make inline inbound device usage default

[Jerin Jacob]

On Fri, Feb 25, 2022 at 12:24 PM Vamsi Attunuru  wrote:
>
> Currently inline inbound device usage is not default for eventdev,
> patch renames force_inl_dev dev arg to no_inl_dev and enables inline
> inbound device by default.
>
> Signed-off-by: Vamsi Attunuru 

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


> ---
>  doc/guides/nics/cnxk.rst | 10 +-
>  drivers/event/cnxk/cnxk_eventdev_adptr.c |  4 ++--
>  drivers/net/cnxk/cn9k_ethdev.c   |  1 +
>  drivers/net/cnxk/cnxk_ethdev.h   |  4 ++--
>  drivers/net/cnxk/cnxk_ethdev_devargs.c   | 11 +--
>  5 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst
> index be51ca2146..31c801fa04 100644
> --- a/doc/guides/nics/cnxk.rst
> +++ b/doc/guides/nics/cnxk.rst
> @@ -275,7 +275,7 @@ Runtime Config Options
> With the above configuration, two CPT LF's are setup and distributed among
> all the Tx queues for outbound processing.
>
> -- ``Force using inline ipsec device for inbound`` (default ``0``)
> +- ``Disable using inline ipsec device for inbound`` (default ``0``)
>
> In CN10K, in event mode, driver can work in two modes,
>
> @@ -285,13 +285,13 @@ Runtime Config Options
> 2. Both Inbound encrypted traffic and plain traffic post decryption are
>received by ethdev.
>
> -   By default event mode works without using inline device i.e mode ``2``.
> -   This behaviour can be changed to pick mode ``1`` by using
> -   ``force_inb_inl_dev`` ``devargs`` parameter.
> +   By default event mode works using inline device i.e mode ``1``.
> +   This behaviour can be changed to pick mode ``2`` by using
> +   ``no_inl_dev`` ``devargs`` parameter.
>
> For example::
>
> -  -a 0002:02:00.0,force_inb_inl_dev=1 -a 0002:03:00.0,force_inb_inl_dev=1
> +  -a 0002:02:00.0,no_inl_dev=1 -a 0002:03:00.0,no_inl_dev=1
>
> With the above configuration, inbound encrypted traffic from both the 
> ports
> is received by ipsec inline device.
> diff --git a/drivers/event/cnxk/cnxk_eventdev_adptr.c 
> b/drivers/event/cnxk/cnxk_eventdev_adptr.c
> index 5ebd3340e7..42ac14064d 100644
> --- a/drivers/event/cnxk/cnxk_eventdev_adptr.c
> +++ b/drivers/event/cnxk/cnxk_eventdev_adptr.c
> @@ -263,9 +263,9 @@ cnxk_sso_rx_adapter_queue_add(
>
> /* Switch to use PF/VF's NIX LF instead of inline device for inbound
>  * when all the RQ's are switched to event dev mode. We do this only
> -* when using inline device is not forced by dev args.
> +* when dev arg no_inl_dev=1 is selected.
>  */
> -   if (!cnxk_eth_dev->inb.force_inl_dev &&
> +   if (cnxk_eth_dev->inb.no_inl_dev &&
> cnxk_eth_dev->nb_rxq_sso == cnxk_eth_dev->nb_rxq)
> cnxk_nix_inb_mode_set(cnxk_eth_dev, false);
>
> diff --git a/drivers/net/cnxk/cn9k_ethdev.c b/drivers/net/cnxk/cn9k_ethdev.c
> index 6b049b2897..ae42d76d6d 100644
> --- a/drivers/net/cnxk/cn9k_ethdev.c
> +++ b/drivers/net/cnxk/cn9k_ethdev.c
> @@ -594,6 +594,7 @@ cn9k_nix_probe(struct rte_pci_driver *pci_drv, struct 
> rte_pci_device *pci_dev)
> }
>
> dev->hwcap = 0;
> +   dev->inb.no_inl_dev = 1;
>
> /* Register up msg callbacks for PTP information */
> roc_nix_ptp_info_cb_register(&dev->nix, cn9k_nix_ptp_info_update_cb);
> diff --git a/drivers/net/cnxk/cnxk_ethdev.h b/drivers/net/cnxk/cnxk_ethdev.h
> index 445b7abf69..9a9d3baf25 100644
> --- a/drivers/net/cnxk/cnxk_ethdev.h
> +++ b/drivers/net/cnxk/cnxk_ethdev.h
> @@ -272,8 +272,8 @@ struct cnxk_eth_dev_sec_inb {
> /* Using inbound with inline device */
> bool inl_dev;
>
> -   /* Device argument to force inline device for inb */
> -   bool force_inl_dev;
> +   /* Device argument to disable inline device usage for inb */
> +   bool no_inl_dev;
>
> /* Active sessions */
> uint16_t nb_sess;
> diff --git a/drivers/net/cnxk/cnxk_ethdev_devargs.c 
> b/drivers/net/cnxk/cnxk_ethdev_devargs.c
> index 8a71644899..9b2beb6743 100644
> --- a/drivers/net/cnxk/cnxk_ethdev_devargs.c
> +++ b/drivers/net/cnxk/cnxk_ethdev_devargs.c
> @@ -241,7 +241,7 @@ parse_sdp_channel_mask(const char *key, const char 
> *value, void *extra_args)
>  #define CNXK_IPSEC_IN_MAX_SPI  "ipsec_in_max_spi"
>  #define CNXK_IPSEC_OUT_MAX_SA  "ipsec_out_max_sa"
>  #define CNXK_OUTB_NB_DESC  "outb_nb_desc"
> -#define CNXK_FORCE_INB_INL_DEV "force_inb_inl_dev"
> +#define CNXK_NO_INL_DEV"no_inl_dev"
>  #define CNXK_OUTB_NB_CRYPTO_QS "outb_nb_crypto_qs"
>  #define CNXK_SDP_CHANNEL_MASK  "sdp_channel_mask"
>  #define CNXK_FLOW_PRE_L2_INFO  "flow_pre_l2_info"
> @@ -257,7 +257,6 @@ cnxk_ethdev_parse_devargs(struct rte_devargs *devargs, 
> struct cnxk_eth_dev *dev)
> uint16_t flow_prealloc_size = 1;
> uint16_t switch_header_type = 0;
> uint16_t flow_max_priority = 3;
> -   uint16_t force_inb_inl_dev = 0;
> 

[PATCH v3 1/2] test/efd: fix size of constant

[Pablo de Lara]

Constant value 1 has a size of 32 bits, and shifting it more than 32 bits
to the left overflows. 1ULL is needed to be able to get a 64-bit value.

Coverity ID: 375846
Fixes: 8751a7e9832b ("efd: allow more CPU sockets in table creation")
Cc: pablo.de.lara.gua...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Pablo de Lara 
Acked-by: Yipeng Wang 
---
 app/test/test_efd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_efd.c b/app/test/test_efd.c
index 7bea674086..fa29e8f97a 100644
--- a/app/test/test_efd.c
+++ b/app/test/test_efd.c
@@ -107,7 +107,7 @@ static inline uint64_t efd_get_all_sockets_bitmask(void)
unsigned int next_lcore = rte_get_main_lcore();
const int val_true = 1, val_false = 0;
for (i = 0; i < rte_lcore_count(); i++) {
-   all_cpu_sockets_bitmask |= 1 << 
rte_lcore_to_socket_id(next_lcore);
+   all_cpu_sockets_bitmask |= 1ULL << 
rte_lcore_to_socket_id(next_lcore);
next_lcore = rte_get_next_lcore(next_lcore, val_false, 
val_true);
}
 
-- 
2.25.1

[PATCH v3 2/2] efd: fix uninitialized structure

[Pablo de Lara]

Coverity flags that both elements of efd_online_group_entry
are used uninitialized. This is OK because this structure
is initially used for starting values, so any value is OK.

Coverity ID: 375868
Fixes: 56b6ef874f80 ("efd: new Elastic Flow Distributor library")
Cc: pablo.de.lara.gua...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Pablo de Lara 
Acked-by: Yipeng Wang 
---

-v3: Fixed RHEL build
-v2: Fixed typo in commit message 

---
 lib/efd/rte_efd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efd/rte_efd.c b/lib/efd/rte_efd.c
index 560cd78961..bbc6fc585d 100644
--- a/lib/efd/rte_efd.c
+++ b/lib/efd/rte_efd.c
@@ -1162,7 +1162,7 @@ rte_efd_update(struct rte_efd_table * const table, const 
unsigned int socket_id,
 {
uint32_t chunk_id = 0, group_id = 0, bin_id = 0;
uint8_t new_bin_choice = 0;
-   struct efd_online_group_entry entry;
+   struct efd_online_group_entry entry = {{0}};
 
int status = efd_compute_update(table, socket_id, key, value,
&chunk_id, &group_id, &bin_id,
-- 
2.25.1

RE: [PATCH v3] app/pdump: check lcore is not the maximum core

[Pattan, Reshma]

> -Original Message-
> From: Pattan, Reshma 



Hi Stephen,

Can you take a look and ack the patch.

Thanks,
Reshma

Re: [PATCH] common/cnxk: support B0 variant

[Ferruh Yigit]

On 2/24/2022 8:35 PM, Jerin Jacob wrote:

On Thu, Feb 24, 2022 at 4:13 PM Tomasz Duszynski  wrote:


Add B0 variant to the list of supported models.

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob Kollanukkaran 


Updated the git commit as follows and applied to
dpdk-next-net-mrvl/for-next-net. Thanks

 common/cnxk: support CNF95xx B0 variant

 Add CNF95xx B0 variant to the list of supported models.

 Signed-off-by: Tomasz Duszynski 
 Reviewed-by: Jerin Jacob 



  drivers/common/cnxk/roc_model.c | 1 +
  drivers/common/cnxk/roc_model.h | 6 --
  2 files changed, 5 insertions(+), 2 deletions(-)


Hi Jerin, Tomasz,

Can you please update release note to document this new
device support? (Although it is still B0, some users may be
interested in with the new device support.)

RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym crypto routine

[Ji, Kai]

The warning messages are deprecated APIs warnings from openssl , not compiler 
warnings from gcc, the integrity of DPDK remain the same.
Alongside openssl pmd, the ccp and qat pmd also raise the same type of warnings 
once openssl 3.0 installed. 

In the current intel roadmap,  we will try to support 3.0 API fully for openssl 
and qat pmds by the end of year, so this patch is the first step.
I think the warning messages are safe to stay, Unfortunately the fix ccp pmd 
driver is out of our reach. 

Regards

Kai 
 

> -Original Message-
> From: Akhil Goyal 
> Sent: Friday, February 25, 2022 3:56 AM
> To: Ji, Kai ; dev@dpdk.org
> Cc: Zhang, Roy Fan 
> Subject: RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym
> crypto routine
> 
> Hi Kai,
> > Hi Akhil,
> >
> > This patch was intend to support Openssl 3.0 on symmetric crypto
> > algorithms only, where the deprecated APIs, compile warnings and
> > failing test cases were fixed.
> > All the asymmetric crypto related issues stay untreated and will be
> > fixed in the next patch.
> >
> How can one verify if the driver is openssl 3.0 compliant?
> Is there a way to bypass those warnings?
> We cannot have build with warnings or we can have something in meson.build to
> bypass those for openssl pmd.

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

[Ferruh Yigit]

On 2/25/2022 12:01 AM, Michael Baum wrote:


On 2/23/2022 11:48 PM, Ferruh Yigit wrote:

On 2/23/2022 1:48 PM, Michael Baum wrote:

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

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

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

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

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


Hi Michael,

This is not a document patch to update the parameter name, patch actually
changes the parameter name in the code and documents it, updating it as:
net/mlx5: update doorbell mapping parameter name


Hi Ferruh,

Your argument makes sense to me, but most of updates was in MLX5 common library 
so I think it is better to write:
common/mlx5: update doorbell mapping parameter name


ack, updated accordingly.

Re: [dpdk-dev] [PATCH v5] net/ice: fix function pointer in multi-process

[Navin Srinivas]

Hi Qi,
Thank you for your reply and confirmation.

Regards,
Navin Srinivas

On Fri, Feb 25, 2022 at 7:04 AM Zhang, Qi Z  wrote:

> We need a separate fix for AVF which is ongoing.
>
> And DPDK 20.11.4 LTS by default will only backport all the fix that during
> DPDK 21.11 dev cycle, so you may need to wait for 20.11.5 or just cherry
> pick by yourself.
>
>
>
> Regards
>
> Qi
>
>
>
>
>
> *From:* Navin Srinivas 
> *Sent:* Friday, February 25, 2022 2:00 AM
> *To:* Zhang, Qi Z 
> *Cc:* Yu, DapengX ; Yang, Qiming <
> qiming.y...@intel.com>; dev@dpdk.org; Wang, Haiyue ;
> sta...@dpdk.org
> *Subject:* Re: [dpdk-dev] [PATCH v5] net/ice: fix function pointer in
> multi-process
>
>
>
> Hi,
>
>
>
> Whether this fix is applicable for VF? I do not see this change ported to
> VF in DPDK-20.11.4.
>
>
>
> Thanks,
>
> Navin Srinivas
>
>
>
> On Wed, Oct 27, 2021 at 8:58 AM Zhang, Qi Z  wrote:
>
>
>
> > -Original Message-
> > From: Yu, DapengX 
> > Sent: Tuesday, October 26, 2021 9:56 AM
> > To: Yang, Qiming ; Zhang, Qi Z
> > 
> > Cc: dev@dpdk.org; Wang, Haiyue ; Yu, DapengX
> > ; sta...@dpdk.org
> > Subject: [PATCH v5] net/ice: fix function pointer in multi-process
> >
> > From: Dapeng Yu 
> >
> > This patch uses the index value to call the function, instead of the
> function
> > pointer assignment to save the selection of Receive Flex Descriptor
> profile ID.
> >
> > Otherwise the secondary process will run with wrong function address from
> > primary process.
> >
> > Fixes: 7a340b0b4e03 ("net/ice: refactor Rx FlexiMD handling")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Dapeng Yu 
> > Acked-by: Haiyue Wang 
>
> Applied to dpdk-next-net-intel.
>
> Thanks
> Qi
>
>

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

[Navin Srinivas]

Thanks, I noticed it in the release and took the LTS version.
I do not see the previously noticed VF crash now on 20.11.4

Navin

On Tue, Feb 22, 2022 at 2:51 PM Kevin Traynor  wrote:

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

[dpdk-dev] [PATCH v2] common/cnxk: support CNF95xx B0 variant

[Tomasz Duszynski]

Add CNF95xx B0 variant to the list of supported models.

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob 
---
v2:
- Update release notes for new device support (Ferruh)

 doc/guides/rel_notes/release_22_03.rst | 1 +
 drivers/common/cnxk/roc_model.c| 1 +
 drivers/common/cnxk/roc_model.h| 6 --
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 54563106d1..43c4db65c3 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -135,6 +135,7 @@ New Features
   * Added queue based priority flow control support for CN9K & CN10K.
   * Added support for IP reassembly for inline inbound IPsec packets.
   * Added support for packet marking in traffic manager.
+  * Added support for CNF95xx B0 variant SoC.

 * **Added an API for private user data in asymmetric crypto session.**

diff --git a/drivers/common/cnxk/roc_model.c b/drivers/common/cnxk/roc_model.c
index 49617c02b7..4120029541 100644
--- a/drivers/common/cnxk/roc_model.c
+++ b/drivers/common/cnxk/roc_model.c
@@ -56,6 +56,7 @@ static const struct model_db {
{VENDOR_CAVIUM, PART_95xx, 1, 0, ROC_MODEL_CNF95xx_B0, "cnf95xx_b0"},
{VENDOR_CAVIUM, PART_95xxN, 0, 0, ROC_MODEL_CNF95xxN_A0, "cnf95xxn_a0"},
{VENDOR_CAVIUM, PART_95xxN, 0, 1, ROC_MODEL_CNF95xxN_A0, "cnf95xxn_a1"},
+   {VENDOR_CAVIUM, PART_95xxN, 1, 0, ROC_MODEL_CNF95xxN_B0, "cnf95xxn_b0"},
{VENDOR_CAVIUM, PART_95O, 0, 0, ROC_MODEL_CNF95xxO_A0, "cnf95O_a0"},
{VENDOR_CAVIUM, PART_95xxMM, 0, 0, ROC_MODEL_CNF95xxMM_A0,
 "cnf95xxmm_a0"}};
diff --git a/drivers/common/cnxk/roc_model.h b/drivers/common/cnxk/roc_model.h
index cee06779bc..4567566169 100644
--- a/drivers/common/cnxk/roc_model.h
+++ b/drivers/common/cnxk/roc_model.h
@@ -19,6 +19,7 @@ struct roc_model {
 #define ROC_MODEL_CNF95xxN_A0  BIT_ULL(12)
 #define ROC_MODEL_CNF95xxO_A0  BIT_ULL(13)
 #define ROC_MODEL_CNF95xxN_A1  BIT_ULL(14)
+#define ROC_MODEL_CNF95xxN_B0  BIT_ULL(15)
 #define ROC_MODEL_CN98xx_A0BIT_ULL(16)
 #define ROC_MODEL_CN106xx_A0   BIT_ULL(20)
 #define ROC_MODEL_CNF105xx_A0  BIT_ULL(21)
@@ -39,11 +40,12 @@ struct roc_model {
(ROC_MODEL_CN96xx_Ax | ROC_MODEL_CN96xx_C0 | ROC_MODEL_CNF95xx_A0 |\
 ROC_MODEL_CNF95xx_B0 | ROC_MODEL_CNF95xxMM_A0 |   \
 ROC_MODEL_CNF95xxO_A0 | ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CN98xx_A0 | \
-ROC_MODEL_CNF95xxN_A1)
+ROC_MODEL_CNF95xxN_A1 | ROC_MODEL_CNF95xxN_B0)
 #define ROC_MODEL_CNF9K
\
(ROC_MODEL_CNF95xx_A0 | ROC_MODEL_CNF95xx_B0 | \
 ROC_MODEL_CNF95xxMM_A0 | ROC_MODEL_CNF95xxO_A0 |  \
-ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CNF95xxN_A1)
+ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CNF95xxN_A1 |   \
+ROC_MODEL_CNF95xxN_B0)

 #define ROC_MODEL_CN106xx   (ROC_MODEL_CN106xx_A0)
 #define ROC_MODEL_CNF105xx  (ROC_MODEL_CNF105xx_A0)
--
2.35.1

Re: [dpdk-dev] [PATCH v2] common/cnxk: support CNF95xx B0 variant

[Jerin Jacob]

On Fri, Feb 25, 2022 at 4:04 PM Tomasz Duszynski  wrote:
>
> Add CNF95xx B0 variant to the list of supported models.
>
> Signed-off-by: Tomasz Duszynski 
> Reviewed-by: Jerin Jacob 
> ---
> v2:
> - Update release notes for new device support (Ferruh)


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


>
>  doc/guides/rel_notes/release_22_03.rst | 1 +
>  drivers/common/cnxk/roc_model.c| 1 +
>  drivers/common/cnxk/roc_model.h| 6 --
>  3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_22_03.rst 
> b/doc/guides/rel_notes/release_22_03.rst
> index 54563106d1..43c4db65c3 100644
> --- a/doc/guides/rel_notes/release_22_03.rst
> +++ b/doc/guides/rel_notes/release_22_03.rst
> @@ -135,6 +135,7 @@ New Features
>* Added queue based priority flow control support for CN9K & CN10K.
>* Added support for IP reassembly for inline inbound IPsec packets.
>* Added support for packet marking in traffic manager.
> +  * Added support for CNF95xx B0 variant SoC.
>
>  * **Added an API for private user data in asymmetric crypto session.**
>
> diff --git a/drivers/common/cnxk/roc_model.c b/drivers/common/cnxk/roc_model.c
> index 49617c02b7..4120029541 100644
> --- a/drivers/common/cnxk/roc_model.c
> +++ b/drivers/common/cnxk/roc_model.c
> @@ -56,6 +56,7 @@ static const struct model_db {
> {VENDOR_CAVIUM, PART_95xx, 1, 0, ROC_MODEL_CNF95xx_B0, "cnf95xx_b0"},
> {VENDOR_CAVIUM, PART_95xxN, 0, 0, ROC_MODEL_CNF95xxN_A0, 
> "cnf95xxn_a0"},
> {VENDOR_CAVIUM, PART_95xxN, 0, 1, ROC_MODEL_CNF95xxN_A0, 
> "cnf95xxn_a1"},
> +   {VENDOR_CAVIUM, PART_95xxN, 1, 0, ROC_MODEL_CNF95xxN_B0, 
> "cnf95xxn_b0"},
> {VENDOR_CAVIUM, PART_95O, 0, 0, ROC_MODEL_CNF95xxO_A0, "cnf95O_a0"},
> {VENDOR_CAVIUM, PART_95xxMM, 0, 0, ROC_MODEL_CNF95xxMM_A0,
>  "cnf95xxmm_a0"}};
> diff --git a/drivers/common/cnxk/roc_model.h b/drivers/common/cnxk/roc_model.h
> index cee06779bc..4567566169 100644
> --- a/drivers/common/cnxk/roc_model.h
> +++ b/drivers/common/cnxk/roc_model.h
> @@ -19,6 +19,7 @@ struct roc_model {
>  #define ROC_MODEL_CNF95xxN_A0  BIT_ULL(12)
>  #define ROC_MODEL_CNF95xxO_A0  BIT_ULL(13)
>  #define ROC_MODEL_CNF95xxN_A1  BIT_ULL(14)
> +#define ROC_MODEL_CNF95xxN_B0  BIT_ULL(15)
>  #define ROC_MODEL_CN98xx_A0BIT_ULL(16)
>  #define ROC_MODEL_CN106xx_A0   BIT_ULL(20)
>  #define ROC_MODEL_CNF105xx_A0  BIT_ULL(21)
> @@ -39,11 +40,12 @@ struct roc_model {
> (ROC_MODEL_CN96xx_Ax | ROC_MODEL_CN96xx_C0 | ROC_MODEL_CNF95xx_A0 |   
>  \
>  ROC_MODEL_CNF95xx_B0 | ROC_MODEL_CNF95xxMM_A0 |  
>  \
>  ROC_MODEL_CNF95xxO_A0 | ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CN98xx_A0 
> | \
> -ROC_MODEL_CNF95xxN_A1)
> +ROC_MODEL_CNF95xxN_A1 | ROC_MODEL_CNF95xxN_B0)
>  #define ROC_MODEL_CNF9K  
>   \
> (ROC_MODEL_CNF95xx_A0 | ROC_MODEL_CNF95xx_B0 |
>  \
>  ROC_MODEL_CNF95xxMM_A0 | ROC_MODEL_CNF95xxO_A0 | 
>  \
> -ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CNF95xxN_A1)
> +ROC_MODEL_CNF95xxN_A0 | ROC_MODEL_CNF95xxN_A1 |  
>  \
> +ROC_MODEL_CNF95xxN_B0)
>
>  #define ROC_MODEL_CN106xx   (ROC_MODEL_CN106xx_A0)
>  #define ROC_MODEL_CNF105xx  (ROC_MODEL_CNF105xx_A0)
> --
> 2.35.1
>

RE: [PATCH v5 0/2] Add config file support for l3fwd

[Ananyev, Konstantin]

> On Thu, Feb 24, 2022 at 02:46:24PM +0100, Thomas Monjalon wrote:
> > 24/02/2022 12:06, Ananyev, Konstantin:
> > > > > > > > > > > >> Or have a generic library for reading LPM entries.  
> > > > > > > > > > > >> L3fwd is supposed
> > > > > > > > > > > >> to be as small as possible (it no longer is), and the 
> > > > > > > > > > > >> real work should
> > > > > > > > > > > >> be done by libraries to make it easier to build other 
> > > > > > > > > > > >> applications.
> > > > > > > > > > > >
> > > > > > > > > > > > I never heard users ask about such thing,
> > > > > > > > > > > > but if there is a demand for that, then I suppose it 
> > > > > > > > > > > > could be considered.
> > > > > > > > > > > > CC-ing LPM/FIB maintainers to comment.
> > > > > > > > > > > > Though I believe it should be a subject of separate 
> > > > > > > > > > > > patch and discussion
> > > > > > > > > > > > (I think many questions will arise - what format should 
> > > > > > > > > > > > be, how to support
> > > > > > > > > > > > different types of user-data, to make it generic 
> > > > > > > > > > > > enough, etc.).
> > > > > > > > > > >
> > > > > > > > > > > Agree, it is very application specific, so it could be 
> > > > > > > > > > > really difficult
> > > > > > > > > > > to make it generic.
> > > > > > > > > >
> > > > > > > > > > But several other also have LPM tables, so why not have 
> > > > > > > > > > common code for other applications.
> > > > > > > > > >
> > > > > > > > > > examples/l3fwd-power/main.c
> > > > > > > > > > examples/ipsec-secgw/rt.c
> > > > > > > > > > examples/ip_fragmentation/main.c
> > > > > > > > > > examples/l3fwd/l3fwd_lpm.c
> > > > > > > > > > examples/ip_reassembly/main.c
> > > > > > > > >
> > > > > > > > > Ah yes, that's good point.
> > > > > > > > > All these examples (except ipsec-secgw) started as l3fwd 
> > > > > > > > > clones,
> > > > > > > > > so all of them have hard-coded LPM (and EM) tables too.
> > > > > > > > > Yes it would be good thing to address that problem too,
> > > > > > > > > and have some common code (and common routes file format) for 
> > > > > > > > > all of them.
> > > > > > > > > I don't know is that a good idea to introduce parse file 
> > > > > > > > > function in LPM/FIB library
> > > > > > > > > itself, might be better to  have something like 
> > > > > > > > > examples/common/lpm_parse*.
> > > > > > > > > Anyway, this is an extra effort, and I think no-one has time 
> > > > > > > > > for it in 22.03 timeframe.
> > > > > > > > > My suggestion would be for 22.03 go ahead with current l3fwd 
> > > > > > > > > patches,
> > > > > > > > > then later we can consider to make it common and update other 
> > > > > > > > > examples.
> > > > > > > >
> > > > > > > > I don't think this patch is urgent.
> > > > > > > > I suggest taking time to have common code for all examples
> > > > > > > > and target a merge in DPDK 22.07.
> > > > > > >
> > > > > > > Well, yes, from one perspective it not really a critical one,
> > > > > > > we do live with hard-coded routes inside l3fwd for nearly 10 year 
> > > > > > > by now.
> > > > > > > Though l3fwd is one of mostly used examples inside DPDK and
> > > > > > > it is quite a pain to patch/rebuild it each time someone needs to 
> > > > > > > run
> > > > > > > l3fwd with a different routing table.
> > > > > > > Merging this patch will allow people to use l3fwd for more 
> > > > > > > realistic test
> > > > > > > scenarios in a painless manner.
> > > > > > > So I believe this patch is really helpful and should be 
> > > > > > > beneficial for the whole community.
> > > > > > > Looking from that perspective, I don't see why it has to be "all 
> > > > > > > or nothing" attitude here.
> > > > > > > Why we can't move one step at a time instead?
> > > > > > > That would allow to split and effort in terms of 
> > > > > > > development/testing/upstreaming/etc.
> > > > > >
> > > > > > When a feature is merged, there is less incentives to rework.
> > > > > > That's why, when a feature is not urgent,
> > > > > > it is better to wait for the complete work.
> > > > >
> > > > > That's true till some extent, though from other side
> > > > > even without further rework that patch improves situation
> > > > > from what we have right now.
> > > > > So I don't see any harm here.
> > > >
> > > > It is adding a lot of code to an example which is already too big.
> > > > There are a lot of complain about the size of l3fwd.
> > > > That's why I think it makes sense to require this extra code
> > > > (not demonstrating anything, but just for testing convenience)
> > > > outside of the example.
> > >
> > > Ok, so your main concern is l3fwd code size increase, right?
> > > Then would it help if for we'll move file parsing code into a separate 
> > > file(s)
> > > (under examples/l3fwd) for now?
> > > Something like examples/l3fwd/(lpm_em)_route_parse.c.
> >
> > Yes it would help to isolate the config file parsing code.
> > What others think?
> >
> I still would like conf

RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym crypto routine

[Akhil Goyal]

Hi Kai,
> 
> The warning messages are deprecated APIs warnings from openssl , not
> compiler warnings from gcc, the integrity of DPDK remain the same.
> Alongside openssl pmd, the ccp and qat pmd also raise the same type of
> warnings once openssl 3.0 installed.
> 
> In the current intel roadmap,  we will try to support 3.0 API fully for 
> openssl and
> qat pmds by the end of year, so this patch is the first step.
> I think the warning messages are safe to stay, Unfortunately the fix ccp pmd
> driver is out of our reach.
> 

When DPDK is compiled with openssl 3.0. I am seeing these errors in compilation.
So, compilation is broken and we cannot take this patch as is.
We have few options,
- fix all of these errors,
- add exception in meson.build for ignoring these errors.
- disable/skip compilation of PMDs if openssl version is >3.0

Adding only one type of APIs does not make sense, if the driver is not compiled.

In file included from ../drivers/crypto/openssl/openssl_pmd_private.h:12,
 from ../drivers/crypto/openssl/rte_openssl_pmd.c:16:
/usr/local/include/openssl/dh.h:223:27: note: declared here
  223 | OSSL_DEPRECATEDIN_3_0 int DH_generate_key(DH *dh);
  |   ^~~
../drivers/crypto/openssl/rte_openssl_pmd.c: In function 
'process_openssl_rsa_op':
../drivers/crypto/openssl/rte_openssl_pmd.c:2068:3: error: 'RSA_public_encrypt' 
is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
 2068 |   ret = RSA_public_encrypt(op->rsa.message.length,

Also, avoid top posting of comments!

Re: [PATCH v5 0/2] Add config file support for l3fwd

[Bruce Richardson]

On Fri, Feb 25, 2022 at 10:36:29AM +, Ananyev, Konstantin wrote:
> 
> > On Thu, Feb 24, 2022 at 02:46:24PM +0100, Thomas Monjalon wrote:
> > > 24/02/2022 12:06, Ananyev, Konstantin:
> > > > > > > > > > > > >> Or have a generic library for reading LPM entries.  
> > > > > > > > > > > > >> L3fwd is supposed
> > > > > > > > > > > > >> to be as small as possible (it no longer is), and 
> > > > > > > > > > > > >> the real work should
> > > > > > > > > > > > >> be done by libraries to make it easier to build 
> > > > > > > > > > > > >> other applications.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I never heard users ask about such thing,
> > > > > > > > > > > > > but if there is a demand for that, then I suppose it 
> > > > > > > > > > > > > could be considered.
> > > > > > > > > > > > > CC-ing LPM/FIB maintainers to comment.
> > > > > > > > > > > > > Though I believe it should be a subject of separate 
> > > > > > > > > > > > > patch and discussion
> > > > > > > > > > > > > (I think many questions will arise - what format 
> > > > > > > > > > > > > should be, how to support
> > > > > > > > > > > > > different types of user-data, to make it generic 
> > > > > > > > > > > > > enough, etc.).
> > > > > > > > > > > >
> > > > > > > > > > > > Agree, it is very application specific, so it could be 
> > > > > > > > > > > > really difficult
> > > > > > > > > > > > to make it generic.
> > > > > > > > > > >
> > > > > > > > > > > But several other also have LPM tables, so why not have 
> > > > > > > > > > > common code for other applications.
> > > > > > > > > > >
> > > > > > > > > > > examples/l3fwd-power/main.c
> > > > > > > > > > > examples/ipsec-secgw/rt.c
> > > > > > > > > > > examples/ip_fragmentation/main.c
> > > > > > > > > > > examples/l3fwd/l3fwd_lpm.c
> > > > > > > > > > > examples/ip_reassembly/main.c
> > > > > > > > > >
> > > > > > > > > > Ah yes, that's good point.
> > > > > > > > > > All these examples (except ipsec-secgw) started as l3fwd 
> > > > > > > > > > clones,
> > > > > > > > > > so all of them have hard-coded LPM (and EM) tables too.
> > > > > > > > > > Yes it would be good thing to address that problem too,
> > > > > > > > > > and have some common code (and common routes file format) 
> > > > > > > > > > for all of them.
> > > > > > > > > > I don't know is that a good idea to introduce parse file 
> > > > > > > > > > function in LPM/FIB library
> > > > > > > > > > itself, might be better to  have something like 
> > > > > > > > > > examples/common/lpm_parse*.
> > > > > > > > > > Anyway, this is an extra effort, and I think no-one has 
> > > > > > > > > > time for it in 22.03 timeframe.
> > > > > > > > > > My suggestion would be for 22.03 go ahead with current 
> > > > > > > > > > l3fwd patches,
> > > > > > > > > > then later we can consider to make it common and update 
> > > > > > > > > > other examples.
> > > > > > > > >
> > > > > > > > > I don't think this patch is urgent.
> > > > > > > > > I suggest taking time to have common code for all examples
> > > > > > > > > and target a merge in DPDK 22.07.
> > > > > > > >
> > > > > > > > Well, yes, from one perspective it not really a critical one,
> > > > > > > > we do live with hard-coded routes inside l3fwd for nearly 10 
> > > > > > > > year by now.
> > > > > > > > Though l3fwd is one of mostly used examples inside DPDK and
> > > > > > > > it is quite a pain to patch/rebuild it each time someone needs 
> > > > > > > > to run
> > > > > > > > l3fwd with a different routing table.
> > > > > > > > Merging this patch will allow people to use l3fwd for more 
> > > > > > > > realistic test
> > > > > > > > scenarios in a painless manner.
> > > > > > > > So I believe this patch is really helpful and should be 
> > > > > > > > beneficial for the whole community.
> > > > > > > > Looking from that perspective, I don't see why it has to be 
> > > > > > > > "all or nothing" attitude here.
> > > > > > > > Why we can't move one step at a time instead?
> > > > > > > > That would allow to split and effort in terms of 
> > > > > > > > development/testing/upstreaming/etc.
> > > > > > >
> > > > > > > When a feature is merged, there is less incentives to rework.
> > > > > > > That's why, when a feature is not urgent,
> > > > > > > it is better to wait for the complete work.
> > > > > >
> > > > > > That's true till some extent, though from other side
> > > > > > even without further rework that patch improves situation
> > > > > > from what we have right now.
> > > > > > So I don't see any harm here.
> > > > >
> > > > > It is adding a lot of code to an example which is already too big.
> > > > > There are a lot of complain about the size of l3fwd.
> > > > > That's why I think it makes sense to require this extra code
> > > > > (not demonstrating anything, but just for testing convenience)
> > > > > outside of the example.
> > > >
> > > > Ok, so your main concern is l3fwd code size increase, right?
> > > > Then would it help if for we'll move file parsing cod

RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym crypto routine

[Ji, Kai]

HI Akhil,

> 
> When DPDK is compiled with openssl 3.0. I am seeing these errors in 
> compilation.
> So, compilation is broken and we cannot take this patch as is.
> We have few options,
> - fix all of these errors,
> - add exception in meson.build for ignoring these errors.
> - disable/skip compilation of PMDs if openssl version is >3.0
> 
> Adding only one type of APIs does not make sense, if the driver is not 
> compiled.
> 
> In file included from ../drivers/crypto/openssl/openssl_pmd_private.h:12,
>  from ../drivers/crypto/openssl/rte_openssl_pmd.c:16:
> /usr/local/include/openssl/dh.h:223:27: note: declared here
>   223 | OSSL_DEPRECATEDIN_3_0 int DH_generate_key(DH *dh);
>   |   ^~~
> ../drivers/crypto/openssl/rte_openssl_pmd.c: In function
> 'process_openssl_rsa_op':
> ../drivers/crypto/openssl/rte_openssl_pmd.c:2068:3: error:
> 'RSA_public_encrypt' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-
> declarations]
>  2068 |   ret = RSA_public_encrypt(op->rsa.message.length,
> 
> Also, avoid top posting of comments!


I will try to suppress the warning message in meson.build by EOB, otherwise the 
patch need to be deferred until next release. 

Regards

Kai  

Re: [PATCH v1] power: add wakeup log

[Burakov, Anatoly]

On 24-Feb-22 2:38 AM, Li, Miao wrote:

Hi,


-Original Message-
From: Hunt, David 
Sent: Wednesday, February 23, 2022 12:32 AM
To: Li, Miao ; dev@dpdk.org
Cc: Wang, Yinan ; step...@networkplumber.org
Subject: Re: [PATCH v1] power: add wakeup log


On 22/2/2022 1:52 PM, Miao Li wrote:

This patch adds a log in rte_power_monitor to show the core has been
waked up.

Signed-off-by: Miao Li 
---
   lib/eal/x86/rte_power_intrinsics.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c

b/lib/eal/x86/rte_power_intrinsics.c

index f749da9b85..dd63e2b6eb 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -128,6 +128,14 @@ rte_power_monitor(const struct

rte_power_monitor_cond *pmc,

: "D"(0), /* enter C0.2 */
  "a"(tsc_l), "d"(tsc_h));

+   cur_value = __get_umwait_val(pmc->addr, pmc->size);
+
+   /* check if core has been waked up by changing monitoring value */
+   if (pmc->fn(cur_value, pmc->opaque) != 0)
+   RTE_LOG(INFO, EAL,
+   "lcore %u is waked up from value change\n",
+   rte_lcore_id());
+
   end:
/* erase sleep address */
rte_spinlock_lock(&s->lock);



Hi Li,

If I'm not mistaken, a similar patch was added to a previous DPDK
release and then removed because of the enormous performance impact.

This looks to be something similar, and it's adding a log message to a
low-level function. Also, as mentioned before, the intention in the
future is to call this function much more agressively, so there would be
hundreds of thousands of messages every second.

We cannot add an RTE_LOG here. Please rework and put the log in the test
case instead.


I add a judgment before the output. When no packet arriver, the log will not be 
printed. When a lot of packets arriver, the rte_power_monitor will not be 
called. So I think the performance impact is small.



Also, regarding the wording, I would suggest  "lcore %u awoke due to
monitor address value change\n"


I will change the log content in next version.



Rgds,

Dave.



Thanks,
Miao




Hi Miao,

I have to agree with Dave here, I don't think this patch should be 
merged, as there are several problems with it.


First of all, the result might be inaccurate in practice, because there 
is a race condition between reading value first and second time - 
UMONITOR protects us from that before we sleep, but not after. So, the 
information we get with `__get_umwait_val()` and calling a callback 
might be out of date by the time we reach that code. So, this code is 
*provably* vulnerable to race conditions.


More importantly, I do not see how this is a useful addition to DPDK. I 
have to ask: what is the problem the patch is trying to solve? Because 
if the problem being solved is validating full path from l3fwd-power 
down to `rte_power_monitor`, then it could be solved in other ways that 
are more agreeable.


For example, I believe we have logging inside l3fwd-power, so we can 
validate that it wakes up correctly. We *don't* have logging inside 
rte_power for these particular code paths, but IMO it would be 
unnecessary because l3fwd-power already effectively does that anyway. We 
*don't* have logging inside `rte_power_monitor`, but we can still 
validate it with unit tests, if the concern here is validating that the 
functionality works correctly.


So, we can verify `rte_power_monitor` works with unit tests. We *could* 
introspect `rte_power` callback code with more logging if that's 
required (although IMO unnecessary, given that l3fwd-power already does 
that), and we can validate that l3fwd-power wakes up correctly with 
existing logging. So, with the addition of unit tests, the entire stack 
would be validated.


Thus, to me, it seems like the patch is adding a (conditional) log 
message to a low level function, supported by an unnecessary and racy 
read/callback call for the sole purpose of checking information that 
does not get used anywhere else in the function other than in a log 
message, to solve a problem that could be solved in another way (with 
unit tests).


Is there anything that I'm missing here?

--
Thanks,
Anatoly

RE: [PATCH v5 0/2] Add config file support for l3fwd

[Ananyev, Konstantin]

> > > > > > > > > > > > > >> Or have a generic library for reading LPM entries. 
> > > > > > > > > > > > > >>  L3fwd is supposed
> > > > > > > > > > > > > >> to be as small as possible (it no longer is), and 
> > > > > > > > > > > > > >> the real work should
> > > > > > > > > > > > > >> be done by libraries to make it easier to build 
> > > > > > > > > > > > > >> other applications.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I never heard users ask about such thing,
> > > > > > > > > > > > > > but if there is a demand for that, then I suppose 
> > > > > > > > > > > > > > it could be considered.
> > > > > > > > > > > > > > CC-ing LPM/FIB maintainers to comment.
> > > > > > > > > > > > > > Though I believe it should be a subject of separate 
> > > > > > > > > > > > > > patch and discussion
> > > > > > > > > > > > > > (I think many questions will arise - what format 
> > > > > > > > > > > > > > should be, how to support
> > > > > > > > > > > > > > different types of user-data, to make it generic 
> > > > > > > > > > > > > > enough, etc.).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agree, it is very application specific, so it could 
> > > > > > > > > > > > > be really difficult
> > > > > > > > > > > > > to make it generic.
> > > > > > > > > > > >
> > > > > > > > > > > > But several other also have LPM tables, so why not have 
> > > > > > > > > > > > common code for other applications.
> > > > > > > > > > > >
> > > > > > > > > > > > examples/l3fwd-power/main.c
> > > > > > > > > > > > examples/ipsec-secgw/rt.c
> > > > > > > > > > > > examples/ip_fragmentation/main.c
> > > > > > > > > > > > examples/l3fwd/l3fwd_lpm.c
> > > > > > > > > > > > examples/ip_reassembly/main.c
> > > > > > > > > > >
> > > > > > > > > > > Ah yes, that's good point.
> > > > > > > > > > > All these examples (except ipsec-secgw) started as l3fwd 
> > > > > > > > > > > clones,
> > > > > > > > > > > so all of them have hard-coded LPM (and EM) tables too.
> > > > > > > > > > > Yes it would be good thing to address that problem too,
> > > > > > > > > > > and have some common code (and common routes file format) 
> > > > > > > > > > > for all of them.
> > > > > > > > > > > I don't know is that a good idea to introduce parse file 
> > > > > > > > > > > function in LPM/FIB library
> > > > > > > > > > > itself, might be better to  have something like 
> > > > > > > > > > > examples/common/lpm_parse*.
> > > > > > > > > > > Anyway, this is an extra effort, and I think no-one has 
> > > > > > > > > > > time for it in 22.03 timeframe.
> > > > > > > > > > > My suggestion would be for 22.03 go ahead with current 
> > > > > > > > > > > l3fwd patches,
> > > > > > > > > > > then later we can consider to make it common and update 
> > > > > > > > > > > other examples.
> > > > > > > > > >
> > > > > > > > > > I don't think this patch is urgent.
> > > > > > > > > > I suggest taking time to have common code for all examples
> > > > > > > > > > and target a merge in DPDK 22.07.
> > > > > > > > >
> > > > > > > > > Well, yes, from one perspective it not really a critical one,
> > > > > > > > > we do live with hard-coded routes inside l3fwd for nearly 10 
> > > > > > > > > year by now.
> > > > > > > > > Though l3fwd is one of mostly used examples inside DPDK and
> > > > > > > > > it is quite a pain to patch/rebuild it each time someone 
> > > > > > > > > needs to run
> > > > > > > > > l3fwd with a different routing table.
> > > > > > > > > Merging this patch will allow people to use l3fwd for more 
> > > > > > > > > realistic test
> > > > > > > > > scenarios in a painless manner.
> > > > > > > > > So I believe this patch is really helpful and should be 
> > > > > > > > > beneficial for the whole community.
> > > > > > > > > Looking from that perspective, I don't see why it has to be 
> > > > > > > > > "all or nothing" attitude here.
> > > > > > > > > Why we can't move one step at a time instead?
> > > > > > > > > That would allow to split and effort in terms of 
> > > > > > > > > development/testing/upstreaming/etc.
> > > > > > > >
> > > > > > > > When a feature is merged, there is less incentives to rework.
> > > > > > > > That's why, when a feature is not urgent,
> > > > > > > > it is better to wait for the complete work.
> > > > > > >
> > > > > > > That's true till some extent, though from other side
> > > > > > > even without further rework that patch improves situation
> > > > > > > from what we have right now.
> > > > > > > So I don't see any harm here.
> > > > > >
> > > > > > It is adding a lot of code to an example which is already too big.
> > > > > > There are a lot of complain about the size of l3fwd.
> > > > > > That's why I think it makes sense to require this extra code
> > > > > > (not demonstrating anything, but just for testing convenience)
> > > > > > outside of the example.
> > > > >
> > > > > Ok, so your main concern is l3fwd code size increase, right?
> > > > > Then would it help if for we'll move file parsing code into a

RE: [PATCH v5 0/2] Add config file support for l3fwd

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 25 February 2022 11.40
> 
> On Fri, Feb 25, 2022 at 10:36:29AM +, Ananyev, Konstantin wrote:
> >
> > > On Thu, Feb 24, 2022 at 02:46:24PM +0100, Thomas Monjalon wrote:
> > > > 24/02/2022 12:06, Ananyev, Konstantin:
> > > > > > > > > > > > > >> Or have a generic library for reading LPM
> entries.  L3fwd is supposed
> > > > > > > > > > > > > >> to be as small as possible (it no longer
> is), and the real work should
> > > > > > > > > > > > > >> be done by libraries to make it easier to
> build other applications.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I never heard users ask about such thing,
> > > > > > > > > > > > > > but if there is a demand for that, then I
> suppose it could be considered.
> > > > > > > > > > > > > > CC-ing LPM/FIB maintainers to comment.
> > > > > > > > > > > > > > Though I believe it should be a subject of
> separate patch and discussion
> > > > > > > > > > > > > > (I think many questions will arise - what
> format should be, how to support
> > > > > > > > > > > > > > different types of user-data, to make it
> generic enough, etc.).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agree, it is very application specific, so it
> could be really difficult
> > > > > > > > > > > > > to make it generic.
> > > > > > > > > > > >
> > > > > > > > > > > > But several other also have LPM tables, so why
> not have common code for other applications.
> > > > > > > > > > > >
> > > > > > > > > > > > examples/l3fwd-power/main.c
> > > > > > > > > > > > examples/ipsec-secgw/rt.c
> > > > > > > > > > > > examples/ip_fragmentation/main.c
> > > > > > > > > > > > examples/l3fwd/l3fwd_lpm.c
> > > > > > > > > > > > examples/ip_reassembly/main.c
> > > > > > > > > > >
> > > > > > > > > > > Ah yes, that's good point.
> > > > > > > > > > > All these examples (except ipsec-secgw) started as
> l3fwd clones,
> > > > > > > > > > > so all of them have hard-coded LPM (and EM) tables
> too.
> > > > > > > > > > > Yes it would be good thing to address that problem
> too,
> > > > > > > > > > > and have some common code (and common routes file
> format) for all of them.
> > > > > > > > > > > I don't know is that a good idea to introduce parse
> file function in LPM/FIB library
> > > > > > > > > > > itself, might be better to  have something like
> examples/common/lpm_parse*.
> > > > > > > > > > > Anyway, this is an extra effort, and I think no-one
> has time for it in 22.03 timeframe.
> > > > > > > > > > > My suggestion would be for 22.03 go ahead with
> current l3fwd patches,
> > > > > > > > > > > then later we can consider to make it common and
> update other examples.
> > > > > > > > > >
> > > > > > > > > > I don't think this patch is urgent.
> > > > > > > > > > I suggest taking time to have common code for all
> examples
> > > > > > > > > > and target a merge in DPDK 22.07.
> > > > > > > > >
> > > > > > > > > Well, yes, from one perspective it not really a
> critical one,
> > > > > > > > > we do live with hard-coded routes inside l3fwd for
> nearly 10 year by now.
> > > > > > > > > Though l3fwd is one of mostly used examples inside DPDK
> and
> > > > > > > > > it is quite a pain to patch/rebuild it each time
> someone needs to run
> > > > > > > > > l3fwd with a different routing table.
> > > > > > > > > Merging this patch will allow people to use l3fwd for
> more realistic test
> > > > > > > > > scenarios in a painless manner.
> > > > > > > > > So I believe this patch is really helpful and should be
> beneficial for the whole community.
> > > > > > > > > Looking from that perspective, I don't see why it has
> to be "all or nothing" attitude here.
> > > > > > > > > Why we can't move one step at a time instead?
> > > > > > > > > That would allow to split and effort in terms of
> development/testing/upstreaming/etc.
> > > > > > > >
> > > > > > > > When a feature is merged, there is less incentives to
> rework.
> > > > > > > > That's why, when a feature is not urgent,
> > > > > > > > it is better to wait for the complete work.
> > > > > > >
> > > > > > > That's true till some extent, though from other side
> > > > > > > even without further rework that patch improves situation
> > > > > > > from what we have right now.
> > > > > > > So I don't see any harm here.
> > > > > >
> > > > > > It is adding a lot of code to an example which is already too
> big.
> > > > > > There are a lot of complain about the size of l3fwd.
> > > > > > That's why I think it makes sense to require this extra code
> > > > > > (not demonstrating anything, but just for testing
> convenience)
> > > > > > outside of the example.
> > > > >
> > > > > Ok, so your main concern is l3fwd code size increase, right?
> > > > > Then would it help if for we'll move file parsing code into a
> separate file(s)
> > > > > (under examples/l3fwd) for now?
> > > > > Something like examples/l3fwd/(lpm_em)_route_parse.c.
> > > >
> > > > Yes it would help to isolate the conf

RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym crypto routine

[Zhang, Roy Fan]

Hi Akhil,

> -Original Message-
> From: Akhil Goyal 
> Sent: Friday, February 25, 2022 10:40 AM
> To: Ji, Kai ; dev@dpdk.org
> Cc: Zhang, Roy Fan 
> Subject: RE: [EXT] [dpdk-dev v5] crypto/openssl: openssl 3.0 support on sym
> crypto routine
> 
> Hi Kai,
> >
> > The warning messages are deprecated APIs warnings from openssl , not
> > compiler warnings from gcc, the integrity of DPDK remain the same.
> > Alongside openssl pmd, the ccp and qat pmd also raise the same type of
> > warnings once openssl 3.0 installed.
> >
> > In the current intel roadmap,  we will try to support 3.0 API fully for 
> > openssl
> and
> > qat pmds by the end of year, so this patch is the first step.
> > I think the warning messages are safe to stay, Unfortunately the fix ccp
> pmd
> > driver is out of our reach.
> >
> 
> When DPDK is compiled with openssl 3.0. I am seeing these errors in
> compilation.
> So, compilation is broken and we cannot take this patch as is.
> We have few options,
> - fix all of these errors,
> - add exception in meson.build for ignoring these errors.
> - disable/skip compilation of PMDs if openssl version is >3.0
> 
> Adding only one type of APIs does not make sense, if the driver is not
> compiled.
> 
> In file included from ../drivers/crypto/openssl/openssl_pmd_private.h:12,
>  from ../drivers/crypto/openssl/rte_openssl_pmd.c:16:
> /usr/local/include/openssl/dh.h:223:27: note: declared here
>   223 | OSSL_DEPRECATEDIN_3_0 int DH_generate_key(DH *dh);
>   |   ^~~
> ../drivers/crypto/openssl/rte_openssl_pmd.c: In function
> 'process_openssl_rsa_op':
> ../drivers/crypto/openssl/rte_openssl_pmd.c:2068:3: error:
> 'RSA_public_encrypt' is deprecated: Since OpenSSL 3.0 [-
> Werror=deprecated-declarations]
>  2068 |   ret = RSA_public_encrypt(op->rsa.message.length,

You are right. We will defer the change to next release so we can send along
with the asym openssl change Kai is working on. But since we have your attention
I would want to drag Chandubabu's attention too  as there are three PMDs uses
deprecated openssl lib APIs: openssl, qat, and ccp. Adding a suppress flag to 
meson
build file won't resolve the problem - we need to resolve them before the APIs 
are
gone for good.

> 
> Also, avoid top posting of comments!

Re: [PATCH v3] net/ice/base: support E824S and E825 devices

[Ferruh Yigit]

On 2/25/2022 2:00 AM, Robin Zhang wrote:

Add support for E824S and E825 family devices.

This will be documented later in release notes due to we don't have
mature product now.

Signed-off-by: Robin Zhang


Acked-by: Ferruh Yigit 

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

RE: [PATCH v3] ip_frag: add IPv4 options fragment and test data

[Ananyev, Konstantin]

Ho Huichao,

> According to RFC791,the options may appear or not in datagrams.
> They must be implemented by all IP modules (host and gateways).
> What is optional is their transmission in any particular datagram,
> not their implementation.So we have to deal with it during the
> fragmenting process.Add some test data for the IPv4 header optional
> field fragmenting.

Apologies for delay in getting back to you.
LGTM in general, just few extra questions/nits/suggestions below.

> 
> Signed-off-by: Huichao Cai 
> ---
>  app/test/test_ipfrag.c   | 263 
> ---
>  lib/ip_frag/rte_ipv4_fragmentation.c |  77 +-
>  2 files changed, 318 insertions(+), 22 deletions(-)
> 
> diff --git a/app/test/test_ipfrag.c b/app/test/test_ipfrag.c
> index 1ced25a..996130d 100644
> --- a/app/test/test_ipfrag.c
> +++ b/app/test/test_ipfrag.c
> @@ -18,10 +18,96 @@
>  #define NUM_MBUFS 128
>  #define BURST 32
> 
> +/* IP options */
> +#define RTE_IPOPT_EOL0
> +#define RTE_IPOPT_NOP1
> +#define RTE_IPOPT_COPIED(v)  ((v) & 0x80)
> +#define RTE_IPOPT_MAX_LEN40

These macros are dups for what we have in rte_ipv4_fragmentation.c
Would probably make sense to name them RTE_IPV4_IPOPT_... and put them 
in some public .h to avoid duplication.

> +#define RTE_IPOPT_MANUAL

Could you clarify what this macro does?
BTW, I assume it is a local one?
If so, no need for RTE_ prefix.

> +#ifdef RTE_IPOPT_MANUAL
> +uint8_t expected_first_frag_ipv4_opts[] = {
> + 0x07, 0x0b, 0x04, 0x00,
> + 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x83,
> + 0x07, 0x04, 0xc0, 0xa8,
> + 0xe3, 0x96, 0x00, 0x00,
> +};
> +
> +uint8_t expected_sub_frag_ipv4_opts[] = {
> + 0x83, 0x07, 0x04, 0xc0,
> + 0xa8, 0xe3, 0x96, 0x00,
> +};
> +#else
> +/**
> + * IPv4 Options
> + */
> +struct test_ipv4_opt {
> + __extension__
> + union {
> + uint8_t type;   /**< option type */
> + struct {
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> + uint8_t number:5;   /**< option number */
> + uint8_t category:2; /**< option class */
> + uint8_t copied:1;   /**< option copy flag */
> +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> + uint8_t copied:1;   /**< option copy flag */
> + uint8_t category:2; /**< option class */
> + uint8_t number:5;   /**< option number */
> +#endif
> + } s_type;
> + };
> + uint8_t length; /**< option length */
> + uint8_t pointer;/**< option pointer */
> + uint8_t data[37];   /**< option data */
> +} __rte_packed;
> +
> +struct test_ipv4_opt test_ipv4_opts[] = {
> + {
> + .s_type.copied = 0,
> + .s_type.category = 0,
> + .s_type.number = 7,
> + .length = 11,
> + .pointer = 4,
> + },
> + {
> + .s_type.copied = 1,
> + .s_type.category = 0,
> + .s_type.number = 3,
> + .length = 7,
> + .pointer = 4,
> + .data[0] = 0xc0,
> + .data[1] = 0xa8,
> + .data[2] = 0xe3,
> + .data[3] = 0x96,
> + },
> +};
> +#endif
> +
> +struct test_opt_data {
> + bool is_first_frag;  /**< offset is 0 */
> + uint16_t len;/**< option data len */
> + uint8_t data[RTE_IPOPT_MAX_LEN]; /**< option data */
> +};
> +
>  static struct rte_mempool *pkt_pool,
> *direct_pool,
> *indirect_pool;
> 
> +static inline void
> +hex_to_str(uint8_t *hex, uint16_t len, char *str)
> +{
> + int i;
> +
> + for (i = 0; i < len; i++) {
> + sprintf(str, "%02x", hex[i]);
> + str += 2;
> + }
> + *str = 0;
> +}
> +
>  static int
>  setup_buf_pool(void)
>  {
> @@ -88,23 +174,78 @@ static void ut_teardown(void)
>  {
>  }
> 
> +static inline void
> +test_get_ipv4_opt(bool is_first_frag,
> + struct test_opt_data *expected_opt)
> +{
> +#ifdef RTE_IPOPT_MANUAL
> + if (is_first_frag) {
> + expected_opt->len = sizeof(expected_first_frag_ipv4_opts);
> + rte_memcpy(expected_opt->data, expected_first_frag_ipv4_opts,
> + sizeof(expected_first_frag_ipv4_opts));
> + } else {
> + expected_opt->len = sizeof(expected_sub_frag_ipv4_opts);
> + rte_memcpy(expected_opt->data, expected_sub_frag_ipv4_opts,
> + sizeof(expected_sub_frag_ipv4_opts));
> + }
> +#else
> + uint16_t i;
> + uint16_t pos = 0;
> + expected_opt->len = 0;
> +
> + for (i = 0; i < RTE_DIM(test_ipv4_opts); i++) {
> + if (unlikely(pos + test_ipv4_opts[i].length >
> + RTE_IPOPT_MAX_LEN))
> + 

Re: [PATCH v3] net/i40e: fix unintentional integer overflow

[Ferruh Yigit]

On 2/25/2022 2:39 AM, Steve Yang wrote:

Cast 1 to type uint64_t to avoid overflow.

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

Coverity issue: 375812
Fixes: 5fec01c35c49 ("net/i40e: support Linux VF to configure IRQ link list")
Cc: sta...@dpdk.org

---
v2: update commit message;
v3: use RTE_BIT64() to set bit;

Signed-off-by: Steve Yang 


Reviewed-by: Ferruh Yigit 

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

[PATCH] raw/cnxk_gpio: stop device once tests are complete

[Tomasz Duszynski]

Started device should eventually be stopped.

Fixes: 0e6557b448fa ("raw/cnxk_gpio: add self test")

Signed-off-by: Tomasz Duszynski 
Reviewed-by: Jerin Jacob Kollanukkaran 
---
 drivers/raw/cnxk_gpio/cnxk_gpio_selftest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/raw/cnxk_gpio/cnxk_gpio_selftest.c 
b/drivers/raw/cnxk_gpio/cnxk_gpio_selftest.c
index acb65afa65..10742b5dc4 100644
--- a/drivers/raw/cnxk_gpio/cnxk_gpio_selftest.c
+++ b/drivers/raw/cnxk_gpio/cnxk_gpio_selftest.c
@@ -390,6 +390,7 @@ cnxk_gpio_selftest(uint16_t dev_id)
 
 out:
close(fd);
+   rte_rawdev_stop(dev_id);
 
return ret;
 }
-- 
2.25.1

[dpdk-dev v6] crypto/openssl: openssl 3.0 support on sym crypto routine

[Kai Ji]

This patch setup OPENSSL_API_COMPAT to suppress deprecated compile
warning messages in ccp, openssl and qat PMDs, also update the symmetric
EVP routine in crypto openssl pmd to adopt openssl 3.0 library.

Signed-off-by: Kai Ji 
Acked-by: Fan Zhang 
---
 drivers/common/qat/meson.build   |   1 +
 drivers/crypto/ccp/meson.build   |   1 +
 drivers/crypto/openssl/meson.build   |   1 +
 drivers/crypto/openssl/openssl_pmd_private.h |   4 +
 drivers/crypto/openssl/rte_openssl_pmd.c | 187 ++-
 5 files changed, 184 insertions(+), 10 deletions(-)

diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build
index af92271a75..f9bef9b2e1 100644
--- a/drivers/common/qat/meson.build
+++ b/drivers/common/qat/meson.build
@@ -86,4 +86,5 @@ if qat_crypto
 deps += ['security']
 ext_deps += libcrypto
 cflags += ['-DBUILD_QAT_SYM', '-DBUILD_QAT_ASYM']
+cflags += ['-DOPENSSL_API_COMPAT=0x1010L']
 endif
diff --git a/drivers/crypto/ccp/meson.build b/drivers/crypto/ccp/meson.build
index a4f3406009..fe89e17b14 100644
--- a/drivers/crypto/ccp/meson.build
+++ b/drivers/crypto/ccp/meson.build
@@ -23,3 +23,4 @@ sources = files(
 )
 
 ext_deps += dep
+cflags += ['-DOPENSSL_API_COMPAT=0x1010L']
diff --git a/drivers/crypto/openssl/meson.build 
b/drivers/crypto/openssl/meson.build
index cd962da1d6..cef92fe57a 100644
--- a/drivers/crypto/openssl/meson.build
+++ b/drivers/crypto/openssl/meson.build
@@ -15,3 +15,4 @@ endif
 deps += 'bus_vdev'
 sources = files('rte_openssl_pmd.c', 'rte_openssl_pmd_ops.c')
 ext_deps += dep
+cflags += ['-DOPENSSL_API_COMPAT=0x1010L']
\ No newline at end of file
diff --git a/drivers/crypto/openssl/openssl_pmd_private.h 
b/drivers/crypto/openssl/openssl_pmd_private.h
index b2054b3754..86dc169aaf 100644
--- a/drivers/crypto/openssl/openssl_pmd_private.h
+++ b/drivers/crypto/openssl/openssl_pmd_private.h
@@ -134,8 +134,12 @@ struct openssl_session {
/**< pointer to EVP key */
const EVP_MD *evp_algo;
/**< pointer to EVP algorithm function */
+# if OPENSSL_VERSION_NUMBER >= 0x3000L
+   EVP_MAC_CTX * ctx;
+# else
HMAC_CTX *ctx;
/**< pointer to EVP context structure */
+# endif
} hmac;
};
 
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c 
b/drivers/crypto/openssl/rte_openssl_pmd.c
index 5794ed8159..5840ab472e 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -39,6 +39,61 @@ static void HMAC_CTX_free(HMAC_CTX *ctx)
 }
 #endif
 
+#if (OPENSSL_VERSION_NUMBER >= 0x3000L)
+
+#include 
+#include 
+
+#define MAX_OSSL_ALGO_NAME_SIZE16
+
+OSSL_PROVIDER *legacy;
+OSSL_PROVIDER *deflt;
+
+static void ossl_load_legacy_provider(void)
+{
+   /* Load Multiple providers into the default (NULL) library context */
+   legacy = OSSL_PROVIDER_load(NULL, "legacy");
+   if (legacy == NULL) {
+   OPENSSL_LOG(ERR, "Failed to load Legacy provider\n");
+   return;
+   }
+
+   deflt = OSSL_PROVIDER_load(NULL, "default");
+   if (deflt == NULL) {
+   OPENSSL_LOG(ERR, "Failed to load Default provider\n");
+   OSSL_PROVIDER_unload(legacy);
+   return;
+   }
+}
+
+static void ossl_unload_legacy_provider(void)
+{
+   OSSL_PROVIDER_unload(legacy);
+   OSSL_PROVIDER_unload(deflt);
+}
+
+static __rte_always_inline const char *
+get_digest_name(const struct rte_crypto_sym_xform *xform)
+{
+   switch (xform->auth.algo) {
+   case RTE_CRYPTO_AUTH_MD5_HMAC:
+   return OSSL_DIGEST_NAME_MD5;
+   case RTE_CRYPTO_AUTH_SHA1_HMAC:
+   return OSSL_DIGEST_NAME_SHA1;
+   case RTE_CRYPTO_AUTH_SHA224_HMAC:
+   return OSSL_DIGEST_NAME_SHA2_224;
+   case RTE_CRYPTO_AUTH_SHA256_HMAC:
+   return OSSL_DIGEST_NAME_SHA2_256;
+   case RTE_CRYPTO_AUTH_SHA384_HMAC:
+   return OSSL_DIGEST_NAME_SHA2_384;
+   case RTE_CRYPTO_AUTH_SHA512_HMAC:
+   return OSSL_DIGEST_NAME_SHA2_512;
+   default:
+   return NULL;
+   }
+}
+#endif
+
 static int cryptodev_openssl_remove(struct rte_vdev_device *vdev);
 
 
/**/
@@ -580,6 +635,40 @@ openssl_set_session_auth_parameters(struct openssl_session 
*sess,
sess->auth.auth.ctx = EVP_MD_CTX_create();
break;
 
+# if (OPENSSL_VERSION_NUMBER >= 0x3000L)
+   case RTE_CRYPTO_AUTH_MD5_HMAC:
+   case RTE_CRYPTO_AUTH_SHA1_HMAC:
+   case RTE_CRYPTO_AUTH_SHA224_HMAC:
+   case RTE_CRYPTO_AUTH_SHA256_HMAC:
+   case RTE_CRYPTO_AUTH_SHA384_HMAC:
+   case RTE_CRYPTO_AUTH_SHA512_HMAC:
+   sess->auth.mode = OPE

[PATCH] app/testpmd: fix build without drivers

[Thomas Monjalon]

When ixgbe and bnxt are disabled, compilation was failing:

app/test-pmd/cmdline.c:9396:11: error:
variable 'vf_rxmode' set but not used

Fixes: 4cfe399f6550 ("net/bnxt: support to set VF rxmode")
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
 app/test-pmd/cmdline.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b4ba8da2b0..7ab0575e64 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9409,6 +9409,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
}
 
RTE_SET_USED(is_on);
+   RTE_SET_USED(vf_rxmode);
 
 #ifdef RTE_NET_IXGBE
if (ret == -ENOTSUP)
-- 
2.34.1

Re: [PATCH] net/mlx5: support matching optional fields of GRE

[Thomas Monjalon]

21/02/2022 04:00, Sean Zhang (Networking SW):
> Hi Thomas,
> 
> > -Original Message-
> > From: Thomas Monjalon 
> > Sent: Thursday, February 17, 2022 4:34 PM
> > To: Matan Azrad ; Slava Ovsiienko
> > ; Sean Zhang (Networking SW)
> > 
> > Cc: dev@dpdk.org
> > Subject: Re: [PATCH] net/mlx5: support matching optional fields of GRE
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > 17/02/2022 07:27, Sean Zhang:
> > > This patch adds matching on the optional fields
> > > (checksum/key/sequence) of GRE header. The matching on checksum and
> > > sequence fields requests support from rdma-core with the capability of
> > misc5 and tunnel_header 0-3.
> > >
> > > For patterns without checksum and sequence specified, keep using misc
> > > for matching as before, but for patterns with checksum or sequence,
> > > validate capability first and then use misc5 for the matching.
> > >
> > > Signed-off-by: Sean Zhang 
> > > Acked-by: Slava Ovsiienko 
> > >
> > > ---
> > > v3 - some code style change
> > > v2 - replace default mask with nic mask
> > > ---
> > >  doc/guides/nics/mlx5.rst |  10 +++
> > >  drivers/common/mlx5/mlx5_devx_cmds.c |   3 +
> > >  drivers/net/mlx5/linux/mlx5_os.c |   2 +
> > >  drivers/net/mlx5/mlx5.h  |   1 +
> > >  drivers/net/mlx5/mlx5_flow.c | 101
> > +
> > >  drivers/net/mlx5/mlx5_flow.h |   6 ++
> > >  drivers/net/mlx5/mlx5_flow_dv.c  | 121
> > +++
> > >  7 files changed, 244 insertions(+)
> > 
> > Should we add a line in the release notes?
> > 
> 
> This patch is v3 of the forth patch of patch set: 
> https://patches.dpdk.org/project/dpdk/cover/20220211014530.77711-1-xiazh...@nvidia.com/
> The release notes changed in the second patch of the patch set and applied in 
> v2.
> 
> --- a/doc/guides/rel_notes/release_22_03.rst
> +++ b/doc/guides/rel_notes/release_22_03.rst
> @@ -87,6 +87,11 @@  New Features
>  
>The new API ``rte_event_eth_rx_adapter_event_port_get()`` was added.
>  
> +* **Added rte_flow support for matching GRE optional fields.**
> +
> +  * Added ``gre_option`` item in rte_flow to support checksum/key/sequence
> +matching in GRE packets.
> +

OK but it is missing a line for mlx5 features.
I'm adding it while merging.

Re: [v4] net/mlx5: support matching optional fields of GRE

[Thomas Monjalon]

25/02/2022 02:14, Sean Zhang:
> This patch adds matching on the optional fields (checksum/key/sequence)
> of GRE header. The matching on checksum and sequence fields requests
> support from rdma-core with the capability of misc5 and tunnel_header 0-3.
> 
> For patterns without checksum and sequence specified, keep using misc for
> matching as before, but for patterns with checksum or sequence, validate
> capability first and then use misc5 for the matching.
> 
> Signed-off-by: Sean Zhang 
> Acked-by: Viacheslav Ovsiienko 

Applied in next-net-mlx with a release notes addition.

Re: [PATCH] app/testpmd: fix raw encap of GENEVE option

[Ferruh Yigit]

On 2/24/2022 7:02 AM, Bing Zhao wrote:

The structure "rte_flow_item_geneve_opt" is not a protocol header of
geneve tunnel option from rfc8926. The field "data" is a pointer
which points to the actual variable-length option data. So the
structure is not packed.

There is 4 bytes hole before the pointer in a 64-bit system. The
option header is just 4 bytes. When using offsetof() to get the
fixed part's size of option header, the wrong value 8 was got. When
constructing the encap header, a wrong size and offset was used due
to this hole.

With this commit, the fixed part's size is calculated explicitly
based on all fields.

Fixes: 55c074f3ba1d ("app/testpmd: support GENEVE option item")
Cc: viachesl...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Bing Zhao 
Reviewed-by: Viacheslav Ovsiienko 


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

Re: [PATCH] app/testpmd: fix build without drivers

[Bruce Richardson]

On Fri, Feb 25, 2022 at 04:26:53PM +0100, Thomas Monjalon wrote:
> When ixgbe and bnxt are disabled, compilation was failing:
> 
> app/test-pmd/cmdline.c:9396:11: error:
>   variable 'vf_rxmode' set but not used
> 
> Fixes: 4cfe399f6550 ("net/bnxt: support to set VF rxmode")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  app/test-pmd/cmdline.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index b4ba8da2b0..7ab0575e64 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -9409,6 +9409,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
>   }
>  
>   RTE_SET_USED(is_on);
> + RTE_SET_USED(vf_rxmode);
>  
Checking the code, I see the issue and the fix looks correct. However,
doing some basic builds disabling the relevant drivers, and all drivers, in
fact, I fail to reproduce the actual error message. Does this error only
occur at lower optimization levels, or only using clang or similar?

Acked-by: Bruce Richardson 

[PATCH v6] eal: fix rte_memcpy strict aliasing/alignment bugs

[Luc Pelletier]

Calls to rte_memcpy for 1 < n < 16 could result in unaligned
loads/stores, which is undefined behaviour according to the C
standard, and strict aliasing violations.

The code was changed to use a packed structure that allows aliasing
(using the __may_alias__ attribute) to perform the load/store
operations. This results in code that has the same performance as the
original code and that is also C standard-compliant.

Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li 
Cc: sta...@dpdk.org

Signed-off-by: Luc Pelletier 
---
v6:
* Refocus to fix strict aliasing problems discovered following
discussions in this thread.
* Modified the code to use __may_alias__ and packed structure. This fixes
both the undefined behaviour of unaligned access (which is not the main
concern), and also fixes the strict aliasing violations (which can cause
major bugs, as demonstrated in a previous message in this thread).
* Renamed new function from rte_mov15_or_less_unaligned to
rte_mov15_or_less.
* Modified code that copies <= 15 bytes to call rte_mov15_or_less.

v5:
* Replaced assembly with pure C code that uses a packed structure to make
unaligned loads conform to C standard.

v4:
* Added volatile to asm statements, which is required under gcc.

v3:
* Removed for loop and went back to using assembly.

v2:
* Replaced assembly with a regular for loop that copies bytes one by
one.

v1:
* Fix undefined behaviour of unaligned stores/loads by using assembly
to perform stores/loads.

 lib/eal/x86/include/rte_memcpy.h | 133 ---
 1 file changed, 51 insertions(+), 82 deletions(-)

diff --git a/lib/eal/x86/include/rte_memcpy.h b/lib/eal/x86/include/rte_memcpy.h
index 1b6c6e585f..360b7e069e 100644
--- a/lib/eal/x86/include/rte_memcpy.h
+++ b/lib/eal/x86/include/rte_memcpy.h
@@ -45,6 +45,52 @@ extern "C" {
 static __rte_always_inline void *
 rte_memcpy(void *dst, const void *src, size_t n);
 
+/**
+ * Copy bytes from one location to another,
+ * locations should not overlap.
+ * Use with n <= 15.
+ */
+static __rte_always_inline void *
+rte_mov15_or_less(void *dst, const void *src, size_t n)
+{
+   /**
+* Use the following structs to avoid violating C standard
+* alignment requirements and to avoid strict aliasing bugs
+*/
+   struct rte_uint64_alias {
+   uint64_t val;
+   } __attribute__((__may_alias__, __packed__));
+   struct rte_uint32_alias {
+   uint32_t val;
+   } __attribute__((__may_alias__, __packed__));
+   struct rte_uint16_alias {
+   uint16_t val;
+   } __attribute__((__may_alias__, __packed__));
+
+   void *ret = dst;
+   if (n & 8) {
+   ((struct rte_uint64_alias *)dst)->val =
+   ((const struct rte_uint64_alias *)src)->val;
+   src = (const uint64_t *)src + 1;
+   dst = (uint64_t *)dst + 1;
+   }
+   if (n & 4) {
+   ((struct rte_uint32_alias *)dst)->val =
+   ((const struct rte_uint32_alias *)src)->val;
+   src = (const uint32_t *)src + 1;
+   dst = (uint32_t *)dst + 1;
+   }
+   if (n & 2) {
+   ((struct rte_uint16_alias *)dst)->val =
+   ((const struct rte_uint16_alias *)src)->val;
+   src = (const uint16_t *)src + 1;
+   dst = (uint16_t *)dst + 1;
+   }
+   if (n & 1)
+   *(uint8_t *)dst = *(const uint8_t *)src;
+   return ret;
+}
+
 #if defined __AVX512F__ && defined RTE_MEMCPY_AVX512
 
 #define ALIGNMENT_MASK 0x3F
@@ -171,8 +217,6 @@ rte_mov512blocks(uint8_t *dst, const uint8_t *src, size_t n)
 static __rte_always_inline void *
 rte_memcpy_generic(void *dst, const void *src, size_t n)
 {
-   uintptr_t dstu = (uintptr_t)dst;
-   uintptr_t srcu = (uintptr_t)src;
void *ret = dst;
size_t dstofss;
size_t bits;
@@ -181,24 +225,7 @@ rte_memcpy_generic(void *dst, const void *src, size_t n)
 * Copy less than 16 bytes
 */
if (n < 16) {
-   if (n & 0x01) {
-   *(uint8_t *)dstu = *(const uint8_t *)srcu;
-   srcu = (uintptr_t)((const uint8_t *)srcu + 1);
-   dstu = (uintptr_t)((uint8_t *)dstu + 1);
-   }
-   if (n & 0x02) {
-   *(uint16_t *)dstu = *(const uint16_t *)srcu;
-   srcu = (uintptr_t)((const uint16_t *)srcu + 1);
-   dstu = (uintptr_t)((uint16_t *)dstu + 1);
-   }
-   if (n & 0x04) {
-   *(uint32_t *)dstu = *(const uint32_t *)srcu;
-   srcu = (uintptr_t)((const uint32_t *)srcu + 1);
-   dstu = (uintptr_t)((uint32_t *)dstu + 1);
-   }
-   if (n & 0x08)
-   *(uint64_t *)dstu = *(const uint64_t *)srcu;
-   return r

Re: [PATCH] eal: fix unaligned loads/stores in rte_memcpy_aligned

[Luc Pelletier]

Hi,

This patch can be abandoned. As indicated in another thread
(http://mails.dpdk.org/archives/dev/2022-February/234889.html), there
is no requirement/desire to make this change.

Thanks.

Le sam. 15 janv. 2022 à 14:39, Luc Pelletier  a écrit :
>
> Calls to rte_memcpy_aligned could result in unaligned loads/stores for
> 1 < n < 16. This is undefined behavior according to the C standard,
> and it gets flagged by the clang undefined behavior sanitizer.
>
> rte_memcpy_aligned is called with aligned src and dst addresses. When
> n is odd, the code would copy a single byte first, increment src/dst,
> then, depending on the value of n, would cast src/dst to a qword, dword
> or word pointer. This results in an unaligned load/store. Reversing the
> order of the casts & copies (ie. copying a qword first, dword second,
> etc.) fixes the issue.
>
> Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
> Cc: Xiaoyun Li 
> Cc: sta...@dpdk.org
>
> Signed-off-by: Luc Pelletier 
> ---
>  lib/eal/x86/include/rte_memcpy.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/lib/eal/x86/include/rte_memcpy.h 
> b/lib/eal/x86/include/rte_memcpy.h
> index 1b6c6e585f..a4eb1316b6 100644
> --- a/lib/eal/x86/include/rte_memcpy.h
> +++ b/lib/eal/x86/include/rte_memcpy.h
> @@ -818,25 +818,25 @@ rte_memcpy_aligned(void *dst, const void *src, size_t n)
>  {
> void *ret = dst;
>
> -   /* Copy size <= 16 bytes */
> +   /* Copy size < 16 bytes */
> if (n < 16) {
> -   if (n & 0x01) {
> -   *(uint8_t *)dst = *(const uint8_t *)src;
> -   src = (const uint8_t *)src + 1;
> -   dst = (uint8_t *)dst + 1;
> -   }
> -   if (n & 0x02) {
> -   *(uint16_t *)dst = *(const uint16_t *)src;
> -   src = (const uint16_t *)src + 1;
> -   dst = (uint16_t *)dst + 1;
> +   if (n & 0x08) {
> +   *(uint64_t *)dst = *(const uint64_t *)src;
> +   src = (const uint64_t *)src + 1;
> +   dst = (uint64_t *)dst + 1;
> }
> if (n & 0x04) {
> *(uint32_t *)dst = *(const uint32_t *)src;
> src = (const uint32_t *)src + 1;
> dst = (uint32_t *)dst + 1;
> }
> -   if (n & 0x08)
> -   *(uint64_t *)dst = *(const uint64_t *)src;
> +   if (n & 0x02) {
> +   *(uint16_t *)dst = *(const uint16_t *)src;
> +   src = (const uint16_t *)src + 1;
> +   dst = (uint16_t *)dst + 1;
> +   }
> +   if (n & 0x01)
> +   *(uint8_t *)dst = *(const uint8_t *)src;
>
> return ret;
> }
> --
> 2.25.1
>

[PATCH v7] eal: fix rte_memcpy strict aliasing/alignment bugs

[Luc Pelletier]

Calls to rte_memcpy for 1 < n < 16 could result in unaligned
loads/stores, which is undefined behaviour according to the C
standard, and strict aliasing violations.

The code was changed to use a packed structure that allows aliasing
(using the __may_alias__ attribute) to perform the load/store
operations. This results in code that has the same performance as the
original code and that is also C standards-compliant.

Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
Cc: Xiaoyun Li 
Cc: sta...@dpdk.org

Signed-off-by: Luc Pelletier 
---
v7:
* Fix coding style issue by adding new __rte_may_alias macro rather
than directly use __attribute__

v6:
* Refocus to fix strict aliasing problems discovered following
discussions in this thread.
* Modified the code to use __may_alias__ and packed structure. This fixes
both the undefined behaviour of unaligned access (which is not the main
concern), and also fixes the strict aliasing violations (which can cause
major bugs, as demonstrated in a previous message in this thread).
* Renamed new function from rte_mov15_or_less_unaligned to
rte_mov15_or_less.
* Modified code that copies <= 15 bytes to call rte_mov15_or_less.

v5:
* Replaced assembly with pure C code that uses a packed structure to make
unaligned loads conform to C standard.

v4:
* Added volatile to asm statements, which is required under gcc.

v3:
* Removed for loop and went back to using assembly.

v2:
* Replaced assembly with a regular for loop that copies bytes one by
one.

v1:
* Fix undefined behaviour of unaligned stores/loads by using assembly
to perform stores/loads.

 lib/eal/include/rte_common.h |   5 ++
 lib/eal/x86/include/rte_memcpy.h | 133 ---
 2 files changed, 56 insertions(+), 82 deletions(-)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 4a399cc7c8..2f1ec69f3d 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -85,6 +85,11 @@ typedef uint16_t unaligned_uint16_t;
  */
 #define __rte_packed __attribute__((__packed__))
 
+/**
+ * Macro to mark a type that is not subject to type-based aliasing rules
+ */
+#define __rte_may_alias __attribute__((__may_alias__))
+
 /*** Macro to mark functions and fields scheduled for removal */
 #define __rte_deprecated   __attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)  __attribute__((__deprecated__(msg)))
diff --git a/lib/eal/x86/include/rte_memcpy.h b/lib/eal/x86/include/rte_memcpy.h
index 1b6c6e585f..18aa4e43a7 100644
--- a/lib/eal/x86/include/rte_memcpy.h
+++ b/lib/eal/x86/include/rte_memcpy.h
@@ -45,6 +45,52 @@ extern "C" {
 static __rte_always_inline void *
 rte_memcpy(void *dst, const void *src, size_t n);
 
+/**
+ * Copy bytes from one location to another,
+ * locations should not overlap.
+ * Use with n <= 15.
+ */
+static __rte_always_inline void *
+rte_mov15_or_less(void *dst, const void *src, size_t n)
+{
+   /**
+* Use the following structs to avoid violating C standard
+* alignment requirements and to avoid strict aliasing bugs
+*/
+   struct rte_uint64_alias {
+   uint64_t val;
+   } __rte_packed __rte_may_alias;
+   struct rte_uint32_alias {
+   uint32_t val;
+   } __rte_packed __rte_may_alias;
+   struct rte_uint16_alias {
+   uint16_t val;
+   } __rte_packed __rte_may_alias;
+
+   void *ret = dst;
+   if (n & 8) {
+   ((struct rte_uint64_alias *)dst)->val =
+   ((const struct rte_uint64_alias *)src)->val;
+   src = (const uint64_t *)src + 1;
+   dst = (uint64_t *)dst + 1;
+   }
+   if (n & 4) {
+   ((struct rte_uint32_alias *)dst)->val =
+   ((const struct rte_uint32_alias *)src)->val;
+   src = (const uint32_t *)src + 1;
+   dst = (uint32_t *)dst + 1;
+   }
+   if (n & 2) {
+   ((struct rte_uint16_alias *)dst)->val =
+   ((const struct rte_uint16_alias *)src)->val;
+   src = (const uint16_t *)src + 1;
+   dst = (uint16_t *)dst + 1;
+   }
+   if (n & 1)
+   *(uint8_t *)dst = *(const uint8_t *)src;
+   return ret;
+}
+
 #if defined __AVX512F__ && defined RTE_MEMCPY_AVX512
 
 #define ALIGNMENT_MASK 0x3F
@@ -171,8 +217,6 @@ rte_mov512blocks(uint8_t *dst, const uint8_t *src, size_t n)
 static __rte_always_inline void *
 rte_memcpy_generic(void *dst, const void *src, size_t n)
 {
-   uintptr_t dstu = (uintptr_t)dst;
-   uintptr_t srcu = (uintptr_t)src;
void *ret = dst;
size_t dstofss;
size_t bits;
@@ -181,24 +225,7 @@ rte_memcpy_generic(void *dst, const void *src, size_t n)
 * Copy less than 16 bytes
 */
if (n < 16) {
-   if (n & 0x01) {
-   *(uint8_t *)dstu = *(const uint8_t *)srcu;
-   srcu = (ui

Re: [PATCH] app/testpmd: fix build without drivers

[Thomas Monjalon]

25/02/2022 16:50, Bruce Richardson:
> On Fri, Feb 25, 2022 at 04:26:53PM +0100, Thomas Monjalon wrote:
> > When ixgbe and bnxt are disabled, compilation was failing:
> > 
> > app/test-pmd/cmdline.c:9396:11: error:
> > variable 'vf_rxmode' set but not used
> > 
> > Fixes: 4cfe399f6550 ("net/bnxt: support to set VF rxmode")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Thomas Monjalon 
> > ---
> >  app/test-pmd/cmdline.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index b4ba8da2b0..7ab0575e64 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -9409,6 +9409,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
> > }
> >  
> > RTE_SET_USED(is_on);
> > +   RTE_SET_USED(vf_rxmode);
> >  
> Checking the code, I see the issue and the fix looks correct. However,
> doing some basic builds disabling the relevant drivers, and all drivers, in
> fact, I fail to reproduce the actual error message. Does this error only
> occur at lower optimization levels, or only using clang or similar?

I don't remember, probably clang only.

Re: [PATCH] app/testpmd: fix build without drivers

[Ajit Khaparde]

On Fri, Feb 25, 2022 at 7:50 AM Bruce Richardson
 wrote:
>
> On Fri, Feb 25, 2022 at 04:26:53PM +0100, Thomas Monjalon wrote:
> > When ixgbe and bnxt are disabled, compilation was failing:
> >
> > app/test-pmd/cmdline.c:9396:11: error:
> >   variable 'vf_rxmode' set but not used
> >
> > Fixes: 4cfe399f6550 ("net/bnxt: support to set VF rxmode")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Thomas Monjalon 
> > ---
> >  app/test-pmd/cmdline.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index b4ba8da2b0..7ab0575e64 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -9409,6 +9409,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
> >   }
> >
> >   RTE_SET_USED(is_on);
> > + RTE_SET_USED(vf_rxmode);
> >
> Checking the code, I see the issue and the fix looks correct. However,
> doing some basic builds disabling the relevant drivers, and all drivers, in
> fact, I fail to reproduce the actual error message. Does this error only
> occur at lower optimization levels, or only using clang or similar?
>
> Acked-by: Bruce Richardson 
Thanks

Acked-by: Ajit Khaparde 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] app/testpmd: fix build without drivers

[Ferruh Yigit]

On 2/25/2022 4:53 PM, Ajit Khaparde wrote:

On Fri, Feb 25, 2022 at 7:50 AM Bruce Richardson
 wrote:


On Fri, Feb 25, 2022 at 04:26:53PM +0100, Thomas Monjalon wrote:

When ixgbe and bnxt are disabled, compilation was failing:

app/test-pmd/cmdline.c:9396:11: error:
   variable 'vf_rxmode' set but not used

Fixes: 4cfe399f6550 ("net/bnxt: support to set VF rxmode")
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
  app/test-pmd/cmdline.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b4ba8da2b0..7ab0575e64 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9409,6 +9409,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
   }

   RTE_SET_USED(is_on);
+ RTE_SET_USED(vf_rxmode);


Checking the code, I see the issue and the fix looks correct. However,
doing some basic builds disabling the relevant drivers, and all drivers, in
fact, I fail to reproduce the actual error message. Does this error only
occur at lower optimization levels, or only using clang or similar?

Acked-by: Bruce Richardson 

Thanks

Acked-by: Ajit Khaparde 


Able to reproduce with clang.

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

Re: [PATCH v3] app/pdump: check lcore is not the maximum core

[Stephen Hemminger]

On Tue, 22 Feb 2022 11:02:24 +
Reshma Pattan  wrote:

> Check lcore id value is not the maximum core supported.
> Using lcore id without this check might cause
> out of bound access inside the rte_eal_wait_lcore.
> 
> Coverity issue: 375841
> Fixes: b2854d5317e8 ("app/pdump: support multi-core capture")
> Cc: vipin.vargh...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Reshma Pattan 
> ---
> v3: add new function to get next core id and validate it.
> ---
>  app/pdump/main.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/app/pdump/main.c b/app/pdump/main.c
> index 04a38e8911..e4e62811c9 100644
> --- a/app/pdump/main.c
> +++ b/app/pdump/main.c
> @@ -900,6 +900,15 @@ dump_packets_core(void *arg)
>   return 0;
>  }
>  
> +static inline void
> +get_next_core(uint32_t *lcore_id)
> +{
> + *lcore_id = rte_get_next_lcore(*lcore_id, 1, 0);
> + if (*lcore_id == RTE_MAX_LCORE)
> + rte_exit(EXIT_FAILURE,
> + "Max core limit %u reached for packet capture", 
> *lcore_id);
> +}
> +

This looks good, can I make a some suggestions.

Since function either exits or returns a good value, I would prefer
that it returned the lcore id. Avoiding call by reference if possible.

Also, the lcore is currently typed unsigned int in rte_lcore.h
therefore use that type?

Inline is certainly unnecessary here, not critical path and compiler
is likely to do it anyway.

Also, DPDK uses lcore for most places (rather than core) so use that name.

Result is:

static unsigned int
get_next_lcore(unsigned int lcore)
{
lcore = rte_get_next_lcore(lcore, 1, 0);
if (lcore >= RTE_MAX_LCORE)
"Max core limit %u reached for packet capture", lcore);
return lcore;
}

>  static inline void
>  dump_packets(void)
>  {
> @@ -930,12 +939,12 @@ dump_packets(void)
>   return;
>   }
>  
> - lcore_id = rte_get_next_lcore(lcore_id, 1, 0);
> + get_next_core(&lcore_id);
>  
>   for (i = 0; i < num_tuples; i++) {
>   rte_eal_remote_launch(dump_packets_core,
>   &pdump_t[i], lcore_id);
> - lcore_id = rte_get_next_lcore(lcore_id, 1, 0);
> + get_next_core(&lcore_id);
>  
>   if (rte_eal_wait_lcore(lcore_id) < 0)
>   rte_exit(EXIT_FAILURE, "failed to wait\n");

Re: [dpdk-dev v6] crypto/openssl: openssl 3.0 support on sym crypto routine

[Stephen Hemminger]

On Fri, 25 Feb 2022 23:13:56 +0800
Kai Ji  wrote:

> +cflags += ['-DOPENSSL_API_COMPAT=0x1010L']
> \ No newline at end of file

All files in DPDK should have newline at end of file.
How did this sneak in?

Re: [PATCH v3 0/6] mlx5: external RxQ support

[Thomas Monjalon]

> Michael Baum (6):
>   common/mlx5: consider local functions as internal
>   common/mlx5: glue device and PD importation
>   common/mlx5: add remote PD and CTX support
>   net/mlx5: optimize RxQ/TxQ control structure
>   net/mlx5: add external RxQ mapping API
>   net/mlx5: support queue/RSS action for external RxQ

Applied in next-net-mlx, thanks.

[PATCH 1/2] remove extra blank line at eof

[Stephen Hemminger]

These source files all had unnecessary blank line at end of file.

Signed-off-by: Stephen Hemminger 
---
 drivers/common/iavf/iavf_adminq.c | 1 -
 drivers/common/mlx5/mlx5_common_log.h | 1 -
 drivers/net/cxgbe/smt.h   | 1 -
 drivers/net/dpaa2/mc/dpni.c   | 1 -
 drivers/net/hinic/hinic_pmd_flow.c| 1 -
 drivers/net/iavf/iavf_generic_flow.c  | 1 -
 drivers/net/ionic/ionic_ethdev.h  | 1 -
 drivers/net/ionic/ionic_mac_api.c | 1 -
 drivers/net/mlx5/linux/meson.build| 1 -
 drivers/net/mlx5/mlx5_flow_dv.c   | 1 -
 drivers/net/mlx5/mlx5_rx.c| 1 -
 drivers/net/netvsc/meson.build| 1 -
 drivers/net/nfp/nfp_rxtx.h| 1 -
 drivers/net/ngbe/ngbe_ptypes.c| 1 -
 drivers/net/octeontx_ep/meson.build   | 1 -
 drivers/net/octeontx_ep/otx2_ep_vf.h  | 1 -
 drivers/net/txgbe/txgbe_flow.c| 1 -
 drivers/net/txgbe/txgbe_ptypes.c  | 1 -
 drivers/net/txgbe/txgbe_rxtx.c| 1 -
 drivers/regex/cn9k/meson.build| 1 -
 lib/ethdev/ethdev_driver.c| 1 -
 lib/ethdev/ethdev_private.c   | 1 -
 22 files changed, 22 deletions(-)

diff --git a/drivers/common/iavf/iavf_adminq.c 
b/drivers/common/iavf/iavf_adminq.c
index 9c36e8908e59..8b305c0fe3eb 100644
--- a/drivers/common/iavf/iavf_adminq.c
+++ b/drivers/common/iavf/iavf_adminq.c
@@ -963,4 +963,3 @@ enum iavf_status iavf_clean_arq_element(struct iavf_hw *hw,
 
return ret_code;
 }
-
diff --git a/drivers/common/mlx5/mlx5_common_log.h 
b/drivers/common/mlx5/mlx5_common_log.h
index 26b13fedaf2e..cabae3866b58 100644
--- a/drivers/common/mlx5/mlx5_common_log.h
+++ b/drivers/common/mlx5/mlx5_common_log.h
@@ -18,4 +18,3 @@ extern int mlx5_common_logtype;
PMD_DRV_LOG_CPAREN)
 
 #endif /* RTE_PMD_MLX5_COMMON_LOG_H_ */
-
diff --git a/drivers/net/cxgbe/smt.h b/drivers/net/cxgbe/smt.h
index e6e8aea964e1..a70e3a208575 100644
--- a/drivers/net/cxgbe/smt.h
+++ b/drivers/net/cxgbe/smt.h
@@ -42,4 +42,3 @@ struct smt_entry *cxgbe_smt_alloc_switching(struct 
rte_eth_dev *dev, u8 *smac);
 void cxgbe_smt_release(struct smt_entry *e);
 
 #endif  /* __CXGBE_SMT_H_ */
-
diff --git a/drivers/net/dpaa2/mc/dpni.c b/drivers/net/dpaa2/mc/dpni.c
index 7a2bc15eb4da..c5cc9302f987 100644
--- a/drivers/net/dpaa2/mc/dpni.c
+++ b/drivers/net/dpaa2/mc/dpni.c
@@ -3118,4 +3118,3 @@ int dpni_set_port_cfg(struct fsl_mc_io *mc_io, uint32_t 
cmd_flags,
/* send command to MC */
return mc_send_command(mc_io, &cmd);
 }
-
diff --git a/drivers/net/hinic/hinic_pmd_flow.c 
b/drivers/net/hinic/hinic_pmd_flow.c
index 2cf24ebcf64e..358b372e07e8 100644
--- a/drivers/net/hinic/hinic_pmd_flow.c
+++ b/drivers/net/hinic/hinic_pmd_flow.c
@@ -3311,4 +3311,3 @@ const struct rte_flow_ops hinic_flow_ops = {
.destroy = hinic_flow_destroy,
.flush = hinic_flow_flush,
 };
-
diff --git a/drivers/net/iavf/iavf_generic_flow.c 
b/drivers/net/iavf/iavf_generic_flow.c
index 2befa125ac90..d1abcbd54266 100644
--- a/drivers/net/iavf/iavf_generic_flow.c
+++ b/drivers/net/iavf/iavf_generic_flow.c
@@ -2334,4 +2334,3 @@ iavf_flow_query(struct rte_eth_dev *dev,
}
return ret;
 }
-
diff --git a/drivers/net/ionic/ionic_ethdev.h b/drivers/net/ionic/ionic_ethdev.h
index 652f28c97d57..9304e170dec3 100644
--- a/drivers/net/ionic/ionic_ethdev.h
+++ b/drivers/net/ionic/ionic_ethdev.h
@@ -23,4 +23,3 @@
 int ionic_dev_link_update(struct rte_eth_dev *eth_dev, int wait_to_complete);
 
 #endif /* _IONIC_ETHDEV_H_ */
-
diff --git a/drivers/net/ionic/ionic_mac_api.c 
b/drivers/net/ionic/ionic_mac_api.c
index c0ea042bc5d0..411d84b57806 100644
--- a/drivers/net/ionic/ionic_mac_api.c
+++ b/drivers/net/ionic/ionic_mac_api.c
@@ -60,4 +60,3 @@ ionic_set_mac_type(struct ionic_hw *hw)
 
return err;
 }
-
diff --git a/drivers/net/mlx5/linux/meson.build 
b/drivers/net/mlx5/linux/meson.build
index 553024135601..e541d25c183d 100644
--- a/drivers/net/mlx5/linux/meson.build
+++ b/drivers/net/mlx5/linux/meson.build
@@ -11,4 +11,3 @@ sources += files(
 'mlx5_vlan_os.c',
 'mlx5_flow_os.c',
 )
-
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ef9c66eddf06..b430754ea918 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -18284,4 +18284,3 @@ const struct mlx5_flow_driver_ops mlx5_flow_dv_drv_ops 
= {
 };
 
 #endif /* HAVE_IBV_FLOW_DV_SUPPORT */
-
diff --git a/drivers/net/mlx5/mlx5_rx.c b/drivers/net/mlx5/mlx5_rx.c
index 11ea935d72f0..e5eea0ad949e 100644
--- a/drivers/net/mlx5/mlx5_rx.c
+++ b/drivers/net/mlx5/mlx5_rx.c
@@ -1187,4 +1187,3 @@ mlx5_check_vec_rx_support(struct rte_eth_dev *dev 
__rte_unused)
 {
return -ENOTSUP;
 }
-
diff --git a/drivers/net/netvsc/meson.build b/drivers/net/netvsc/meson.build
index 399400dd0114..bb6225d05a10 100644
--- a/drivers/net/netvsc/meson.build
+++ b/drivers/net/netvsc/meson.build
@@ -15,4 +15,3 @@ sources = files(
 'hn_rxtx.c',
 'hn_vf.c',
 )
-
diff --git a/drivers/

[PATCH 2/2] examples: add missing newline at eof

[Stephen Hemminger]

The text file did not end with newline.

Signed-off-by: Stephen Hemminger 
---
 examples/flow_classify/ipv4_rules_file.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/flow_classify/ipv4_rules_file.txt 
b/examples/flow_classify/ipv4_rules_file.txt
index dfa0631fcc09..cd5215736aaf 100644
--- a/examples/flow_classify/ipv4_rules_file.txt
+++ b/examples/flow_classify/ipv4_rules_file.txt
@@ -11,4 +11,4 @@
 6.7.8.9/16 192.168.0.36/16 10 : 0x 11 : 0x 6/0xfe 7
 6.7.8.9/8 192.168.0.36/8 10 : 0x 11 : 0x 6/0xfe 8
 #error rules
-#9.8.7.6/8 192.168.0.36/8 10 : 0x 11 : 0x 6/0xfe 9
\ No newline at end of file
+#9.8.7.6/8 192.168.0.36/8 10 : 0x 11 : 0x 6/0xfe 9
-- 
2.34.1

Re: [v4] net/mlx5: support matching optional fields of GRE

[Ferruh Yigit]

On 2/25/2022 1:14 AM, Sean Zhang wrote:

This patch adds matching on the optional fields (checksum/key/sequence)
of GRE header. The matching on checksum and sequence fields requests
support from rdma-core with the capability of misc5 and tunnel_header 0-3.

For patterns without checksum and sequence specified, keep using misc for
matching as before, but for patterns with checksum or sequence, validate
capability first and then use misc5 for the matching.

Signed-off-by: Sean Zhang 
Acked-by: Viacheslav Ovsiienko 



doc is missing:

./devtools/check-doc-vs-code.sh
rte_flow doc out of sync for mlx5
item gre_option

I can add in next-net while merging, if this is the only issue.

Re: [EXT] [PATCH] crypto: fix misspelled key in qt format

[Thomas Monjalon]

18/02/2022 07:11, Kusztal, ArkadiuszX:
> From: Akhil Goyal 
> > Fix ABI warning.
> > Add libabigail.abiignore rule.
> 
> I think what is worth noticing is a fact that after "random 'k' patch" 
> addition of
> [suppress_type]
> name = rte_crypto_asym_op
> this problem does not show up.
> 
> But I think it is safer to send addition of
> [suppress_type]
> name = rte_crypto_rsa_priv_key_type
> anyway.
> Will send v2.

I don't understand why adding this rule,
and the comment does say nothing about it:
"Ignore name change of rsa qt key type"

The ABI check is fine without above because of this existing exception:

; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op

So I will just drop the unjustified additional exception while pulling.

Next time, please make sure such ABI exception is approved by more maintainers.

Re: [PATCH v3 1/6] common/mlx5: consider local functions as internal

[Ferruh Yigit]

On 2/24/2022 11:25 PM, Michael Baum wrote:

The functions which are not explicitly marked as internal
were exported because the local catch-all rule was missing in the
version script.
After adding the missing rule, all local functions are hidden.
The function mlx5_get_device_guid is used in another library,
so it needs to be exported (as internal).

Because the local functions were exported as non-internal
in DPDK 21.11, any change in these functions would break the ABI.
An ABI exception is added for this library, considering that all
functions are either local or internal.



When a function is not listed explicitly in .map file, it shouldn't
be exported at all.

So I am not sure if this exception is required, did you get
warning for tool, or is this theoretical?

cc'ed David and Ray for comment.


Signed-off-by: Michael Baum 
Acked-by: Matan Azrad 



<...>

[PATCH] doc/guides/cryptodev/features: add missing newline at eof

[Stephen Hemminger]

Even these are ini files, they should still have new line at
end of file.

Signed-off-by: Stephen Hemminger 
---
 doc/guides/cryptodevs/features/aesni_mb.ini | 2 +-
 doc/guides/cryptodevs/features/armv8.ini| 2 +-
 doc/guides/cryptodevs/features/bcmfs.ini| 2 +-
 doc/guides/cryptodevs/features/caam_jr.ini  | 2 +-
 doc/guides/cryptodevs/features/ccp.ini  | 2 +-
 doc/guides/cryptodevs/features/cn10k.ini| 2 +-
 doc/guides/cryptodevs/features/cn9k.ini | 2 +-
 doc/guides/cryptodevs/features/null.ini | 2 +-
 doc/guides/cryptodevs/features/qat.ini  | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/doc/guides/cryptodevs/features/aesni_mb.ini 
b/doc/guides/cryptodevs/features/aesni_mb.ini
index e616f13d504e..3c648a391ed7 100644
--- a/doc/guides/cryptodevs/features/aesni_mb.ini
+++ b/doc/guides/cryptodevs/features/aesni_mb.ini
@@ -80,4 +80,4 @@ CHACHA20-POLY1305 = Y
 ;
 [OS]
 Linux = Y
-FreeBSD = Y
\ No newline at end of file
+FreeBSD = Y
diff --git a/doc/guides/cryptodevs/features/armv8.ini 
b/doc/guides/cryptodevs/features/armv8.ini
index 33c1291ce6e9..ae3f7277e90b 100644
--- a/doc/guides/cryptodevs/features/armv8.ini
+++ b/doc/guides/cryptodevs/features/armv8.ini
@@ -38,4 +38,4 @@ SHA256 HMAC  = Y
 ;
 [OS]
 Linux = Y
-FreeBSD = Y
\ No newline at end of file
+FreeBSD = Y
diff --git a/doc/guides/cryptodevs/features/bcmfs.ini 
b/doc/guides/cryptodevs/features/bcmfs.ini
index 5def12f8a595..d8dcaee28a22 100644
--- a/doc/guides/cryptodevs/features/bcmfs.ini
+++ b/doc/guides/cryptodevs/features/bcmfs.ini
@@ -64,4 +64,4 @@ AES CCM (256) = Y
 ;
 [OS]
 Linux = Y
-FreeBSD = Y
\ No newline at end of file
+FreeBSD = Y
diff --git a/doc/guides/cryptodevs/features/caam_jr.ini 
b/doc/guides/cryptodevs/features/caam_jr.ini
index ba6d10c88093..a2fe9dbba014 100644
--- a/doc/guides/cryptodevs/features/caam_jr.ini
+++ b/doc/guides/cryptodevs/features/caam_jr.ini
@@ -54,4 +54,4 @@ AES GCM (256) = Y
 ; Supported Operating systems of the 'dpaa2_sec' crypto driver.
 ;
 [OS]
-Linux = Y
\ No newline at end of file
+Linux = Y
diff --git a/doc/guides/cryptodevs/features/ccp.ini 
b/doc/guides/cryptodevs/features/ccp.ini
index 53abd2b68edc..0734ace9d0a6 100644
--- a/doc/guides/cryptodevs/features/ccp.ini
+++ b/doc/guides/cryptodevs/features/ccp.ini
@@ -68,4 +68,4 @@ AES GCM (256) = Y
 ; Supported Operating systems of the 'ccp' crypto driver.
 ;
 [OS]
-Linux = Y
\ No newline at end of file
+Linux = Y
diff --git a/doc/guides/cryptodevs/features/cn10k.ini 
b/doc/guides/cryptodevs/features/cn10k.ini
index c8193c2ccae7..166fca5adb2b 100644
--- a/doc/guides/cryptodevs/features/cn10k.ini
+++ b/doc/guides/cryptodevs/features/cn10k.ini
@@ -87,4 +87,4 @@ ECPM= Y
 ; Supported Operating systems of the 'cn10k' crypto driver.
 ;
 [OS]
-Linux = Y
\ No newline at end of file
+Linux = Y
diff --git a/doc/guides/cryptodevs/features/cn9k.ini 
b/doc/guides/cryptodevs/features/cn9k.ini
index f215ee045bb5..98ad7cf10aac 100644
--- a/doc/guides/cryptodevs/features/cn9k.ini
+++ b/doc/guides/cryptodevs/features/cn9k.ini
@@ -86,4 +86,4 @@ ECPM= Y
 ; Supported Operating systems of the 'cn9k' crypto driver.
 ;
 [OS]
-Linux = Y
\ No newline at end of file
+Linux = Y
diff --git a/doc/guides/cryptodevs/features/null.ini 
b/doc/guides/cryptodevs/features/null.ini
index ae09cdd1c018..6005fe2b8bf2 100644
--- a/doc/guides/cryptodevs/features/null.ini
+++ b/doc/guides/cryptodevs/features/null.ini
@@ -35,4 +35,4 @@ NULL = Y
 ;
 [OS]
 Linux = Y
-FreeBSD = Y
\ No newline at end of file
+FreeBSD = Y
diff --git a/doc/guides/cryptodevs/features/qat.ini 
b/doc/guides/cryptodevs/features/qat.ini
index bc50ecf032ca..b9755a757ef4 100644
--- a/doc/guides/cryptodevs/features/qat.ini
+++ b/doc/guides/cryptodevs/features/qat.ini
@@ -88,4 +88,4 @@ RSA   = Y
 ;
 [OS]
 Linux = Y
-FreeBSD = Y
\ No newline at end of file
+FreeBSD = Y
-- 
2.34.1

[PATCH] doc: add GRE option flow item to feature list

[Ferruh Yigit]

'gre_option' flow item was missing in the feature list, adding it.

Fixes: f61490bdf218 ("ethdev: support GRE optional fields")

Signed-off-by: Ferruh Yigit 
---
Cc: xiazh...@nvidia.com
---
 doc/guides/nics/features/default.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 0fcc64cac1b1..b1d18ac62cdc 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -93,6 +93,7 @@ geneve   =
 geneve_opt   =
 gre  =
 gre_key  =
+gre_option   =
 gtp  =
 gtpc =
 gtpu =
-- 
2.35.1

Re: [v4] net/mlx5: support matching optional fields of GRE

[Thomas Monjalon]

25/02/2022 18:55, Ferruh Yigit:
> On 2/25/2022 1:14 AM, Sean Zhang wrote:
> > This patch adds matching on the optional fields (checksum/key/sequence)
> > of GRE header. The matching on checksum and sequence fields requests
> > support from rdma-core with the capability of misc5 and tunnel_header 0-3.
> > 
> > For patterns without checksum and sequence specified, keep using misc for
> > matching as before, but for patterns with checksum or sequence, validate
> > capability first and then use misc5 for the matching.
> > 
> > Signed-off-by: Sean Zhang 
> > Acked-by: Viacheslav Ovsiienko 
> > 
> 
> doc is missing:
> 
> ./devtools/check-doc-vs-code.sh
> rte_flow doc out of sync for mlx5
>  item gre_option
> 
> I can add in next-net while merging, if this is the only issue.

Yes please

Re: [PATCH v3 1/6] common/mlx5: consider local functions as internal

[Thomas Monjalon]

25/02/2022 19:01, Ferruh Yigit:
> On 2/24/2022 11:25 PM, Michael Baum wrote:
> > The functions which are not explicitly marked as internal
> > were exported because the local catch-all rule was missing in the
> > version script.
> > After adding the missing rule, all local functions are hidden.
> > The function mlx5_get_device_guid is used in another library,
> > so it needs to be exported (as internal).
> > 
> > Because the local functions were exported as non-internal
> > in DPDK 21.11, any change in these functions would break the ABI.
> > An ABI exception is added for this library, considering that all
> > functions are either local or internal.
> > 
> 
> When a function is not listed explicitly in .map file, it shouldn't
> be exported at all.

It seems we need local:* to achieve this behaviour.
Few other libs are missing it. I plan to send a patch for them.

> So I am not sure if this exception is required, did you get
> warning for tool, or is this theoretical?

It is not theoritical, you can check with objdump:
objdump -T build/lib/librte_common_mlx5.so | sed -rn 's,^[[:xdigit:]]* g 
*(D[^0]*)[^ ]* *,\1,p'

I did not check the ABI tool without the exception.

Re: [PATCH] doc: add GRE option flow item to feature list

[Thomas Monjalon]

25/02/2022 19:27, Ferruh Yigit:
> 'gre_option' flow item was missing in the feature list, adding it.
> 
> Fixes: f61490bdf218 ("ethdev: support GRE optional fields")
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: Thomas Monjalon 

Re: [PATCH] doc: add GRE option flow item to feature list

[Ferruh Yigit]

On 2/25/2022 6:41 PM, Thomas Monjalon wrote:

25/02/2022 19:27, Ferruh Yigit:

'gre_option' flow item was missing in the feature list, adding it.

Fixes: f61490bdf218 ("ethdev: support GRE optional fields")

Signed-off-by: Ferruh Yigit 


Acked-by: Thomas Monjalon 



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

Re: [PATCH v3 1/6] common/mlx5: consider local functions as internal

[Ferruh Yigit]

On 2/25/2022 6:38 PM, Thomas Monjalon wrote:

25/02/2022 19:01, Ferruh Yigit:

On 2/24/2022 11:25 PM, Michael Baum wrote:

The functions which are not explicitly marked as internal
were exported because the local catch-all rule was missing in the
version script.
After adding the missing rule, all local functions are hidden.
The function mlx5_get_device_guid is used in another library,
so it needs to be exported (as internal).

Because the local functions were exported as non-internal
in DPDK 21.11, any change in these functions would break the ABI.
An ABI exception is added for this library, considering that all
functions are either local or internal.



When a function is not listed explicitly in .map file, it shouldn't
be exported at all.


It seems we need local:* to achieve this behaviour.
Few other libs are missing it. I plan to send a patch for them.



+1 for this patch, thanks.


So I am not sure if this exception is required, did you get
warning for tool, or is this theoretical?


It is not theoritical, you can check with objdump:
objdump -T build/lib/librte_common_mlx5.so | sed -rn 's,^[[:xdigit:]]* g 
*(D[^0]*)[^ ]* *,\1,p'

I did not check the ABI tool without the exception.



Yes tool complains with change [1], I will proceed with original patch.

[1]
29 Removed functions:

  [D] 'function int mlx5_auxiliary_get_pci_str(const rte_auxiliary_device*, 
char*, size_t)'{mlx5_auxiliary_get_pci_str}
  [D] 'function void mlx5_common_auxiliary_init()'
{mlx5_common_auxiliary_init}
  [D] 'function int mlx5_common_dev_dma_map(rte_device*, void*, uint64_t, 
size_t)'{mlx5_common_dev_dma_map}
  [D] 'function int mlx5_common_dev_dma_unmap(rte_device*, void*, uint64_t, 
size_t)'{mlx5_common_dev_dma_unmap}
  [D] 'function int mlx5_common_dev_probe(rte_device*)'
{mlx5_common_dev_probe}
  [D] 'function int mlx5_common_dev_remove(rte_device*)'
{mlx5_common_dev_remove}
  [D] 'function void mlx5_common_driver_on_register_pci(mlx5_class_driver*)'
{mlx5_common_driver_on_register_pci}
  [D] 'function void mlx5_common_pci_init()'{mlx5_common_pci_init}
  [D] 'function mlx5_mr* mlx5_create_mr_ext(void*, uintptr_t, size_t, int, 
mlx5_reg_mr_t)'{mlx5_create_mr_ext}
  [D] 'function bool mlx5_dev_pci_match(const mlx5_class_driver*, const 
rte_device*)'{mlx5_dev_pci_match}
  [D] 'function int mlx5_dev_to_pci_str(const rte_device*, char*, size_t)'
{mlx5_dev_to_pci_str}
  [D] 'function void mlx5_free_mr_by_addr(mlx5_mr_share_cache*, const char*, 
void*, size_t)'{mlx5_free_mr_by_addr}
  [D] 'function ibv_device* mlx5_get_aux_ibv_device(const 
rte_auxiliary_device*)'{mlx5_get_aux_ibv_device}
  [D] 'function void mlx5_glue_constructor()'{mlx5_glue_constructor}
  [D] 'function void mlx5_malloc_mem_select(uint32_t)'
{mlx5_malloc_mem_select}
  [D] 'function void mlx5_mr_btree_dump(mlx5_mr_btree*)'{mlx5_mr_btree_dump}
  [D] 'function int mlx5_mr_create_cache(mlx5_mr_share_cache*, int)'
{mlx5_mr_create_cache}
  [D] 'function void mlx5_mr_free(mlx5_mr*, mlx5_dereg_mr_t)'{mlx5_mr_free}
  [D] 'function int mlx5_mr_insert_cache(mlx5_mr_share_cache*, mlx5_mr*)'
{mlx5_mr_insert_cache}
  [D] 'function mlx5_mr* mlx5_mr_lookup_list(mlx5_mr_share_cache*, 
mr_cache_entry*, uintptr_t)'{mlx5_mr_lookup_list}
  [D] 'function void mlx5_mr_rebuild_cache(mlx5_mr_share_cache*)'
{mlx5_mr_rebuild_cache}
  [D] 'function void mlx5_mr_release_cache(mlx5_mr_share_cache*)'
{mlx5_mr_release_cache}
  [D] 'function int mlx5_nl_devlink_family_id_get(int)'
{mlx5_nl_devlink_family_id_get}
  [D] 'function int mlx5_nl_enable_roce_get(int, int, const char*, int*)'
{mlx5_nl_enable_roce_get}
  [D] 'function int mlx5_nl_enable_roce_set(int, int, const char*, int)'
{mlx5_nl_enable_roce_set}
  [D] 'function int mlx5_os_open_device(mlx5_common_device*, uint32_t)'
{mlx5_os_open_device}
  [D] 'function int mlx5_os_pd_create(mlx5_common_device*)'
{mlx5_os_pd_create}
  [D] 'function void mlx5_os_set_reg_mr_cb(mlx5_reg_mr_t*, mlx5_dereg_mr_t*)'   
 {mlx5_os_set_reg_mr_cb}
  [D] 'function void mlx5_set_context_attr(rte_device*, ibv_context*)'
{mlx5_set_context_attr}

2 Removed variables:

  [D] 'uint32_t atomic_sn'{atomic_sn}
  [D] 'int mlx5_common_logtype'{mlx5_common_logtype}

1 Removed function symbol not referenced by debug info:

  [D] mlx5_mr_dump_cache

Re: [EXT] [PATCH] crypto: fix misspelled key in qt format

[Ray Kinsella]

Thomas Monjalon  writes:

> 18/02/2022 07:11, Kusztal, ArkadiuszX:
>> From: Akhil Goyal 
>> > Fix ABI warning.
>> > Add libabigail.abiignore rule.
>> 
>> I think what is worth noticing is a fact that after "random 'k' patch" 
>> addition of
>> [suppress_type]
>> name = rte_crypto_asym_op
>> this problem does not show up.
>> 
>> But I think it is safer to send addition of
>> [suppress_type]
>> name = rte_crypto_rsa_priv_key_type
>> anyway.
>> Will send v2.
>
> I don't understand why adding this rule,
> and the comment does say nothing about it:
>   "Ignore name change of rsa qt key type"
>
> The ABI check is fine without above because of this existing exception:
>
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
> [suppress_type]
> name = rte_crypto_asym_op
>
> So I will just drop the unjustified additional exception while pulling.
>
> Next time, please make sure such ABI exception is approved by more 
> maintainers.

To be fair to those involved, I had been CC'ed on the v2 of this.
I didn't respond before the patch was merged however.

-- 
Regards, Ray K

[PATCH v4 3/3] net/ixgbe: Fix SFP detection and linking on hotplug

[Jeff Daly]

Currently the ixgbe driver does not ID any SFP except for the first one
plugged in. This can lead to no-link, or incorrect speed conditions.

For example:

* If link is initially established with a 1G SFP, and later a 1G/10G
multispeed part is later installed, then the MAC link setup functions are
never called to change from 1000BASE-X to 10GBASE-R mode, and the link
stays running at the slower rate.

* If link is initially established with a 1G SFP, and later a 10G only
module is later installed, no link is established, since we are still
trasnsmitting in 1000BASE-X mode to a 10GBASE-R only partner.

Refactor the SFP ID/setup, and link setup code, to more closely match the
flow of the mainline kernel driver which does not have these issues.  In
that driver a service task runs periodically to handle these operations
based on bit flags that have been set (usually via interrupt or userspace
request), and then get cleared once the requested subtask has been
completed.

Fixes: af75078fece ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Stephen Douthit 
Signed-off-by: Jeff Daly 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 499 +++
 drivers/net/ixgbe/ixgbe_ethdev.h |  14 +-
 2 files changed, 392 insertions(+), 121 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index e8f07cb405..b70985bb1d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -229,9 +229,6 @@ static int ixgbe_dev_interrupt_get_status(struct 
rte_eth_dev *dev);
 static int ixgbe_dev_interrupt_action(struct rte_eth_dev *dev);
 static void ixgbe_dev_interrupt_handler(void *param);
 static void ixgbe_dev_interrupt_delayed_handler(void *param);
-static void *ixgbe_dev_setup_link_thread_handler(void *param);
-static int ixgbe_dev_wait_setup_link_complete(struct rte_eth_dev *dev,
- uint32_t timeout_ms);
 
 static int ixgbe_add_rar(struct rte_eth_dev *dev,
struct rte_ether_addr *mac_addr,
@@ -766,6 +763,33 @@ static const struct rte_ixgbe_xstats_name_off 
rte_ixgbevf_stats_strings[] = {
 #define IXGBEVF_NB_XSTATS (sizeof(rte_ixgbevf_stats_strings) / \
sizeof(rte_ixgbevf_stats_strings[0]))
 
+/**
+ * This function is the same as ixgbe_need_crosstalk_fix() in 
base/ixgbe_common.c
+ *
+ * ixgbe_need_crosstalk_fix - Determine if we need to do cross talk fix
+ * @hw: pointer to hardware structure
+ *
+ * Contains the logic to identify if we need to verify link for the
+ * crosstalk fix
+ **/
+static bool ixgbe_need_crosstalk_fix(struct ixgbe_hw *hw)
+{
+   /* Does FW say we need the fix */
+   if (!hw->need_crosstalk_fix)
+   return false;
+
+   /* Only consider SFP+ PHYs i.e. media type fiber */
+   switch (ixgbe_get_media_type(hw)) {
+   case ixgbe_media_type_fiber:
+   case ixgbe_media_type_fiber_qsfp:
+   break;
+   default:
+   return false;
+   }
+
+   return true;
+}
+
 /*
  * This function is the same as ixgbe_is_sfp() in base/ixgbe.h.
  */
@@ -1032,6 +1056,306 @@ ixgbe_swfw_lock_reset(struct ixgbe_hw *hw)
ixgbe_release_swfw_semaphore(hw, mask);
 }
 
+/**
+ * ixgbe_check_sfp_cage - Find present status of SFP module
+ * @hw: pointer to hardware structure
+ *
+ * Find if a SFP module is present and if this device supports SFPs
+ **/
+enum ixgbe_sfp_cage_status ixgbe_check_sfp_cage(struct ixgbe_hw *hw)
+{
+   enum ixgbe_sfp_cage_status sfp_cage_status;
+
+   /* If we're not a fiber/fiber_qsfp, no cage to check */
+   switch (hw->mac.ops.get_media_type(hw)) {
+   case ixgbe_media_type_fiber:
+   case ixgbe_media_type_fiber_qsfp:
+   break;
+   default:
+   return IXGBE_SFP_CAGE_NOCAGE;
+   }
+
+   switch (hw->mac.type) {
+   case ixgbe_mac_82599EB:
+   sfp_cage_status = !!(IXGBE_READ_REG(hw, IXGBE_ESDP) &
+IXGBE_ESDP_SDP2);
+   break;
+   case ixgbe_mac_X550EM_x:
+   case ixgbe_mac_X550EM_a:
+   /* SDP0 is the active low signal PRSNT#, so invert this */
+   sfp_cage_status = !(IXGBE_READ_REG(hw, IXGBE_ESDP) &
+ IXGBE_ESDP_SDP0);
+   break;
+   default:
+   /* Don't know how to check this device type yet */
+   sfp_cage_status = IXGBE_SFP_CAGE_UNKNOWN;
+   DEBUGOUT("IXGBE_SFP_CAGE_UNKNOWN, unknown mac type %d\n",
+hw->mac.type);
+   break;
+   }
+
+   DEBUGOUT("sfp status %d for mac type %d\n", sfp_cage_status, 
hw->mac.type);
+   return sfp_cage_status;
+}
+
+static s32
+ixgbe_sfp_id_and_setup(struct rte_eth_dev *dev)
+{
+   struct ixgbe_hw *hw =
+   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   enum ixgbe_sfp_cage_status sfp_cage_status;
+   s32 err;
+
+   /* Can't ID or s

RE: [PATCH] net/mlx5: support matching optional fields of GRE

[Sean Zhang (Networking SW)]

Thanks Thomas.

> -Original Message-
> From: Thomas Monjalon 
> Sent: Friday, February 25, 2022 11:32 PM
> To: Sean Zhang (Networking SW) 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; dev@dpdk.org; Asaf Penso 
> Subject: Re: [PATCH] net/mlx5: support matching optional fields of GRE
> 
> External email: Use caution opening links or attachments
> 
> 
> 21/02/2022 04:00, Sean Zhang (Networking SW):
> > Hi Thomas,
> >
> > > -Original Message-
> > > From: Thomas Monjalon 
> > > Sent: Thursday, February 17, 2022 4:34 PM
> > > To: Matan Azrad ; Slava Ovsiienko
> > > ; Sean Zhang (Networking SW)
> > > 
> > > Cc: dev@dpdk.org
> > > Subject: Re: [PATCH] net/mlx5: support matching optional fields of
> > > GRE
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > 17/02/2022 07:27, Sean Zhang:
> > > > This patch adds matching on the optional fields
> > > > (checksum/key/sequence) of GRE header. The matching on checksum
> > > > and sequence fields requests support from rdma-core with the
> > > > capability of
> > > misc5 and tunnel_header 0-3.
> > > >
> > > > For patterns without checksum and sequence specified, keep using
> > > > misc for matching as before, but for patterns with checksum or
> > > > sequence, validate capability first and then use misc5 for the matching.
> > > >
> > > > Signed-off-by: Sean Zhang 
> > > > Acked-by: Slava Ovsiienko 
> > > >
> > > > ---
> > > > v3 - some code style change
> > > > v2 - replace default mask with nic mask
> > > > ---
> > > >  doc/guides/nics/mlx5.rst |  10 +++
> > > >  drivers/common/mlx5/mlx5_devx_cmds.c |   3 +
> > > >  drivers/net/mlx5/linux/mlx5_os.c |   2 +
> > > >  drivers/net/mlx5/mlx5.h  |   1 +
> > > >  drivers/net/mlx5/mlx5_flow.c | 101
> > > +
> > > >  drivers/net/mlx5/mlx5_flow.h |   6 ++
> > > >  drivers/net/mlx5/mlx5_flow_dv.c  | 121
> > > +++
> > > >  7 files changed, 244 insertions(+)
> > >
> > > Should we add a line in the release notes?
> > >
> >
> > This patch is v3 of the forth patch of patch set:
> > https://patches.dpdk.org/project/dpdk/cover/20220211014530.77711-1-xia
> > zh...@nvidia.com/ The release notes changed in the second patch of the
> > patch set and applied in v2.
> >
> > --- a/doc/guides/rel_notes/release_22_03.rst
> > +++ b/doc/guides/rel_notes/release_22_03.rst
> > @@ -87,6 +87,11 @@  New Features
> >
> >The new API ``rte_event_eth_rx_adapter_event_port_get()`` was added.
> >
> > +* **Added rte_flow support for matching GRE optional fields.**
> > +
> > +  * Added ``gre_option`` item in rte_flow to support
> checksum/key/sequence
> > +matching in GRE packets.
> > +
> 
> OK but it is missing a line for mlx5 features.
> I'm adding it while merging.
> 
> 

[PATCH] doc: update Mellanox drivers download link in mlx5 guide

[Zhiheng Chen]

The original download link is invalid.

Signed-off-by: Zhiheng Chen 
---
 doc/guides/nics/mlx5.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index c3cc0c0f41..625d8a2382 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1385,9 +1385,9 @@ managers on most distributions, this PMD requires 
Ethernet extensions that
 may not be supported at the moment (this is a work in progress).
 
 `Mellanox OFED
-`__ and
+`__ 
and
 `Mellanox EN
-`__
+`__
 include the necessary support and should be used in the meantime. For DPDK,
 only libibverbs, libmlx5, mlnx-ofed-kernel packages and firmware updates are
 required from that distribution.
-- 
2.32.0