Re: 22.11.4 patches review and test

2023-12-27 Thread YangHang Liu 
I tested below 18 scenarios on RHEL9 and didn't find any new dpdk issues.

Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
Guest with device assignment(VF) throughput testing: PASS
PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
PVP vhost-user 4Q throughput testing: PASS
PVP vhost-user 2Q throughput testing: PASS
PVP vhost-user 1Q - cross numa node throughput testing: PASS
Guest with vhost-user 2 queues throughput testing: PASS
vhost-user reconnect with dpdk-client, qemu-server qemu reconnect: PASS
vhost-user reconnect with dpdk-client, qemu-server ovs reconnect: PASS
PVP 1Q live migration testing: PASS
PVP 1Q cross numa node live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
Host PF + DPDK testing: PASS
Host VF + DPDK testing: PASS


Test Versions:
qemu-kvm-7.2.0
kernel 5.14
# git describe
v22.11.4-rc3

Test device : X540-AT2 NIC(ixgbe, 10G)



Best Regards,
YangHang Liu



On Wed, Dec 20, 2023 at 3:19 PM Xueming Li  wrote:

> Hi all,
>
> Here is a list of patches targeted for stable release 22.11.4.
>
> The planned date for the final release is 5th January.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.4-rc3
>
> These patches are located at branch 22.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Xueming Li 
>
> ---
> Aakash Sasidharan (2):
>   event/cnxk: fix return values for capability API
>   test/event: fix crypto null device creation
>
> Abdullah Sevincer (3):
>   bus/pci: add PASID control
>   event/dlb2: disable PASID
>   event/dlb2: fix disable PASID
>
> Akhil Goyal (2):
>   common/cnxk: fix different size bit operations
>   net/cnxk: fix uninitialized variable
>
> Alex Vesker (1):
>   net/mlx5/hws: fix field copy bind
>
> Alexander Kozyrev (3):
>   net/mlx5/hws: fix integrity bits level
>   net/mlx5: fix MPRQ stride size check
>   ethdev: fix ESP packet type description
>
> Amit Prakash Shukla (4):
>   common/cnxk: fix DPI memzone name
>   dma/cnxk: fix device state
>   dma/cnxk: fix device reconfigure
>   dma/cnxk: fix chunk buffer failure return code
>
> Anatoly Burakov (1):
>   test: fix named test macro
>
> Anoob Joseph (2):
>   cryptodev: add missing doc for security context
>   doc: replace code blocks with includes in security guide
>
> Artemy Kovalyov (1):
>   mem: fix deadlock with multiprocess
>
> Ashwin Sekhar T K (2):
>   mempool/cnxk: fix alloc from non-EAL threads
>   common/cnxk: fix aura disable handling
>
> Beilei Xing (1):
>   net/i40e: fix FDIR queue receives broadcast packets
>
> Bing Zhao (3):
>   net/mlx5: fix flow workspace double free in Windows
>   net/mlx5: fix shared Rx queue list management
>   net/mlx5: fix LACP redirection in Rx domain
>
> Brian Dooley (4):
>   test/crypto: fix IV in some vectors
>   test/crypto: skip some synchronous tests with CPU crypto
>   doc: update kernel module entry in QAT guide
>   examples/ipsec-secgw: fix partial overflow
>
> Bruce Richardson (8):
>   crypto/ipsec_mb: add dependency check for cross build
>   event/sw: remove obsolete comment
>   net/i40e: fix buffer leak on Rx reconfiguration
>   eventdev: fix device pointer for vdev-based devices
>   eventdev: fix missing driver names in info struct
>   ethdev: fix function name in comment
>   event/dlb2: fix name check in self-test
>   event/dlb2: fix missing queue ordering capability flag
>
> Chaoyong He (5):
>   net/nfp: fix crash on close
>   net/nfp: fix reconfigure logic in PF initialization
>   net/nfp: fix reconfigure logic in VF initialization
>   net/nfp: fix link status interrupt
>   net/nfp: fix reconfigure logic of set MAC address
>
> Chengwen Feng (2):
>   net/hns3: fix traffic management thread safety
>   net/hns3: fix traffic management dump text alignment
>
> Christian Ehrhardt (1):
>   config: fix RISC-V native build
>
> Ciara Power (2):
>   crypto/qat: fix raw API null algorithm digest
>   crypto/openssl: fix memory leaks in asym session
>
> Dariusz Sosnowski (8):
>   net/mlx5: fix jump ipool entry size
>   net/mlx5: fix flow thread safety flag for HWS
>   common/mlx5: fix controller index parsing
>   net/mlx5: fix missing flow rules for external SQ
>   net/mlx5: fix use after free on Rx queue start
>

RE: 22.11.4 patches review and test

2023-12-27 Thread Xueming(Steven) Li 
Hi Yanghang,

Thanks for the test and confirmation!

Best Regards,
Xueming Li

From: YangHang Liu  
Sent: 12/27/2023 16:17
To: Xueming(Steven) Li 
Cc: sta...@dpdk.org; dev@dpdk.org; Abhishek Marathe 
; Ali Alnubani ; 
benjamin.wal...@intel.com; David Christensen ; Hemant 
Agrawal ; Ian Stokes ; Jerin 
Jacob ; John McNamara ; Ju-Hyoung 
Lee ; Kevin Traynor ; Luca Boccassi 
; Pei Zhang ; qian.q...@intel.com; Raslan 
Darawsheh ; NBU-Contact-Thomas Monjalon (EXTERNAL) 
; yuan.p...@intel.com; zhaoyan.c...@intel.com; Chao Yang 

Subject: Re: 22.11.4 patches review and test

I tested below 18 scenarios on RHEL9 and didn't find any new dpdk issues.

Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
Guest with device assignment(VF) throughput testing: PASS
PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
PVP vhost-user 4Q throughput testing: PASS
PVP vhost-user 2Q throughput testing: PASS
PVP vhost-user 1Q - cross numa node throughput testing: PASS
Guest with vhost-user 2 queues throughput testing: PASS
vhost-user reconnect with dpdk-client, qemu-server qemu reconnect: PASS
vhost-user reconnect with dpdk-client, qemu-server ovs reconnect: PASS
PVP 1Q live migration testing: PASS
PVP 1Q cross numa node live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
Host PF + DPDK testing: PASS
Host VF + DPDK testing: PASS


Test Versions:
qemu-kvm-7.2.0
kernel 5.14
# git describe
v22.11.4-rc3

Test device : X540-AT2 NIC(ixgbe, 10G)



Best Regards,
YangHang Liu


On Wed, Dec 20, 2023 at 3:19 PM Xueming Li  wrote:
Hi all,

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

The planned date for the final release is 5th January.

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

A release candidate tarball can be found at:

    https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.4-rc3

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

Thanks.

Xueming Li 

---
Aakash Sasidharan (2):
      event/cnxk: fix return values for capability API
      test/event: fix crypto null device creation

Abdullah Sevincer (3):
      bus/pci: add PASID control
      event/dlb2: disable PASID
      event/dlb2: fix disable PASID

Akhil Goyal (2):
      common/cnxk: fix different size bit operations
      net/cnxk: fix uninitialized variable

Alex Vesker (1):
      net/mlx5/hws: fix field copy bind

Alexander Kozyrev (3):
      net/mlx5/hws: fix integrity bits level
      net/mlx5: fix MPRQ stride size check
      ethdev: fix ESP packet type description

Amit Prakash Shukla (4):
      common/cnxk: fix DPI memzone name
      dma/cnxk: fix device state
      dma/cnxk: fix device reconfigure
      dma/cnxk: fix chunk buffer failure return code

Anatoly Burakov (1):
      test: fix named test macro

Anoob Joseph (2):
      cryptodev: add missing doc for security context
      doc: replace code blocks with includes in security guide

Artemy Kovalyov (1):
      mem: fix deadlock with multiprocess

Ashwin Sekhar T K (2):
      mempool/cnxk: fix alloc from non-EAL threads
      common/cnxk: fix aura disable handling

Beilei Xing (1):
      net/i40e: fix FDIR queue receives broadcast packets

Bing Zhao (3):
      net/mlx5: fix flow workspace double free in Windows
      net/mlx5: fix shared Rx queue list management
      net/mlx5: fix LACP redirection in Rx domain

Brian Dooley (4):
      test/crypto: fix IV in some vectors
      test/crypto: skip some synchronous tests with CPU crypto
      doc: update kernel module entry in QAT guide
      examples/ipsec-secgw: fix partial overflow

Bruce Richardson (8):
      crypto/ipsec_mb: add dependency check for cross build
      event/sw: remove obsolete comment
      net/i40e: fix buffer leak on Rx reconfiguration
      eventdev: fix device pointer for vdev-based devices
      eventdev: fix missing driver names in info struct
      ethdev: fix function name in comment
      event/dlb2: fix name check in self-test
      event/dlb2: fix missing queue ordering capability flag

Chaoyong He (5):
      net/nfp: fix crash on close
      net/nfp: fix reconfigure logic in PF initialization
      net/nfp: fix reconfigure logic in VF initialization
      net/nfp: fix link status interrupt
      net/nfp: fix reconfigure logic of set MAC address

Chengwen Feng (2):
      net/hns3: fix traffic management thread safety
      net/hns3: fix traffic management dump text alignment

Christian Ehrhardt (1):
      c

[PATCH 2/8] app/testpmd: add support for NAT64 in the command line

2023-12-27 Thread Bing Zhao 
The type of NAT64 action will be parsed.

Usage example with template API:
  ...
  flow actions_template 0 create ingress actions_template_id 1 \
template count / nat64 / jump / end mask count / nat64 / \
jump / end
  flow template_table 0 create group 1 priority 0 ingress table_id \
0x1 rules_number 8 pattern_template 0 actions_template 1
  flow queue 0 create 2 template_table 0x1 pattern_template 0 \
actions_template 0 postpone no pattern eth / end actions count / \
nat64 type 1 / jump group 2 / end
   ...

Signed-off-by: Bing Zhao 
---
 app/test-pmd/cmdline_flow.c | 23 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 
 2 files changed, 27 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index ce71818705..6fb252d3d5 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -728,6 +728,8 @@ enum index {
ACTION_IPV6_EXT_PUSH,
ACTION_IPV6_EXT_PUSH_INDEX,
ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
+   ACTION_NAT64,
+   ACTION_NAT64_MODE,
 };
 
 /** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -2193,6 +2195,7 @@ static const enum index next_action[] = {
ACTION_QUOTA_QU,
ACTION_IPV6_EXT_REMOVE,
ACTION_IPV6_EXT_PUSH,
+   ACTION_NAT64,
ZERO,
 };
 
@@ -2534,6 +2537,12 @@ static const enum index action_represented_port[] = {
ZERO,
 };
 
+static const enum index action_nat64[] = {
+   ACTION_NAT64_MODE,
+   ACTION_NEXT,
+   ZERO,
+};
+
 static int parse_set_raw_encap_decap(struct context *, const struct token *,
 const char *, unsigned int,
 void *, unsigned int);
@@ -7022,6 +7031,20 @@ static const struct token token_list[] = {
.call = parse_vc_action_ipv6_ext_push_index,
.comp = comp_set_ipv6_ext_index,
},
+   [ACTION_NAT64] = {
+   .name = "nat64",
+   .help = "NAT64 IP headers translation",
+   .priv = PRIV_ACTION(NAT64, sizeof(struct 
rte_flow_action_nat64)),
+   .next = NEXT(action_nat64),
+   .call = parse_vc,
+   },
+   [ACTION_NAT64_MODE] = {
+   .name = "type",
+   .help = "NAT64 translation type",
+   .next = NEXT(action_nat64, NEXT_ENTRY(COMMON_UNSIGNED)),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_nat64, type)),
+   .call = parse_vc_conf,
+   },
/* Top level command. */
[SET] = {
.name = "set",
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 447e28e694..01044043d0 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4151,6 +4151,10 @@ This section lists supported actions and their 
attributes, if any.
   - ``src_ptr``: pointer to source immediate value.
   - ``width``: number of bits to copy.
 
+- ``nat64``: NAT64 IP headers translation
+
+  - ``type {unsigned}``: NAT64 translation type
+
 Destroying flow rules
 ~
 
-- 
2.25.1

[PATCH 0/8] support NAT64 action

2023-12-27 Thread Bing Zhao 
This patchset introduce the NAT64 action support for rte_flow.

Bing Zhao (7):
  ethdev: introduce NAT64 action
  app/testpmd: add support for NAT64 in the command line
  net/mlx5: fetch the available registers for NAT64
  common/mlx5: add new modify field defininations
  net/mlx5: create NAT64 actions during configuration
  net/mlx5: add NAT64 action support in rule creation
  net/mlx5: validate the actions combination with NAT64

Erez Shitrit (1):
  net/mlx5/hws: support NAT64 action

 app/test-pmd/cmdline_flow.c |  23 ++
 doc/guides/nics/features/default.ini|   1 +
 doc/guides/nics/features/mlx5.ini   |   1 +
 doc/guides/nics/mlx5.rst|   9 +-
 doc/guides/prog_guide/rte_flow.rst  |   8 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   4 +
 drivers/common/mlx5/mlx5_prm.h  |   5 +
 drivers/net/mlx5/hws/mlx5dr.h   |  29 ++
 drivers/net/mlx5/hws/mlx5dr_action.c| 437 +++-
 drivers/net/mlx5/hws/mlx5dr_action.h|  35 ++
 drivers/net/mlx5/hws/mlx5dr_debug.c |   1 +
 drivers/net/mlx5/mlx5.c |   9 +
 drivers/net/mlx5/mlx5.h |   8 +
 drivers/net/mlx5/mlx5_flow.h|  12 +
 drivers/net/mlx5/mlx5_flow_dv.c |   4 +-
 drivers/net/mlx5/mlx5_flow_hw.c |  91 
 lib/ethdev/rte_flow.c   |   1 +
 lib/ethdev/rte_flow.h   |  27 ++
 18 files changed, 702 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH 1/8] ethdev: introduce NAT64 action

2023-12-27 Thread Bing Zhao 
In order to support the communication between IPv4 and IPv6 nodes in
the network, different technologies are used, like dual-stacks,
tunneling and NAT64. In some IPv4-only clients, it is hard to deploy
new software and(or) hardware to support IPv6 protocol.

NAT64 is a choice and it will also reduce the unnecessary overhead of
the traffic in the network. The NAT64 gateways take the
responsibility of the packet headers translation between the IPv6
clouds and IPv4-only clouds.

The commit introduce the NAT64 flow action to offload the software
involvement to the hardware.

This action should support the offloading of the IP headers'
translation. The following fields should be reset correctly in the
translation.
  - Version
  - Traffic Class / TOS
  - Flow Label (0 in v4)
  - Payload Length / Total length
  - Next Header
  - Hop Limit / TTL

The PMD needs to support the basic conversion of the fields above,
and the well-known prefix will be used when translating IPv4 address
to IPv6 address. Another modify fields can be used after the NAT64 to
support other modes with different prefix and offset.

The ICMP* and transport layers protocol is out of the scope of NAT64
rte_flow action.

Reference links:
  - https://datatracker.ietf.org/doc/html/rfc6146
  - https://datatracker.ietf.org/doc/html/rfc6052
  - https://datatracker.ietf.org/doc/html/rfc6145

Signed-off-by: Bing Zhao 
---
 doc/guides/nics/features/default.ini |  1 +
 doc/guides/prog_guide/rte_flow.rst   |  8 
 lib/ethdev/rte_flow.c|  1 +
 lib/ethdev/rte_flow.h| 27 +++
 4 files changed, 37 insertions(+)

diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 806cb033ff..f8a47a055a 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -170,6 +170,7 @@ mark =
 meter=
 meter_mark   =
 modify_field =
+nat64=
 nvgre_decap  =
 nvgre_encap  =
 of_copy_ttl_in   =
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 627b845bfb..f87628e9dc 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3506,6 +3506,14 @@ The packets will be received by the kernel driver 
sharing the same device
 as the DPDK port on which this action is configured.
 
 
+Action: ``NAT64``
+^
+
+This action does the header translation between IPv4 and IPv6. Besides
+converting the IP addresses, other fields in the IP header are handled as
+well. The ``type`` field should be provided as defined in the
+``rte_flow_action_nat64`` when creating the action.
+
 Negative types
 ~~
 
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 549e329558..502df3bfd1 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -268,6 +268,7 @@ static const struct rte_flow_desc_data 
rte_flow_desc_action[] = {
   sizeof(struct rte_flow_action_indirect_list)),
MK_FLOW_ACTION(PROG,
   sizeof(struct rte_flow_action_prog)),
+   MK_FLOW_ACTION(NAT64, sizeof(struct rte_flow_action_nat64)),
 };
 
 int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index affdc8121b..da2afaef83 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3022,6 +3022,13 @@ enum rte_flow_action_type {
 * @see struct rte_flow_action_prog.
 */
RTE_FLOW_ACTION_TYPE_PROG,
+
+   /**
+* Support the NAT64 translation.
+*
+* @see struct rte_flow_action_nat64
+*/
+   RTE_FLOW_ACTION_TYPE_NAT64,
 };
 
 /**
@@ -4150,6 +4157,26 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t 
v)
*RTE_FLOW_DYNF_METADATA(m) = v;
 }
 
+/**
+ * NAT64 translation type for IP headers.
+ */
+enum rte_flow_nat64_type {
+   RTE_FLOW_NAT64_6TO4 = 0, /**< IPv6 to IPv4 headers translation. */
+   RTE_FLOW_NAT64_4TO6 = 1, /**< IPv4 to IPv6 headers translation. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_NAT64
+ *
+ * Specify the NAT64 translation type.
+ */
+struct rte_flow_action_nat64 {
+   enum rte_flow_nat64_type type;
+};
+
 /**
  * Definition of a single action.
  *
-- 
2.25.1

[PATCH 4/8] common/mlx5: add new modify field defininations

2023-12-27 Thread Bing Zhao 
This commit adds TCP data offset, IPv4 total length, IPv4 IHL,
IPv6 payload length in modify field operation.

Also redefine the out protocol(next header) for both IPv4 and IPv6.

Signed-off-by: Bing Zhao 
---
 drivers/common/mlx5/mlx5_prm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 9e22dce6da..2f009f81ea 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -839,6 +839,7 @@ enum mlx5_modification_field {
MLX5_MODI_IN_MPLS_LABEL_2,
MLX5_MODI_IN_MPLS_LABEL_3,
MLX5_MODI_IN_MPLS_LABEL_4,
+   MLX5_MODI_OUT_IP_PROTOCOL = 0x4A,
MLX5_MODI_OUT_IPV6_NEXT_HDR = 0x4A,
MLX5_MODI_META_REG_C_8 = 0x8F,
MLX5_MODI_META_REG_C_9 = 0x90,
@@ -848,6 +849,10 @@ enum mlx5_modification_field {
MLX5_MODI_META_REG_C_13 = 0x94,
MLX5_MODI_META_REG_C_14 = 0x95,
MLX5_MODI_META_REG_C_15 = 0x96,
+   MLX5_MODI_OUT_IPV4_TOTAL_LEN = 0x11D,
+   MLX5_MODI_OUT_IPV6_PAYLOAD_LEN = 0x11E,
+   MLX5_MODI_OUT_IPV4_IHL = 0x11F,
+   MLX5_MODI_OUT_TCP_DATA_OFFSET = 0x120,
MLX5_MODI_INVALID = INT_MAX,
 };
 
-- 
2.25.1

[PATCH 3/8] net/mlx5: fetch the available registers for NAT64

2023-12-27 Thread Bing Zhao 
REG_C_6 is used as the 1st one and since it is reserved internally
by default, there is no impact.

The remaining 2 registers will be fetched from the available TAGs
array from right to left. They will not be masked in the array due
to the fact that not all the rules will use NAT64 action.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5.c | 9 +
 drivers/net/mlx5/mlx5.h | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 3a182de248..6f7b2aaa77 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -1643,6 +1643,15 @@ mlx5_init_hws_flow_tags_registers(struct 
mlx5_dev_ctx_shared *sh)
if (!!((1 << i) & masks))
reg->hw_avl_tags[j++] = mlx5_regc_value(i);
}
+   /*
+* Set the registers for NAT64 usage internally. REG_C_6 is always used.
+* The other 2 registers will be fetched from right to left, at least 2
+* tag registers should be available.
+*/
+   MLX5_ASSERT(j >= (MLX5_FLOW_NAT64_REGS_MAX - 1));
+   reg->nat64_regs[0] = REG_C_6;
+   reg->nat64_regs[1] = reg->hw_avl_tags[j - 2];
+   reg->nat64_regs[2] = reg->hw_avl_tags[j - 1];
 }
 
 static void
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 263ebead7f..b73ab78870 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1407,10 +1407,12 @@ struct mlx5_hws_cnt_svc_mng {
 };
 
 #define MLX5_FLOW_HW_TAGS_MAX 12
+#define MLX5_FLOW_NAT64_REGS_MAX 3
 
 struct mlx5_dev_registers {
enum modify_reg aso_reg;
enum modify_reg hw_avl_tags[MLX5_FLOW_HW_TAGS_MAX];
+   enum modify_reg nat64_regs[MLX5_FLOW_NAT64_REGS_MAX];
 };
 
 #if defined(HAVE_MLX5DV_DR) && \
-- 
2.25.1

[PATCH 6/8] net/mlx5: create NAT64 actions during configuration

2023-12-27 Thread Bing Zhao 
The NAT64 DR actions can be shared among the tables. All these
actions can be created during configuring the flow queues and saved
for the future usage.

Even the actions can be shared now, inside per each flow rule, the
actual hardware resources are unique.

Signed-off-by: Bing Zhao 
---
 doc/guides/nics/features/mlx5.ini |  1 +
 doc/guides/nics/mlx5.rst  |  9 -
 drivers/net/mlx5/mlx5.h   |  6 +++
 drivers/net/mlx5/mlx5_flow.h  | 11 ++
 drivers/net/mlx5/mlx5_flow_dv.c   |  4 +-
 drivers/net/mlx5/mlx5_flow_hw.c   | 65 +++
 6 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/features/mlx5.ini 
b/doc/guides/nics/features/mlx5.ini
index 0739fe9d63..f074ff20db 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -115,6 +115,7 @@ mark = Y
 meter= Y
 meter_mark   = Y
 modify_field = Y
+nat64= Y
 nvgre_decap  = Y
 nvgre_encap  = Y
 of_pop_vlan  = Y
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 6b52fb93c5..920cd1e62f 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -167,7 +167,7 @@ Features
 - Sub-Function.
 - Matching on represented port.
 - Matching on aggregated affinity.
-
+- NAT64.
 
 Limitations
 ---
@@ -779,6 +779,13 @@ Limitations
   if preceding active application rules are still present and vice versa.
 
 
+- NAT64 action:
+  - Supported only with HW Steering enabled (``dv_flow_en`` = 2).
+  - Supported only on non-root table.
+  - Actions order limitation should follow the modify fields action.
+  - The last 2 TAG registers will be used implicitly in address backup mode.
+  - Even if the action can be shared, new steering entries will be created per 
flow rule. It is recommended a single rule with NAT64 should be shared to 
reduce the duplication of entries. The default address and other fields 
covertion will be handled with NAT64 action. To support other address, new 
rule(s) with modify fields on the IP addresses should be created.
+
 Statistics
 --
 
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b73ab78870..860c77a4dd 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1967,6 +1967,12 @@ struct mlx5_priv {
struct mlx5_aso_mtr_pool *hws_mpool; /* HW steering's Meter pool. */
struct mlx5_flow_hw_ctrl_rx *hw_ctrl_rx;
/**< HW steering templates used to create control flow rules. */
+   /*
+* The NAT64 action can be shared among matchers per domain.
+* [0]: RTE_FLOW_NAT64_6TO4, [1]: RTE_FLOW_NAT64_4TO6
+* Todo: consider to add *_MAX macro.
+*/
+   struct mlx5dr_action *action_nat64[MLX5DR_TABLE_TYPE_MAX][2];
 #endif
struct rte_eth_dev *shared_host; /* Host device for HW steering. */
uint16_t shared_refcnt; /* HW steering host reference counter. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 6dde9de688..81026632ed 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -159,6 +159,17 @@ struct mlx5_rte_flow_item_sq {
uint32_t queue; /* DevX SQ number */
 };
 
+/* Map from registers to modify fields. */
+extern enum mlx5_modification_field reg_to_field[];
+extern const size_t mlx5_mod_reg_size;
+
+static __rte_always_inline enum mlx5_modification_field
+mlx5_covert_reg_to_field(enum modify_reg reg)
+{
+   MLX5_ASSERT((size_t)reg < mlx5_mod_reg_size);
+   return reg_to_field[reg];
+}
+
 /* Feature name to allocate metadata register. */
 enum mlx5_feature_name {
MLX5_HAIRPIN_RX,
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 115d730317..97915a54ef 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -958,7 +958,7 @@ flow_dv_convert_action_modify_tcp_ack
 MLX5_MODIFICATION_TYPE_ADD, error);
 }
 
-static enum mlx5_modification_field reg_to_field[] = {
+enum mlx5_modification_field reg_to_field[] = {
[REG_NON] = MLX5_MODI_OUT_NONE,
[REG_A] = MLX5_MODI_META_DATA_REG_A,
[REG_B] = MLX5_MODI_META_DATA_REG_B,
@@ -976,6 +976,8 @@ static enum mlx5_modification_field reg_to_field[] = {
[REG_C_11] = MLX5_MODI_META_REG_C_11,
 };
 
+const size_t mlx5_mod_reg_size = RTE_DIM(reg_to_field);
+
 /**
  * Convert register set to DV specification.
  *
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index da873ae2e2..9b9ad8de2d 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -7413,6 +7413,66 @@ flow_hw_destroy_send_to_kernel_action(struct mlx5_priv 
*priv)
}
 }
 
+static void
+flow_hw_destroy_nat64_actions(struct mlx5_priv *priv)
+{
+   uint32_t i;
+
+   for (i = MLX5DR_TABLE_TYPE_NIC_RX; i < MLX5DR_TABLE_TYPE_MAX; i++) {
+

[PATCH 5/8] net/mlx5/hws: support NAT64 action

2023-12-27 Thread Bing Zhao 
From: Erez Shitrit 

Add support of new action mlx5dr_action_create_nat64.
The new action allows to modify IP packets from version to version, IPV6
to IPV4 and vice versa.

Signed-off-by: Erez Shitrit 
Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/hws/mlx5dr.h|  29 ++
 drivers/net/mlx5/hws/mlx5dr_action.c | 437 ++-
 drivers/net/mlx5/hws/mlx5dr_action.h |  35 +++
 drivers/net/mlx5/hws/mlx5dr_debug.c  |   1 +
 4 files changed, 501 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index d88f73ab57..44fff5db25 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -51,6 +51,7 @@ enum mlx5dr_action_type {
MLX5DR_ACTION_TYP_DEST_ARRAY,
MLX5DR_ACTION_TYP_POP_IPV6_ROUTE_EXT,
MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT,
+   MLX5DR_ACTION_TYP_NAT64,
MLX5DR_ACTION_TYP_MAX,
 };
 
@@ -796,6 +797,34 @@ mlx5dr_action_create_reformat_ipv6_ext(struct 
mlx5dr_context *ctx,
   uint32_t log_bulk_size,
   uint32_t flags);
 
+enum mlx5dr_action_nat64_flags {
+   MLX5DR_ACTION_NAT64_V4_TO_V6 = 1 << 0,
+   MLX5DR_ACTION_NAT64_V6_TO_V4 = 1 << 1,
+   /* Indicates if to backup ipv4 addresses in last two registers */
+   MLX5DR_ACTION_NAT64_BACKUP_ADDR = 1 << 2,
+};
+
+struct mlx5dr_action_nat64_attr {
+   uint8_t num_of_registers;
+   uint8_t *registers;
+   enum mlx5dr_action_nat64_flags flags;
+};
+
+/* Create direct rule nat64 action.
+ *
+ * @param[in] ctx
+ * The context in which the new action will be created.
+ * @param[in] attr
+ * The relevant attiribute of the NAT action.
+  * @param[in] flags
+ * Action creation flags. (enum mlx5dr_action_flags)
+ * @return pointer to mlx5dr_action on success NULL otherwise.
+ */
+struct mlx5dr_action *
+mlx5dr_action_create_nat64(struct mlx5dr_context *ctx,
+  struct mlx5dr_action_nat64_attr *attr,
+  uint32_t flags);
+
 /* Destroy direct rule action.
  *
  * @param[in] action
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c 
b/drivers/net/mlx5/hws/mlx5dr_action.c
index 862ee3e332..4193d8e767 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -31,6 +31,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -52,6 +53,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -75,6 +77,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -246,6 +249,311 @@ static void mlx5dr_action_put_shared_stc(struct 
mlx5dr_action *action,
mlx5dr_action_put_shared_stc_nic(ctx, stc_type, 
MLX5DR_TABLE_TYPE_FDB);
 }
 
+static struct mlx5dr_action *
+mlx5dr_action_create_nat64_copy_state(struct mlx5dr_context *ctx,
+ struct mlx5dr_action_nat64_attr *attr,
+ uint32_t flags)
+{
+   __be64 modify_action_data[MLX5DR_ACTION_NAT64_MAX_MODIFY_ACTIONS];
+   struct mlx5dr_action_mh_pattern pat[2];
+   struct mlx5dr_action *action;
+   uint32_t packet_len_field;
+   uint8_t *action_ptr;
+   uint32_t ttl_field;
+   uint32_t src_addr;
+   uint32_t dst_addr;
+   bool is_v4_to_v6;
+
+   is_v4_to_v6 = attr->flags & MLX5DR_ACTION_NAT64_V4_TO_V6;
+
+   if (is_v4_to_v6) {
+   packet_len_field = MLX5_MODI_OUT_IPV4_TOTAL_LEN;
+   ttl_field = MLX5_MODI_OUT_IPV4_TTL;
+   src_addr = MLX5_MODI_OUT_SIPV4;
+   dst_addr = MLX5_MODI_OUT_DIPV4;
+   } else {
+   packet_len_field = MLX5_MODI_OUT_IPV6_PAYLOAD_LEN;
+   ttl_field = MLX5_MODI_OUT_IPV6_HOPLIMIT;
+   src_addr = MLX5_MODI_OUT_SIPV6_31_0;
+   d

[PATCH 7/8] net/mlx5: add NAT64 action support in rule creation

2023-12-27 Thread Bing Zhao 
The action will handle the IPv4 and IPv6 headers translation. It will
add / remove IPv6 address prefix by default.

To use the user specific address, another rule to modify the
addresses of the IP header is needed.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 9b9ad8de2d..9b60233549 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -2479,6 +2479,19 @@ __flow_hw_actions_translate(struct rte_eth_dev *dev,
}
acts->rule_acts[dr_pos].action = priv->hw_def_miss;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   if (masks->conf &&
+   ((const struct rte_flow_action_nat64 
*)masks->conf)->type) {
+   const struct rte_flow_action_nat64 *nat64_c =
+   (const struct rte_flow_action_nat64 
*)actions->conf;
+
+   acts->rule_acts[dr_pos].action =
+   priv->action_nat64[type][nat64_c->type];
+   } else if (__flow_hw_act_data_general_append(priv, acts,
+
actions->type,
+src_pos, 
dr_pos))
+   goto err;
+   break;
case RTE_FLOW_ACTION_TYPE_END:
actions_end = true;
break;
@@ -2912,6 +2925,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
const struct rte_flow_action_ethdev *port_action = NULL;
const struct rte_flow_action_meter *meter = NULL;
const struct rte_flow_action_age *age = NULL;
+   const struct rte_flow_action_nat64 *nat64_c = NULL;
uint8_t *buf = job->encap_data;
uint8_t *push_buf = job->push_data;
struct rte_flow_attr attr = {
@@ -3179,6 +3193,13 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
if (ret != 0)
return ret;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   nat64_c = action->conf;
+   if (!priv->action_nat64[table->type][nat64_c->type])
+   return -1;
+   rule_acts[act_data->action_dst].action =
+   priv->action_nat64[table->type][nat64_c->type];
+   break;
default:
break;
}
@@ -5872,6 +5893,7 @@ static enum mlx5dr_action_type mlx5_hw_dr_action_types[] 
= {
[RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL] = MLX5DR_ACTION_TYP_DEST_ROOT,
[RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH] = 
MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT,
[RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE] = 
MLX5DR_ACTION_TYP_POP_IPV6_ROUTE_EXT,
+   [RTE_FLOW_ACTION_TYPE_NAT64] = MLX5DR_ACTION_TYP_NAT64,
 };
 
 static inline void
-- 
2.25.1

[PATCH 8/8] net/mlx5: validate the actions combination with NAT64

2023-12-27 Thread Bing Zhao 
NAT64 is treated as a modify header action. The action order and
limitation should be the same as that of modify header in each
domain.

Since the last 2 TAG registers will be used implicitly in the
address backup mode, the values in these registers are no longer
valid after the NAT64 action. The application should not try to
match these TAGs after the rule that contains NAT64 action.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow.h| 1 +
 drivers/net/mlx5/mlx5_flow_hw.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 81026632ed..6bdd350aef 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -376,6 +376,7 @@ enum mlx5_feature_name {
 #define MLX5_FLOW_ACTION_PORT_REPRESENTOR (1ull << 47)
 #define MLX5_FLOW_ACTION_IPV6_ROUTING_REMOVE (1ull << 48)
 #define MLX5_FLOW_ACTION_IPV6_ROUTING_PUSH (1ull << 49)
+#define MLX5_FLOW_ACTION_NAT64 (1ull << 50)
 
 #define MLX5_FLOW_DROP_INCLUSIVE_ACTIONS \
(MLX5_FLOW_ACTION_COUNT | MLX5_FLOW_ACTION_SAMPLE | 
MLX5_FLOW_ACTION_AGE)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 9b60233549..09ae49faa4 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -5841,6 +5841,10 @@ mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
MLX5_HW_VLAN_PUSH_VID_IDX;
action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   /* TODO: Validation logic */
+   action_flags |= MLX5_FLOW_ACTION_NAT64;
+   break;
case RTE_FLOW_ACTION_TYPE_END:
actions_end = true;
break;
-- 
2.25.1

Re: memory_hotplug_lock deadlock during initialization in Multi-process Mode on DPDK Version 22.11.3 LTS

2023-12-27 Thread David Marchand 
Hello,

Cc: 22.11 stable maintainer for info

On Wed, Dec 27, 2023 at 4:14 AM Linzhe Lee
 wrote:
>
> Dear Team,
>
> I hope this message finds you well.
>
> We have encountered a recurring deadlock issue within the function
> rte_rwlock_write_lock in the DPDK version 22.11.3 LTS.
>
> It appears to be related to a known matter addressed in
> https://bugs.dpdk.org/show_bug.cgi?id=1277 and subsequently resolved
> in version 23.11.
>
> I kindly propose the backporting of this fix to the 22.11 branch,
> considering its status as a long-term support (LTS) version.

As far as I can see, this fix is part of the 22.11.4-rc1 tag.

A 22.11.4-rc3 tag was recently released.
https://git.dpdk.org/dpdk-stable/tag/?h=v22.11.4-rc3
Could you have a try with it?


Thanks.

-- 
David Marchand

[PATCH v4 1/2] net/iavf: add diagnostic support in TX path

2023-12-27 Thread Mingjin Ye 
The only way to enable diagnostics for TX paths is to modify the
application source code. Making it difficult to diagnose faults.

In this patch, the devarg option "mbuf_check" is introduced and the
parameters are configured to enable the corresponding diagnostics.

supported cases: mbuf, size, segment, offload, strict.
 1. mbuf: check for corrupted mbuf.
 2. size: check min/max packet length according to hw spec.
 3. segment: check number of mbuf segments not exceed hw limitation.
 4. offload: check any unsupported offload flag.
 5. strict: check protocol headers.

parameter format: mbuf_check=[mbuf,,]
eg: dpdk-testpmd -a :81:01.0,mbuf_check=[mbuf,size] -- -i

Signed-off-by: Mingjin Ye 
---
v2: Remove call chain.
---
v3: Optimisation implementation.
---
v4: Fix Windows os compilation error.
---
 drivers/net/iavf/iavf.h|  25 +-
 drivers/net/iavf/iavf_ethdev.c |  70 +
 drivers/net/iavf/iavf_rxtx.c   | 138 -
 drivers/net/iavf/iavf_rxtx.h   |   5 ++
 4 files changed, 234 insertions(+), 4 deletions(-)

diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 10868f2c30..b81329bb56 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -113,9 +113,14 @@ struct iavf_ipsec_crypto_stats {
} ierrors;
 };
 
+struct iavf_mbuf_stats {
+   uint64_t tx_pkt_errors;
+};
+
 struct iavf_eth_xstats {
struct virtchnl_eth_stats eth_stats;
struct iavf_ipsec_crypto_stats ips_stats;
+   struct iavf_mbuf_stats mbuf_stats;
 };
 
 /* Structure that defines a VSI, associated with a adapter. */
@@ -309,10 +314,27 @@ struct iavf_devargs {
uint32_t watchdog_period;
int auto_reset;
int no_poll_on_link_down;
+   int mbuf_check;
 };
 
 struct iavf_security_ctx;
 
+#define IAVF_MBUF_CHECK_F_TX_MBUF(1ULL << 0)
+#define IAVF_MBUF_CHECK_F_TX_SIZE(1ULL << 1)
+#define IAVF_MBUF_CHECK_F_TX_SEGMENT (1ULL << 2)
+#define IAVF_MBUF_CHECK_F_TX_OFFLOAD (1ULL << 3)
+#define IAVF_MBUF_CHECK_F_TX_STRICT  (1ULL << 4)
+
+enum iavf_tx_pkt_burst_type {
+   IAVF_PKT_BURST_DEFAULT  = 0,
+   IAVF_PKT_BURST_VEC  = 1,
+   IAVF_PKT_BURST_VEC_AVX2 = 2,
+   IAVF_PKT_BURST_VEC_AVX2_OFFLOAD = 3,
+   IAVF_PKT_BURST_VEC_AVX512   = 4,
+   IAVF_PKT_BURST_VEC_AVX512_OFFLOAD   = 5,
+   IAVF_PKT_BURST_VEC_AVX512_CTX_OFFLOAD   = 6,
+};
+
 /* Structure to store private data for each VF instance. */
 struct iavf_adapter {
struct iavf_hw hw;
@@ -329,7 +351,8 @@ struct iavf_adapter {
bool closed;
bool no_poll;
eth_rx_burst_t rx_pkt_burst;
-   eth_tx_burst_t tx_pkt_burst;
+   enum iavf_tx_pkt_burst_type tx_burst_type;
+   uint64_t mc_flags; /* mbuf check flags. */
uint16_t fdir_ref_cnt;
struct iavf_devargs devargs;
 };
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index d1edb0dd5c..5398d2783f 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -39,6 +40,8 @@
 #define IAVF_RESET_WATCHDOG_ARG"watchdog_period"
 #define IAVF_ENABLE_AUTO_RESET_ARG "auto_reset"
 #define IAVF_NO_POLL_ON_LINK_DOWN_ARG "no-poll-on-link-down"
+#define IAVF_MBUF_CHECK_ARG   "mbuf_check"
+
 uint64_t iavf_timestamp_dynflag;
 int iavf_timestamp_dynfield_offset = -1;
 
@@ -48,6 +51,7 @@ static const char * const iavf_valid_args[] = {
IAVF_RESET_WATCHDOG_ARG,
IAVF_ENABLE_AUTO_RESET_ARG,
IAVF_NO_POLL_ON_LINK_DOWN_ARG,
+   IAVF_MBUF_CHECK_ARG,
NULL
 };
 
@@ -174,6 +178,7 @@ static const struct rte_iavf_xstats_name_off 
rte_iavf_stats_strings[] = {
{"tx_broadcast_packets", _OFF_OF(eth_stats.tx_broadcast)},
{"tx_dropped_packets", _OFF_OF(eth_stats.tx_discards)},
{"tx_error_packets", _OFF_OF(eth_stats.tx_errors)},
+   {"tx_mbuf_error_packets", _OFF_OF(mbuf_stats.tx_pkt_errors)},
 
{"inline_ipsec_crypto_ipackets", _OFF_OF(ips_stats.icount)},
{"inline_ipsec_crypto_ibytes", _OFF_OF(ips_stats.ibytes)},
@@ -1881,6 +1886,8 @@ static int iavf_dev_xstats_get(struct rte_eth_dev *dev,
 {
int ret;
unsigned int i;
+   struct iavf_tx_queue *txq;
+   uint64_t mbuf_errors = 0;
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
@@ -1904,6 +1911,15 @@ static int iavf_dev_xstats_get(struct rte_eth_dev *dev,
if (iavf_ipsec_crypto_supported(adapter))
iavf_dev_update_ipsec_xstats(dev, &iavf_xtats.ips_stats);
 
+   if (adapter->devargs.mbuf_check) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   txq = dev->data->tx_queues[i];
+   mbuf_errors += __atomic_load_n(&txq->

[RFC] ethdev: fast path async flow API

2023-12-27 Thread Dariusz Sosnowski 
Goal of the proposed API changes is reducing the overhead of performance
critical asynchronous flow API functions at library level.
Specifically the functions which can be called while processing packets
received by the application in data path.

The plan for the changes is as follows:

1. Fast path flow functions are defined in header file.
   This allows for inlining them into application code.
2. Fast path functions will call the relevant callbacks,
   which are cached in rte_flow_fp_ops array.
- rte_flow_fp_ops is a flat array containing one entry per port.
- Each entry holds the fast path callbacks provided by the PMD.
- By default, each entry holds dummy callbacks defined in flow library,
  which return ENOSYS for all functions.
- Each entry holds a per-port private context, provided by the PMD,
  which is passed to the callbacks.
- It is assumed that a callback is defined for the respective function.
  Either the default callback provided by DPDK or
  one provided by the PMD.
3. Any API-level checks are compiled out unless
   RTE_FLOW_DEBUG macro is defined during compilation.
4. Each PMD which implements fast path functions must populate
   the rte_flow_fp_ops struct by calling rte_flow_fp_ops_register().
5. rte_flow_fp_ops is reset to default state on port cleanup
   by ethdev library.

As a result of these changes the relevant callbacks can also be removed
from rte_flow_ops struct. rte_flow_ops struct for now on may be considered
reserved for defining slow path flow API functions.

The proposed changes apply to the following functions
(currently all are marked as experimental API):

- rte_flow_async_create()
- rte_flow_async_create_by_index()
- rte_flow_async_actions_update()
- rte_flow_async_destroy()
- rte_flow_push()
- rte_flow_pull()
- rte_flow_async_action_handle_create()
- rte_flow_async_action_handle_destroy()
- rte_flow_async_action_handle_update()
- rte_flow_async_action_handle_query()
- rte_flow_async_action_handle_query_update()
- rte_flow_async_action_list_handle_create()
- rte_flow_async_action_list_handle_destroy()
- rte_flow_async_action_list_handle_query_update()

In internal testing for mlx5 PMD, with these API changes applied and
after adapting the PMD itself, we saw significant improvement
in single-threaded flow operations throughput:

Flow rule insertion: ~5570 vs ~6060 Kflows/sec -  +8.8%
Flow rule deletion:  ~8420 vs ~9680 Kflows/sec - +15.0%

NVIDIA plans to provide an implementation in mlx5 PMD,
based on these API changes, in 24.03.

**Future considerations**

A case can be made about converting some of the existing
stable API functions to fast path versions in future LTS releases.
I don't have any hard data on how such changes would affect performance of
these APIs, but I assume that the improvement would be noticeable.

However, at the moment I see one problem with this approach.
It would require DPDK to expose the rte_eth_dev struct definition,
because of implied locking implemented in the flow API.
To be specific, I am referring to fts_enter() and fts_exit()
used in flow library. As a result, we might not be able to fully move
the implementation of stable APIs to header files.

This applies to the following APIs:

- rte_flow_create()
- rte_flow_destroy()
- rte_flow_actions_update()
- rte_flow_query()
- rte_flow_get_aged_flows()
- rte_flow_action_handle_create()
- rte_flow_action_handle_destroy()
- rte_flow_action_handle_update()
- rte_flow_action_handle_query()
- rte_flow_action_list_handle_create()
- rte_flow_action_list_handle_destroy()
- rte_flow_action_list_handle_query_update()

Signed-off-by: Dariusz Sosnowski 
---
 lib/ethdev/ethdev_driver.c   |   3 +
 lib/ethdev/rte_flow.c| 637 +++
 lib/ethdev/rte_flow.h| 550 +++---
 lib/ethdev/rte_flow_driver.h | 144 ++--
 4 files changed, 813 insertions(+), 521 deletions(-)

diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
index bd917a15fc..6c36bce8ab 100644
--- a/lib/ethdev/ethdev_driver.c
+++ b/lib/ethdev/ethdev_driver.c
@@ -10,6 +10,7 @@
 
 #include "ethdev_driver.h"
 #include "ethdev_private.h"
+#include "rte_flow_driver.h"
 
 /**
  * A set of values to describe the possible states of a switch domain.
@@ -245,6 +246,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
 
eth_dev_fp_ops_reset(rte_eth_fp_ops + eth_dev->data->port_id);
 
+   rte_flow_fp_ops_reset(eth_dev->data->port_id);
+
rte_spinlock_lock(rte_mcfg_ethdev_get_lock());
 
eth_dev->state = RTE_ETH_DEV_UNUSED;
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index f49d1d3767..a33185d8d2 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -26,6 +26,8 @@ int32_t rte_flow_dynf_metadata_offs = -1;
 /* Mbuf dynamic field flag bit number for metadata. */
 uint64_t rte_flow_dynf_metadata_mask;
 
+struct rte_flow_fp_ops rte_flow_fp_ops[RTE_MAX_ETHPORTS];
+
 /**
  * Flow elements des

RE: [PATCH v2] net/ice: fix tso tunnel setting to not take effect

2023-12-27 Thread Zhang, Qi Z 



> -Original Message-
> From: Deng, KaiwenX 
> Sent: Thursday, December 7, 2023 10:31 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
> ; Deng, KaiwenX ; Zhang,
> Qi Z ; Ting Xu ; Kevin Liu
> ; Ajit Khaparde ;
> Andrew Rybchenko ; Jerin Jacob
> ; Hemant Agrawal ;
> Somnath Kotur 
> Subject: [PATCH v2] net/ice: fix tso tunnel setting to not take effect
> 
> The Tx offload capabilities of ICE ethdev doesn't include tso tunnel, which 
> will
> result in tso tunnel setting to not take effect.
> 
> The patch adds tunnel tso offload to ICE_TX_NO_VECTOR_FLAGS.
> 
> This commit will add tso tunnel capabilities in ice_dev_info_get().
> 
> Bugzilla ID: 1327
> Fixes: d852fec1be63 ("net/ice: fix Tx offload path choice")
> Fixes: 295968d17407 ("ethdev: add namespace")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Kaiwen Deng 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

RE: [PATCH v4 1/2] net/iavf: add diagnostic support in TX path

2023-12-27 Thread Zhang, Qi Z 



> -Original Message-
> From: Mingjin Ye 
> Sent: Wednesday, December 27, 2023 6:17 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Ye, MingjinX
> ; Wu, Jingjing ; Xing, Beilei
> 
> Subject: [PATCH v4 1/2] net/iavf: add diagnostic support in TX path
> 
> The only way to enable diagnostics for TX paths is to modify the application
> source code. Making it difficult to diagnose faults.
> 
> In this patch, the devarg option "mbuf_check" is introduced and the
> parameters are configured to enable the corresponding diagnostics.

Can you separate this patch into two?

1. introduce the tx burst type and the ops array, this actually fixed the 
multi-process issue, and should be backported into LTS.
2. add mbuf check for tx diagnose 

Btw, please also update the document , so user can know how to use the new 
devarg.

RE: [RFC] ethdev: introduce entropy calculation

2023-12-27 Thread Ori Kam 
Hi Andrew, Stephen, Ferruh and Thomas,

> -Original Message-
> From: Andrew Rybchenko 
> Sent: Saturday, December 16, 2023 11:04 AM
> 
> On 12/15/23 19:21, Thomas Monjalon wrote:
> > 15/12/2023 14:44, Ferruh Yigit:
> >> On 12/14/2023 5:26 PM, Stephen Hemminger wrote:
> >>> On Thu, 14 Dec 2023 17:18:25 +
> >>> Ori Kam  wrote:
> >>>
> >> Since encap groups number of different 5 tuples together, if HW
> doesn’t know
> >> how to RSS
> >> based on the inner application will not be able to get any 
> >> distribution of
> > packets.
> >>
> >> This value is used to reflect the inner packet on the outer header, so
> > distribution
> >> will be possible.
> >>
> >> The main use case is, if application does full offload and implements
> the encap
> > on
> >> the RX.
> >> For example:
> >> Ingress/FDB  match on 5 tuple encap send to hairpin / different port in
> case of
> >> switch.
> >>
> >
> > Smart idea! So basically the user is able to get an idea on how good the
> RSS
> > distribution is, correct?
> >
> 
>  Not exactly, this simply allows the distribution.
>  Maybe entropy is a bad name, this is the name they use in the protocol,
> but in reality
>  this is some hash calculated on the packet header before the encap and
> set in the encap header.
>  Using this hash results in entropy for the packets. Which can be used for
> load balancing.
> 
>  Maybe better name would be:
>  Rte_flow_calc_entropy_hash?
> 
>  or maybe rte_flow_calc_encap_hash (I like it less since it looks like we
> calculate the hash on the encap data and not the inner part)
> 
>  what do you think?
> >>>
> >>> Entropy has meaning in crypto and random numbers generators that is
> different from
> >>> this usage. So entropy is bad name to use. Maybe
> rte_flow_hash_distribution?
> >>>
> >>
> >> Hi Ori,
> >>
> >> Thank you for the description, it is more clear now.
> >>
> >> And unless this is specifically defined as 'entropy' in spec, I am too
> >> for rename.
> >>
> >> At least in VXLAN spec, it is mentioned that this field is to "enable a
> >> level of entropy", but not exactly names it as entropy.
> >
> > Exactly my thought about the naming.
> > Good to see I am not alone thinking this naming is disturbing :)
> 
> I'd avoid usage of term "entropy" in this patch. It is very confusing.

What about rte_flow_calc_encap_hash?

Re: [RFC] ethdev: fast path async flow API

2023-12-27 Thread Stephen Hemminger 
On Wed, 27 Dec 2023 12:57:09 +0200
Dariusz Sosnowski  wrote:

> +/**
> + * @internal
> + *
> + * Fast path async flow functions and related data are held in a flat array, 
> one entry per ethdev.
> + * It is assumed that each entry is read-only and cache aligned.
> + */
> +struct rte_flow_fp_ops {
> + void *ctx;
> + rte_flow_async_create_t async_create;
> + rte_flow_async_create_by_index_t async_create_by_index;
> + rte_flow_async_actions_update_t async_actions_update;
> + rte_flow_async_destroy_t async_destroy;
> + rte_flow_push_t push;
> + rte_flow_pull_t pull;
> + rte_flow_async_action_handle_create_t async_action_handle_create;
> + rte_flow_async_action_handle_destroy_t async_action_handle_destroy;
> + rte_flow_async_action_handle_update_t async_action_handle_update;
> + rte_flow_async_action_handle_query_t async_action_handle_query;
> + rte_flow_async_action_handle_query_update_t 
> async_action_handle_query_update;
> + rte_flow_async_action_list_handle_create_t 
> async_action_list_handle_create;
> + rte_flow_async_action_list_handle_destroy_t 
> async_action_list_handle_destroy;
> + rte_flow_async_action_list_handle_query_update_t 
> async_action_list_handle_query_update;
> +} __rte_cache_aligned;

If you go ahead with this then all usage should be const pointer.
Still think it is bad idea and creates even more technical debt.

[PATCH v3 1/2] net/ice: add Tx scheduling tree dump support

2023-12-27 Thread Qi Zhang 
Added Testpmd CLI support for dumping Tx scheduling tree.

Usage:
testpmd>txsched dump   

The output file is in "dot" format, which can be converted
into an image file using Graphviz.

- In "brief" mode, all scheduling nodes in the tree are displayed.
- In "detail" mode, each node's configuration parameters are also
  displayed.

Renamed `ice_ddp_package.c` to `ice_diagnose.c`, which now contains
all CLI support for diagnostic purposes.

Signed-off-by: Qi Zhang 
---

v3:
- fix incorrect parameter when query rl profile

v2:
- fix CI build issue

 .../ice/{ice_ddp_package.c => ice_diagnose.c} | 367 ++
 drivers/net/ice/ice_ethdev.h  |   3 +
 drivers/net/ice/ice_testpmd.c |  65 
 drivers/net/ice/meson.build   |   2 +-
 drivers/net/ice/version.map   |   1 +
 5 files changed, 437 insertions(+), 1 deletion(-)
 rename drivers/net/ice/{ice_ddp_package.c => ice_diagnose.c} (61%)

diff --git a/drivers/net/ice/ice_ddp_package.c b/drivers/net/ice/ice_diagnose.c
similarity index 61%
rename from drivers/net/ice/ice_ddp_package.c
rename to drivers/net/ice/ice_diagnose.c
index 0aa19eb282..e54554fc9c 100644
--- a/drivers/net/ice/ice_ddp_package.c
+++ b/drivers/net/ice/ice_diagnose.c
@@ -11,6 +11,7 @@
 #include 
 
 #include "ice_ethdev.h"
+#include "ice_rxtx.h"
 
 #define ICE_BLK_MAX_COUNT  512
 #define ICE_BUFF_SEG_HEADER_FLAG   0x1
@@ -507,3 +508,369 @@ int rte_pmd_ice_dump_switch(uint16_t port, uint8_t 
**buff, uint32_t *size)
 
return ice_dump_switch(dev, buff, size);
 }
+
+static void print_rl_profile(struct ice_aqc_rl_profile_elem *prof,
+FILE *stream)
+{
+   fprintf(stream, "\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\tid\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\t%d\n", prof->profile_id);
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\tmax burst size\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\t%d\n", prof->max_burst_size);
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\trate limit multiply\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\t%d\n", prof->rl_multiply);
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\twake up calculation\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\t%d\n", prof->wake_up_calc);
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\trate limit encode\n");
+   fprintf(stream, "\t\t\t\t\t\t\t\t%d\n", prof->rl_encode);
+   fprintf(stream, "\t\t\t\t\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t\n");
+}
+
+static
+void print_elem_type(FILE *stream, u8 type)
+{
+   switch (type) {
+   case 1:
+   fprintf(stream, "root");
+   break;
+   case 2:
+   fprintf(stream, "tc");
+   break;
+   case 3:
+   fprintf(stream, "se_generic");
+   break;
+   case 4:
+   fprintf(stream, "entry_point");
+   break;
+   case 5:
+   fprintf(stream, "leaf");
+   break;
+   default:
+   fprintf(stream, "%d", type);
+   break;
+   }
+}
+
+static
+void print_valid_sections(FILE *stream, u8 vs)
+{
+   if ((vs & 0x1) != 0)
+   fprintf(stream, "generic ");
+   if ((vs & 0x2) != 0)
+   fprintf(stream, "cir ");
+   if ((vs & 0x4) != 0)
+   fprintf(stream, "eir ");
+   if ((vs & 0x8) != 0)
+   fprintf(stream, "shared ");
+}
+
+static
+void print_scheduling_mode(FILE *stream, bool flag)
+{
+   if (flag)
+   fprintf(stream, "pps");
+   else
+   fprintf(stream, "bps");
+}
+
+static
+void print_priority_mode(FILE *stream, bool flag)
+{
+   if (flag)
+   fprintf(stream, "single priority node");
+   else
+   fprintf(stream, "wfq");
+}
+
+static
+void print_node(struct ice_aqc_txsched_elem_data *data,
+   struct ice_aqc_rl_profile_elem *cir_prof,
+   struct ice_aqc_rl_profile_elem *eir_prof,
+   struct ice_aqc_rl_profile_elem *shared_prof,
+   bool detail, FILE *stream)
+{
+   if (!detail)
+   goto edge_only;
+
+   fprintf(stream, "\tNODE_%d [\n", data->node_teid);
+   fprintf(stream, "\t\tlabel=<\n");
+
+   fprintf(stream, "\t\t\t\n");
+
+   fprintf(stream, "\t\t\t\t\n");
+   fprintf(stream, "\t\t\t\t\t teid \n");
+   fprintf(stream, "\t\t\t\t\t %d \n", data->node_teid);
+   fprintf(stream, "\t\t\t\t\n");
+
+   fprintf(stream, "\t\

[PATCH v3 2/2] doc: add document for diagnostic utilities

2023-12-27 Thread Qi Zhang 
Document CLI for diagnose purpose.

Signed-off-by: Qi Zhang 
---
 doc/guides/nics/ice.rst | 36 
 1 file changed, 36 insertions(+)

diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 820a385b06..29309abe4d 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -411,6 +411,42 @@ To start ``testpmd``, and add vlan 10 to port 0:
 
 testpmd> rx_vlan add 10 0
 
+Diagnostic Utilities
+
+
+Dump DDP Package
+
+
+Dump the runtime packet processing pipeline configuration into a
+binary file. This helps the support team diagnose hardware
+configuration issues.
+
+Usage::
+
+testpmd>ddp dump  
+
+Dump Switch Configurations
+~~
+
+Dump detail hardware configurations related to the switch pipeline
+stage into a binary file.
+
+Usage::
+
+testpmd>ddp dump switch  
+
+Dump Tx Scheduling Tree
+~~~
+
+Dump the runtime Tx scheduling tree into a DOT file.
+
+Usage::
+
+testpmd>txsched dump   
+
+In "brief" mode, all scheduling nodes in the tree are displayed.
+In "detail" mode, each node's configuration parameters are also displayed.
+
 Limitations or Known issues
 ---
 
-- 
2.31.1

Re: 21.11.6 patches review and test

2023-12-27 Thread YangHang Liu 
I tested below 18 scenarios on RHEL9 and didn't find any new dpdk issues.

Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
Guest with device assignment(VF) throughput testing: PASS
PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
PVP vhost-user 4Q throughput testing: PASS
PVP vhost-user 2Q throughput testing: PASS
PVP vhost-user 1Q - cross numa node throughput testing: PASS
Guest with vhost-user 2 queues throughput testing: PASS
vhost-user reconnect with dpdk-client, qemu-server qemu reconnect: PASS
vhost-user reconnect with dpdk-client, qemu-server ovs reconnect: PASS
PVP 1Q live migration testing: PASS
PVP 1Q cross numa node live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
Host PF + DPDK testing: PASS
Host VF + DPDK testing: PASS


Test Versions:
qemu-kvm-7.2.0
kernel 5.14
# git describe
v21.11.6-rc1

Test device : X540-AT2 NIC(ixgbe, 10G)

On Wed, Dec 20, 2023 at 9:22 PM Kevin Traynor  wrote:

> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.6.
>
> The planned date for the final release is 12 January.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.6-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Kevin
>
> ---
> Aakash Sasidharan (2):
>   event/cnxk: fix return values for capability API
>   test/event: fix crypto null device creation
>
> Abdullah Sevincer (1):
>   event/dlb2: fix disable PASID
>
> Akhil Goyal (3):
>   common/cnxk: fix different size bit operations
>   net/cnxk: fix uninitialized variable
>   net/cnxk: fix uninitialized variable
>
> Alexander Kozyrev (2):
>   net/mlx5: fix MPRQ stride size to accommodate the headroom
>   ethdev: fix ESP packet type description
>
> Amit Prakash Shukla (2):
>   common/cnxk: fix DPI memzone name
>   dma/cnxk: fix device state
>
> Anoob Joseph (2):
>   cryptodev: add missing doc for security context
>   doc: replace code blocks with includes in security guide
>
> Ashwin Sekhar T K (1):
>   common/cnxk: fix aura disable handling
>
> Beilei Xing (1):
>   net/i40e: fix FDIR queue receives broadcast packets
>
> Bing Zhao (1):
>   net/mlx5: fix shared Rx queue list management
>
> Brian Dooley (3):
>   test/crypto: fix IV in some vectors
>   test/crypto: skip some synchronous tests with CPU crypto
>   examples/ipsec-secgw: fix partial overflow
>
> Bruce Richardson (8):
>   crypto/ipsec_mb: add dependency check for cross build
>   event/sw: remove obsolete comment
>   net/i40e: fix buffer leak on Rx reconfiguration
>   eventdev: fix device pointer for vdev-based devices
>   eventdev: fix missing driver names in info struct
>   ethdev: fix function name in comment
>   event/dlb2: fix name check in self-test
>   event/dlb2: fix missing queue ordering capability flag
>
> Chaoyong He (6):
>   net/nfp: fix Tx descriptor free logic of NFD3
>   net/nfp: fix DMA error after abnormal exit
>   net/nfp: fix link status interrupt
>   net/nfp: fix reconfigure logic in PF initialization
>   net/nfp: fix reconfigure logic in VF initialization
>   net/nfp: fix reconfigure logic of set MAC address
>
> Chengwen Feng (1):
>   net/hns3: fix traffic management thread safety
>
> Ciara Loftus (1):
>   net/af_xdp: make compatible with libbpf 0.8.0
>
> Ciara Power (2):
>   crypto/qat: fix NULL algorithm digest placement
>   crypto/qat: fix raw API null algorithm digest
>
> Dariusz Sosnowski (4):
>   common/mlx5: fix controller index parsing
>   net/mlx5: fix use after free on Rx queue start
>   net/mlx5: fix hairpin queue states
>   net/mlx5: fix hairpin queue unbind
>
> David Christensen (1):
>   net/tap: use MAC address parse API instead of local parser
>
> David Marchand (18):
>   mempool: fix default ops for an empty mempool
>   eventdev: fix symbol export for port maintenance
>   common/cnxk: remove dead Meson code
>   app/bbdev: fix link with NXP LA12XX
>   net/iavf: fix checksum offloading
>   net/iavf: fix Tx debug
>   net/iavf: remove log from Tx prepare function
>   net/iavf: fix TSO with big segments
>   net/ice: remove log from Tx prepare function
>   net/ice: fix TSO with big segments
>   net/mlx5: fix leak in sysfs port name translation
>

[PATCH v5 0/3] net/iavf: support Tx LLDP on scalar and AVX512

2023-12-27 Thread Zhichao Zeng 
This patch set adds an IAVF testpmd command "set tx lldp on|off" which
will register an mbuf dynfield IAVF_TX_LLDP_DYNFIELD to indicate
the need to send LLDP packet. It needs to close the Tx port first,
then "set tx lldp on", and reopen the port to select correct Tx path,
only supports turning on for now.

IAVF will fill the SWTCH_UPLINK bit in the Tx context descriptor based on
the mbuf dynfield to send the LLDP packet.

---
v5: check dynfield at dev_start
v4: fix compile error
v3: non-lldp packet do not use the context descriptor
v2: split into patch set, refine commit log

Zhichao Zeng (3):
  net/iavf: support Tx LLDP on scalar
  net/iavf: support Tx LLDP on AVX512
  net/iavf: add Tx LLDP command

 doc/guides/rel_notes/release_24_03.rst  |  3 +
 drivers/net/iavf/iavf_ethdev.c  |  5 ++
 drivers/net/iavf/iavf_rxtx.c| 21 ++-
 drivers/net/iavf/iavf_rxtx.h|  6 ++
 drivers/net/iavf/iavf_rxtx_vec_avx512.c | 19 ++
 drivers/net/iavf/iavf_rxtx_vec_common.h |  5 ++
 drivers/net/iavf/iavf_testpmd.c | 81 +
 drivers/net/iavf/meson.build|  3 +
 8 files changed, 141 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/iavf/iavf_testpmd.c

-- 
2.34.1

[PATCH v5 1/3] net/iavf: support Tx LLDP on scalar

2023-12-27 Thread Zhichao Zeng 
This patch adds an mbuf dynfield IAVF_TX_LLDP_DYNFIELD to determine
whether or not to fill the SWTCH_UPLINK bit in the Tx context descriptor
to send LLDP packet.

Signed-off-by: Zhichao Zeng 
---
 drivers/net/iavf/iavf_ethdev.c |  5 +
 drivers/net/iavf/iavf_rxtx.c   | 16 ++--
 drivers/net/iavf/iavf_rxtx.h   |  3 +++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index d1edb0dd5c..ef34246d36 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -41,6 +41,7 @@
 #define IAVF_NO_POLL_ON_LINK_DOWN_ARG "no-poll-on-link-down"
 uint64_t iavf_timestamp_dynflag;
 int iavf_timestamp_dynfield_offset = -1;
+int rte_pmd_iavf_tx_lldp_dynfield_offset = -1;
 
 static const char * const iavf_valid_args[] = {
IAVF_PROTO_XTR_ARG,
@@ -1017,6 +1018,10 @@ iavf_dev_start(struct rte_eth_dev *dev)
}
}
 
+   /* Check Tx LLDP dynfield */
+   rte_pmd_iavf_tx_lldp_dynfield_offset =
+   rte_mbuf_dynfield_lookup(IAVF_TX_LLDP_DYNFIELD, NULL);
+
if (iavf_init_queues(dev) != 0) {
PMD_DRV_LOG(ERR, "failed to do Queue init");
return -1;
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index f19aa14646..53b8990b12 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -2418,8 +2418,9 @@ iavf_xmit_cleanup(struct iavf_tx_queue *txq)
 
 /* Check if the context descriptor is needed for TX offloading */
 static inline uint16_t
-iavf_calc_context_desc(uint64_t flags, uint8_t vlan_flag)
+iavf_calc_context_desc(struct rte_mbuf *mb, uint8_t vlan_flag)
 {
+   uint64_t flags = mb->ol_flags;
if (flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG |
RTE_MBUF_F_TX_TUNNEL_MASK | RTE_MBUF_F_TX_OUTER_IP_CKSUM |
RTE_MBUF_F_TX_OUTER_UDP_CKSUM))
@@ -2427,6 +2428,12 @@ iavf_calc_context_desc(uint64_t flags, uint8_t vlan_flag)
if (flags & RTE_MBUF_F_TX_VLAN &&
vlan_flag & IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2)
return 1;
+
+   if (rte_pmd_iavf_tx_lldp_dynfield_offset > 0)
+   if (*RTE_MBUF_DYNFIELD(mb,
+   rte_pmd_iavf_tx_lldp_dynfield_offset, uint8_t *) > 0)
+   return 1;
+
return 0;
 }
 
@@ -2446,6 +2453,11 @@ iavf_fill_ctx_desc_cmd_field(volatile uint64_t *field, 
struct rte_mbuf *m,
<< IAVF_TXD_CTX_QW1_CMD_SHIFT;
}
 
+   if (*RTE_MBUF_DYNFIELD(m,
+   rte_pmd_iavf_tx_lldp_dynfield_offset, uint8_t *) > 0)
+   cmd |= IAVF_TX_CTX_DESC_SWTCH_UPLINK
+   << IAVF_TXD_CTX_QW1_CMD_SHIFT;
+
*field |= cmd;
 }
 
@@ -2826,7 +2838,7 @@ iavf_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
 
nb_desc_data = mb->nb_segs;
nb_desc_ctx =
-   iavf_calc_context_desc(mb->ol_flags, txq->vlan_flag);
+   iavf_calc_context_desc(mb, txq->vlan_flag);
nb_desc_ipsec = !!(mb->ol_flags & RTE_MBUF_F_TX_SEC_OFFLOAD);
 
/**
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index f432f9d956..960618205c 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -107,8 +107,11 @@
 #define IAVF_MAX_DATA_PER_TXD \
(IAVF_TXD_QW1_TX_BUF_SZ_MASK >> IAVF_TXD_QW1_TX_BUF_SZ_SHIFT)
 
+#define IAVF_TX_LLDP_DYNFIELD "intel_pmd_dynfield_tx_lldp"
+
 extern uint64_t iavf_timestamp_dynflag;
 extern int iavf_timestamp_dynfield_offset;
+extern int rte_pmd_iavf_tx_lldp_dynfield_offset;
 
 /**
  * Rx Flex Descriptors
-- 
2.34.1

[PATCH v5 2/3] net/iavf: support Tx LLDP on AVX512

2023-12-27 Thread Zhichao Zeng 
This patch adds an avx512 ctx Tx path that supports context descriptor,
filling in the SWTCH_UPLINK bit based on mbuf
dynfield IAVF_TX_LLDP_DYNFIELD to support sending LLDP packet.

Signed-off-by: Zhichao Zeng 
---
 drivers/net/iavf/iavf_rxtx.c|  5 +
 drivers/net/iavf/iavf_rxtx.h|  3 +++
 drivers/net/iavf/iavf_rxtx_vec_avx512.c | 19 +++
 drivers/net/iavf/iavf_rxtx_vec_common.h |  5 +
 4 files changed, 32 insertions(+)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 53b8990b12..33c2513b5d 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -4051,6 +4051,11 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
dev->tx_pkt_prepare = iavf_prep_pkts;
PMD_DRV_LOG(DEBUG, "Using AVX512 OFFLOAD Vector 
Tx (port %d).",
dev->data->port_id);
+   } else if (check_ret == IAVF_VECTOR_CTX_PATH) {
+   dev->tx_pkt_burst = 
iavf_xmit_pkts_vec_avx512_ctx;
+   dev->tx_pkt_prepare = iavf_prep_pkts;
+   PMD_DRV_LOG(DEBUG, "Using AVX512 CONTEXT Vector 
Tx (port %d).",
+   dev->data->port_id);
} else {
dev->tx_pkt_burst = 
iavf_xmit_pkts_vec_avx512_ctx_offload;
dev->tx_pkt_prepare = iavf_prep_pkts;
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index 960618205c..4e25aa9000 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -66,6 +66,7 @@
 #define IAVF_VECTOR_PATH 0
 #define IAVF_VECTOR_OFFLOAD_PATH 1
 #define IAVF_VECTOR_CTX_OFFLOAD_PATH 2
+#define IAVF_VECTOR_CTX_PATH 3
 
 #define DEFAULT_TX_RS_THRESH 32
 #define DEFAULT_TX_FREE_THRESH   32
@@ -755,6 +756,8 @@ uint16_t iavf_xmit_pkts_vec_avx512_offload(void *tx_queue,
   uint16_t nb_pkts);
 uint16_t iavf_xmit_pkts_vec_avx512_ctx_offload(void *tx_queue, struct rte_mbuf 
**tx_pkts,
  uint16_t nb_pkts);
+uint16_t iavf_xmit_pkts_vec_avx512_ctx(void *tx_queue, struct rte_mbuf 
**tx_pkts,
+ uint16_t nb_pkts);
 int iavf_txq_vec_setup_avx512(struct iavf_tx_queue *txq);
 
 uint8_t iavf_proto_xtr_type_to_rxdid(uint8_t xtr_type);
diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx512.c 
b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
index 7a7df6d258..045cb7fd11 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
@@ -2206,6 +2206,10 @@ ctx_vtx1(volatile struct iavf_tx_desc *txdp, struct 
rte_mbuf *pkt,
low_ctx_qw |= (uint64_t)pkt->vlan_tci << 
IAVF_TXD_CTX_QW0_L2TAG2_PARAM;
}
}
+   if (*RTE_MBUF_DYNFIELD(pkt,
+   rte_pmd_iavf_tx_lldp_dynfield_offset, uint8_t *) > 0)
+   high_ctx_qw |= IAVF_TX_CTX_DESC_SWTCH_UPLINK
+   << IAVF_TXD_CTX_QW1_CMD_SHIFT;
uint64_t high_data_qw = (IAVF_TX_DESC_DTYPE_DATA |
((uint64_t)flags  << IAVF_TXD_QW1_CMD_SHIFT) |
((uint64_t)pkt->data_len << 
IAVF_TXD_QW1_TX_BUF_SZ_SHIFT));
@@ -2258,6 +2262,10 @@ ctx_vtx(volatile struct iavf_tx_desc *txdp,
(uint64_t)pkt[1]->vlan_tci << 
IAVF_TXD_QW1_L2TAG1_SHIFT;
}
}
+   if (*RTE_MBUF_DYNFIELD(pkt[1],
+   rte_pmd_iavf_tx_lldp_dynfield_offset, uint8_t *) > 0)
+   hi_ctx_qw1 |= IAVF_TX_CTX_DESC_SWTCH_UPLINK
+   << IAVF_TXD_CTX_QW1_CMD_SHIFT;
 
if (pkt[0]->ol_flags & RTE_MBUF_F_TX_VLAN) {
if (vlan_flag & IAVF_TX_FLAGS_VLAN_TAG_LOC_L2TAG2) {
@@ -2270,6 +2278,10 @@ ctx_vtx(volatile struct iavf_tx_desc *txdp,
(uint64_t)pkt[0]->vlan_tci << 
IAVF_TXD_QW1_L2TAG1_SHIFT;
}
}
+   if (*RTE_MBUF_DYNFIELD(pkt[0],
+   rte_pmd_iavf_tx_lldp_dynfield_offset, uint8_t *) > 0)
+   hi_ctx_qw0 |= IAVF_TX_CTX_DESC_SWTCH_UPLINK
+   << IAVF_TXD_CTX_QW1_CMD_SHIFT;
 
if (offload) {
iavf_txd_enable_offload(pkt[1], &hi_data_qw1);
@@ -2520,3 +2532,10 @@ iavf_xmit_pkts_vec_avx512_ctx_offload(void *tx_queue, 
struct rte_mbuf **tx_pkts,
 {
return iavf_xmit_pkts_vec_avx512_ctx_cmn(tx_queue, tx_pkts, nb_pkts, 
true);
 }
+
+uint16_t
+iavf_xmit_pkts_vec_avx512_ctx(void *tx_queue, struct rte_mbuf **tx_pkts,
+ uint16_t nb_pkts)
+{
+   return iavf_xmit_pkts_vec_avx512_ctx_cmn(tx_queue, tx_pkts, nb_pkts, 
false);
+}
diff --git a/drive

[PATCH v5 3/3] net/iavf: add Tx LLDP command

2023-12-27 Thread Zhichao Zeng 
This patch adds an IAVF testpmd command "set tx lldp on|off" which
will register an mbuf dynfield IAVF_TX_LLDP_DYNFIELD to indicate
the need to send LLDP packet.

It needs to close the Tx port first, then "set tx lldp on", and reopen
the port to select correct Tx path, only supports turning on for now.

Signed-off-by: Zhichao Zeng 
---
 doc/guides/rel_notes/release_24_03.rst |  3 +
 drivers/net/iavf/iavf_testpmd.c| 81 ++
 drivers/net/iavf/meson.build   |  3 +
 3 files changed, 87 insertions(+)
 create mode 100644 drivers/net/iavf/iavf_testpmd.c

diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 6f8ad27808..f94e18c33a 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -55,6 +55,9 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Updated Intel iavf driver.**
+
+  * Added support for Tx LLDP packet on scalar and avx512.
 
 Removed Items
 -
diff --git a/drivers/net/iavf/iavf_testpmd.c b/drivers/net/iavf/iavf_testpmd.c
new file mode 100644
index 00..07aac07fc3
--- /dev/null
+++ b/drivers/net/iavf/iavf_testpmd.c
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2016 Intel Corporation.
+ */
+
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "iavf.h"
+#include "testpmd.h"
+#include "iavf_rxtx.h"
+
+struct cmd_enable_tx_lldp_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t tx;
+   cmdline_fixed_string_t lldp;
+   cmdline_fixed_string_t what;
+};
+
+static cmdline_parse_token_string_t cmd_enable_tx_lldp_set =
+   TOKEN_STRING_INITIALIZER(struct cmd_enable_tx_lldp_result,
+   set, "set");
+static cmdline_parse_token_string_t cmd_enable_tx_lldp_tx =
+   TOKEN_STRING_INITIALIZER(struct cmd_enable_tx_lldp_result,
+   tx, "tx");
+static cmdline_parse_token_string_t cmd_enable_tx_lldp_lldp =
+   TOKEN_STRING_INITIALIZER(struct cmd_enable_tx_lldp_result,
+   lldp, "lldp");
+static cmdline_parse_token_string_t cmd_enable_tx_lldp_what =
+   TOKEN_STRING_INITIALIZER(struct cmd_enable_tx_lldp_result,
+   what, "on#off");
+
+static void
+cmd_enable_tx_lldp_parsed(void *parsed_result,
+   __rte_unused struct cmdline *cl, __rte_unused void *data)
+{
+   struct cmd_enable_tx_lldp_result *res = parsed_result;
+   const struct rte_mbuf_dynfield iavf_tx_lldp_dynfield = {
+   .name = IAVF_TX_LLDP_DYNFIELD,
+   .size = sizeof(uint8_t),
+   .align = __alignof__(uint8_t),
+   .flags = 0
+   };
+   int offset;
+
+   if (strncmp(res->what, "on", 2) == 0) {
+   offset = rte_mbuf_dynfield_register(&iavf_tx_lldp_dynfield);
+   printf("rte_pmd_iavf_tx_lldp_dynfield_offset: %d", offset);
+   if (offset < 0)
+   fprintf(stderr,
+   "rte mbuf dynfield register failed, offset: 
%d", offset);
+   }
+}
+
+static cmdline_parse_inst_t cmd_enable_tx_lldp = {
+   .f = cmd_enable_tx_lldp_parsed,
+   .data = NULL,
+   .help_str = "set iavf tx lldp on|off",
+   .tokens = {
+   (void *)&cmd_enable_tx_lldp_set,
+   (void *)&cmd_enable_tx_lldp_tx,
+   (void *)&cmd_enable_tx_lldp_lldp,
+   (void *)&cmd_enable_tx_lldp_what,
+   NULL,
+   },
+};
+
+static struct testpmd_driver_commands iavf_cmds = {
+   .commands = {
+   {
+   &cmd_enable_tx_lldp,
+   "set tx lldp (on|off)\n"
+   "Set iavf Tx lldp packet(currently only supported on)\n\n",
+   },
+   { NULL, NULL },
+   },
+};
+TESTPMD_ADD_DRIVER_COMMANDS(iavf_cmds)
diff --git a/drivers/net/iavf/meson.build b/drivers/net/iavf/meson.build
index a6ce2725c3..83aebd5596 100644
--- a/drivers/net/iavf/meson.build
+++ b/drivers/net/iavf/meson.build
@@ -8,6 +8,9 @@ endif
 cflags += ['-Wno-strict-aliasing']
 
 includes += include_directories('../../common/iavf')
+
+testpmd_sources = files('iavf_testpmd.c')
+
 deps += ['common_iavf', 'security', 'cryptodev']
 
 sources = files(
-- 
2.34.1

Re: memory_hotplug_lock deadlock during initialization in Multi-process Mode on DPDK Version 22.11.3 LTS

2023-12-27 Thread Linzhe Lee 
Hi,

Testing on 22.11.4-rc3 confirms that this issue has been resolved.

Thank you very much.

David Marchand  于2023年12月27日周三 18:14写道：
>
> Hello,
>
> Cc: 22.11 stable maintainer for info
>
> On Wed, Dec 27, 2023 at 4:14 AM Linzhe Lee
>  wrote:
> >
> > Dear Team,
> >
> > I hope this message finds you well.
> >
> > We have encountered a recurring deadlock issue within the function
> > rte_rwlock_write_lock in the DPDK version 22.11.3 LTS.
> >
> > It appears to be related to a known matter addressed in
> > https://bugs.dpdk.org/show_bug.cgi?id=1277 and subsequently resolved
> > in version 23.11.
> >
> > I kindly propose the backporting of this fix to the 22.11 branch,
> > considering its status as a long-term support (LTS) version.
>
> As far as I can see, this fix is part of the 22.11.4-rc1 tag.
>
> A 22.11.4-rc3 tag was recently released.
> https://git.dpdk.org/dpdk-stable/tag/?h=v22.11.4-rc3
> Could you have a try with it?
>
>
> Thanks.
>
> --
> David Marchand
>