[PATCH v3] net/ixgbe: add vector Rx parameter check

2021-12-10 Thread Bin Zheng 
Under the circumstance that `rx_tail` wrap back to zero
and the advance speed of `rx_tail` is greater than `rxrearm_start`,
`rx_tail` will catch up with `rxrearm_start` and surpass it.
This may cause some mbufs be reused by application.

So we need to make some restrictions to ensure that
 `rx_tail` will not exceed `rxrearm_start`.

e.g.

RDH: 972 RDT: 991 rxrearm_nb: 991 rxrearm_start: 992 rx_tail: 959
RDH: 1004 RDT: 1023 rxrearm_nb: 991 rxrearm_start: 0 rx_tail: 991
RDH: 12 RDT: 31 rxrearm_nb: 991 rxrearm_start: 32 rx_tail: 1023
RDH: 31 RDT: 63 rxrearm_nb: 960 rxrearm_start: 64 rx_tail: 0
RDH: 95 RDT: 95 rxrearm_nb: 1016 rxrearm_start: 96 rx_tail: 88
RDH: 95 RDT: 127 rxrearm_nb: 991 rxrearm_start: 128 rx_tail: 95
...
RDH: 908 RDT: 927 rxrearm_nb: 991 rxrearm_start: 928 rx_tail: 895
RDH: 940 RDT: 959 rxrearm_nb: 991 rxrearm_start: 960 rx_tail: 927
RDH: 980 RDT: 991 rxrearm_nb: 991 rxrearm_start: 992 rx_tail: 959
RDH: 991 RDT: 991 rxrearm_nb: 1026 rxrearm_start: 992 rx_tail: 994

when `rx_tail` catches up with `rxrearm_start`,
2(994 - 992) mbufs be reused by application !

Bugzilla ID: 882
Fixes: 5a3cca342417 ("net/ixgbe: fix vector Rx")
Cc: jia@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Bin Zheng 
---
 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index 1eed949495..4654d0adec 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -364,6 +364,17 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
uint8_t vlan_flags;
uint16_t udp_p_flag = 0; /* Rx Descriptor UDP header present */
 
+   /*
+* Under the circumstance that `rx_tail` wrap back to zero
+* and the advance speed of `rx_tail` is greater than `rxrearm_start`,
+* `rx_tail` will catch up with `rxrearm_start` and surpass it.
+* This may cause some mbufs be reused by application.
+*
+* So we need to make some restrictions to ensure that
+* `rx_tail` will not exceed `rxrearm_start`.
+*/
+   nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_RXQ_REARM_THRESH);
+
/* nb_pkts has to be floor-aligned to RTE_IXGBE_DESCS_PER_LOOP */
nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
 
-- 
2.25.1

Re: [PATCH v14 04/11] app/test: skip interrupt tests on Windows

2021-12-10 Thread Dmitry Kozlyuk 
2021-12-09 16:39 (UTC+), Bruce Richardson:
> On Thu, Dec 09, 2021 at 04:17:08PM +, Bruce Richardson wrote:
> [...]
> > I'm wondering if a reasonable compromise solution might be to have the
> > build system expose a usable RTE_EXEC_ENV symbol that can be used in C-code
> > if statements rather than just in ifdefs. That would allow us to easily add
> > e.g.
> > 
> > if (RTE_EXEC_ENV == rte_env_linux)
> > return TEST_SKIPPED;
> > 
> > into each test function needing it. Two lines of C-code is a lot easier to
> > add and manage than #ifdefs covering the whole file, or alternative lists
> > in meson.
> >   
> Quick patch to allow C-code comparisons:
> 
> diff --git a/lib/eal/meson.build b/lib/eal/meson.build
> index 1722924f67..b5b9fa14b4 100644
> --- a/lib/eal/meson.build
> +++ b/lib/eal/meson.build
> @@ -10,6 +10,12 @@ if not is_windows
>  subdir('unix')
>  endif
>  
> +exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2}
> +foreach env, id:exec_envs
> +dpdk_conf.set('RTE_ENV_' + env.to_upper(), id)
> +endforeach
> +dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env])
> +
>  dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
>  subdir(exec_env)
> 
> A slightly simpler patch would just expose the environment as a string as
> e.g. "linux", but I think numeric ids just make the code better rather than
> having string comparisons. Alternatively, this could also be done via
> C-code with ifdefs in EAL, but as it stands this meson change allows:
> 
>   if (RTE_EXEC_ENV == RTE_ENV_WINDOWS)
>  ...
> 
> or:
> 
>   switch (RTE_EXEC_ENV) {
> case RTE_ENV_LINUX: ... ; break;
> case RTE_ENV_FREEBSD: ... ; break;
> case RTE_ENV_WINDOWS: ... ; break;
>   }
> 
> Thoughts?

I like this.
Even outside of tests more code can be made to compile on all platforms
(e.g. ixgbe_wait_for_link_up).
Alternative naming: RTE_EXEC_ENV_IS_* (similar to RTE_CC_IS_*),
which does not allow switch statements, but shortens most practical cases.
Will Coverity understand that if a condition is always false,
variables beneath still may be used on another platform?

Re: [PATCH v14 04/11] app/test: skip interrupt tests on Windows

2021-12-10 Thread Bruce Richardson 
On Fri, Dec 10, 2021 at 12:23:59PM +0300, Dmitry Kozlyuk wrote:
> 2021-12-09 16:39 (UTC+), Bruce Richardson:
> > On Thu, Dec 09, 2021 at 04:17:08PM +, Bruce Richardson wrote:
> > [...]
> > > I'm wondering if a reasonable compromise solution might be to have the
> > > build system expose a usable RTE_EXEC_ENV symbol that can be used in 
> > > C-code
> > > if statements rather than just in ifdefs. That would allow us to easily 
> > > add
> > > e.g.
> > > 
> > > if (RTE_EXEC_ENV == rte_env_linux)
> > > return TEST_SKIPPED;
> > > 
> > > into each test function needing it. Two lines of C-code is a lot easier to
> > > add and manage than #ifdefs covering the whole file, or alternative lists
> > > in meson.
> > >   
> > Quick patch to allow C-code comparisons:
> > 
> > diff --git a/lib/eal/meson.build b/lib/eal/meson.build
> > index 1722924f67..b5b9fa14b4 100644
> > --- a/lib/eal/meson.build
> > +++ b/lib/eal/meson.build
> > @@ -10,6 +10,12 @@ if not is_windows
> >  subdir('unix')
> >  endif
> >  
> > +exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2}
> > +foreach env, id:exec_envs
> > +dpdk_conf.set('RTE_ENV_' + env.to_upper(), id)
> > +endforeach
> > +dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env])
> > +
> >  dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
> >  subdir(exec_env)
> > 
> > A slightly simpler patch would just expose the environment as a string as
> > e.g. "linux", but I think numeric ids just make the code better rather than
> > having string comparisons. Alternatively, this could also be done via
> > C-code with ifdefs in EAL, but as it stands this meson change allows:
> > 
> >   if (RTE_EXEC_ENV == RTE_ENV_WINDOWS)
> >  ...
> > 
> > or:
> > 
> >   switch (RTE_EXEC_ENV) {
> > case RTE_ENV_LINUX: ... ; break;
> > case RTE_ENV_FREEBSD: ... ; break;
> > case RTE_ENV_WINDOWS: ... ; break;
> >   }
> > 
> > Thoughts?
> 
> I like this.
> Even outside of tests more code can be made to compile on all platforms
> (e.g. ixgbe_wait_for_link_up).
> Alternative naming: RTE_EXEC_ENV_IS_* (similar to RTE_CC_IS_*),
> which does not allow switch statements, but shortens most practical cases.

Sure. I wonder if it is worthwhile implementing both, since it's not a
large amount of code.

> Will Coverity understand that if a condition is always false,
> variables beneath still may be used on another platform?

That I don't know, unfortunately. Perhaps some coverity experts can weigh
in.

/Bruce

[RFC PATCH] net/af_xdp: use libxdp if available

2021-12-10 Thread Ciara Loftus 
AF_XDP support is deprecated in libbpf since v0.7.0 [1]. The
libxdp library now provides the functionality which once was in
libbpf and which the AF_XDP PMD relies on. This commit updates the
AF_XDP meson build to use the libxdp library if available. If it
is not available, only versions of libbpf prior to v0.7.0 are
allowed, as they still contain the required AF_XDP functionality.

libbpf still remains a dependency even if libxdp is present, as we
use libbpf APIs for program loading.

[1] https://github.com/libbpf/libbpf/commit/277846bc6c15

Signed-off-by: Ciara Loftus 
---
 doc/guides/nics/af_xdp.rst |  4 +--
 doc/guides/rel_notes/release_22_03.rst |  4 +++
 drivers/net/af_xdp/compat.h|  4 +++
 drivers/net/af_xdp/meson.build | 45 +-
 drivers/net/af_xdp/rte_eth_af_xdp.c|  1 -
 5 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index c9d0e1ad6c..966f713c11 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -43,9 +43,7 @@ Prerequisites
 This is a Linux-specific PMD, thus the following prerequisites apply:
 
 *  A Linux Kernel (version > v4.18) with XDP sockets configuration enabled;
-*  libbpf (within kernel version > v5.1-rc4) with latest af_xdp support 
installed,
-   User can install libbpf via `make install_lib` && `make install_headers` in
-   /tools/lib/bpf;
+*  Both libxdp and libbpf libraries installed, or, libbpf <=v0.6.0
 *  A Kernel bound interface to attach to;
 *  For need_wakeup feature, it requires kernel version later than v5.3-rc1;
 *  For PMD zero copy, it requires kernel version later than v5.4-rc1;
diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa9..acf0f66fa8 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -55,6 +55,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Update AF_XDP PMD**
+
+  * Added libxdp support.
+
 
 Removed Items
 -
diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h
index 3880dc7dd7..245df1b109 100644
--- a/drivers/net/af_xdp/compat.h
+++ b/drivers/net/af_xdp/compat.h
@@ -2,7 +2,11 @@
  * Copyright(c) 2020 Intel Corporation.
  */
 
+#ifdef RTE_LIBRTE_AF_XDP_PMD_LIBXDP
+#include 
+#else
 #include 
+#endif
 #include 
 #include 
 
diff --git a/drivers/net/af_xdp/meson.build b/drivers/net/af_xdp/meson.build
index 3ed2b29784..dc4f53352e 100644
--- a/drivers/net/af_xdp/meson.build
+++ b/drivers/net/af_xdp/meson.build
@@ -9,19 +9,48 @@ endif
 
 sources = files('rte_eth_af_xdp.c')
 
+xdp_dep = dependency('libxdp', required: false, method: 'pkg-config')
+if not xdp_dep.found()
+xdp_dep = cc.find_library('xdp', required: false)
+endif
+
 bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
 if not bpf_dep.found()
 bpf_dep = cc.find_library('bpf', required: false)
 endif
 
-if bpf_dep.found() and cc.has_header('bpf/xsk.h') and 
cc.has_header('linux/if_xdp.h')
-ext_deps += bpf_dep
-bpf_ver_dep = dependency('libbpf', version : '>=0.2.0',
-required: false, method: 'pkg-config')
-if bpf_ver_dep.found()
-dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_SHARED_UMEM', 1)
+if cc.has_header('linux/if_xdp.h')
+if xdp_dep.found() and cc.has_header('xdp/xsk.h')
+if bpf_dep.found() and cc.has_header('bpf/bpf.h')
+dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_LIBXDP', 1)
+dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_SHARED_UMEM', 1)
+ext_deps += xdp_dep
+ext_deps += bpf_dep
+else
+build = false
+reason = 'missing dependency, libbpf'
+endif
+elif bpf_dep.found() and cc.has_header('bpf/xsk.h') and 
cc.has_header('bpf/bpf.h')
+# libxdp not found. Rely solely on libbpf for xsk functionality
+# which is only available in versions <= v0.6.0.
+bpf_ver_dep = dependency('libbpf', version : '<=0.6.0',
+ required: false, method: 'pkg-config')
+if bpf_ver_dep.found()
+ext_deps += bpf_dep
+bpf_shumem_ver_dep = dependency('libbpf', version : '>=0.2.0',
+required: false, method: 'pkg-config')
+if bpf_shumem_ver_dep.found()
+dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_SHARED_UMEM', 1)
+endif
+else
+build = false
+reason = 'missing dependency, "libxdp" or "libbpf <= v0.6.0"'
+endif
+else
+build = false
+reason = 'missing dependency, "libxdp" and "libbpf"'
 endif
 else
 build = false
-reason = 'missing dependency, "libbpf"'
-endif
+reason = 'missing header, "linux/if_xdp.h"'
+endif
\ No newline at end of file
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c 
b/drivers/

RE: 20.11.4 patches review and test

2021-12-10 Thread Jiang, YuX 
> -Original Message-
> From: Jiang, YuX 
> Sent: Thursday, December 9, 2021 6:01 PM
> To: Xueming Li ; sta...@dpdk.org; Lin, Xueqin
> 
> Cc: dev@dpdk.org; Abhishek Marathe ;
> Ali Alnubani ; Walker, Benjamin
> ; David Christensen
> ; Govindharajan, Hariprasad
> ; Hemant Agrawal
> ; Stokes, Ian ; Jerin
> Jacob ; Mcnamara, John ;
> Ju-Hyoung Lee ; Kevin Traynor
> ; Luca Boccassi ; Pei Zhang
> ; Xu, Qian Q ; Raslan
> Darawsheh ; Thomas Monjalon
> ; Peng, Yuan ; Chen,
> Zhaoyan 
> Subject: RE: 20.11.4 patches review and test
> 
> > -Original Message-
> > From: Xueming Li 
> > Sent: Tuesday, December 7, 2021 12:15 AM
> > To: sta...@dpdk.org
> > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe
> > ; Ali Alnubani ;
> > Walker, Benjamin ; David Christensen
> > ; Govindharajan, Hariprasad
> > ; Hemant Agrawal
> > ; Stokes, Ian ; Jerin
> > Jacob ; Mcnamara, John
> ;
> > Ju-Hyoung Lee ; Kevin Traynor
> > ; Luca Boccassi ; Pei Zhang
> > ; Xu, Qian Q ; Raslan
> > Darawsheh ; Thomas Monjalon
> ;
> > Peng, Yuan ; Chen, Zhaoyan
> > 
> > Subject: 20.11.4 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 20.11.4.
> >
> > The planned date for the final release is 31th December.
> >
> > 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=v20.11.4-rc1
> >
> > These patches are located at branch 20.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Xueming Li 
> >
> Update the test status for Intel part. Till now dpdk20.11.4-rc1 test execution
> rate is 80%. Currently, find three bugs, two bugs have fix now.
> # Basic Intel(R) NIC testing
> * Build or compile:
>   *Build: cover the build test combination with latest GCC/Clang/ICC
> version and the popular OS revision such as Ubuntu20.04, Fedora34, RHEL8.4,
> etc.
>   - All test done.
>   - Two bugs are found in 20.11.4-rc1.
>   - dpdk-20.11.4]kernel/linux/kni/rte_kni.ko build
> failed on OpenSuse15.3 with gcc7.5.0&clang11.0.1
>   - fix link:
> http://inbox.dpdk.org/stable/20211208103410.835542-1-
> ferruh.yi...@intel.com/T/#u , verify passed by Intel
>   - https://bugs.dpdk.org/show_bug.cgi?id=894
> [dpdk-20.11.4] lib/librte_eal.a.p/librte_eal_common_rte_random.c.obj build
> failed on WIN10 with clang8.0.0
>   - fix link:
> http://inbox.dpdk.org/stable/20211207141644.369624-1-
> dmitry.kozl...@gmail.com/T/#u, verify passed by Intel
>   * PF(i40e, ixgbe): test scenarios including
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
>   - All test done. No new issue is found.
>   * VF(i40e, ixgbe): test scenarios including VF-
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> 
>   - All test done. No new issue is found.
>   * PF/VF(ice): test scenarios including Switch features/Package
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Share
> code update/Flexible Descriptor, etc.
>   - Execution rate is 80%. No new issue is found.
>   * Intel NIC single core/NIC performance: test scenarios including
> PF/VF single core performance test, RFC2544 Zero packet loss performance
> test, etc.
>   - Execution rate is 50%. No big performance drop.
>   * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic
> test - QAT&SW/FIB library, etc.
>   - All passed.
> # Basic cryptodev and virtio testing
>   * Virtio: both function and performance test are covered. Such as
> PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf
> testing/VMAWARE ESXI 7.0u3, etc.
>   - Execution rate is 80%. No new issue is found.
>   * Cryptodev:
>   *Function test: test scenarios including Cryptodev API
> testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
>   - All test done.
>   - One new bug about "[dpdk-LTS-20.11.4-rc1]
> cryptodev_qat_asym_autotest is failing" is found, Intel dev is under
> investigating.
>   bad commit id is commit
> 2f2c2b5b7e7ae4942b4b3686bce2eb856fee447d
>   Author: Przemyslaw Zegan
> 
>   Date: Wed Nov 3 15:08:23 2021 +
>   common/qat: fix queue pairs number
>   *Performance test: test scenarios including Thoughput
> Performance /Cryptodev Latency, etc.
>   - All test done.

Update the test status for Intel part. Till now dpdk20.11.4-rc1 test is almost 
finished. Totally find three bugs, two bugs have fix now.
# Basic Intel(R) NIC

Re: [PATCH] devtools/cocci: update cocci for ethdev namespace

2021-12-10 Thread Ferruh Yigit 

On 12/8/2021 11:45 AM, Aman Singh wrote:

Added two specific execptions for ETH_SPEED_10G
and ETH_SPEED_25G to avoid there name change.

Signed-off-by: Aman Singh 
---
  devtools/cocci/namespace_ethdev.cocci | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/devtools/cocci/namespace_ethdev.cocci 
b/devtools/cocci/namespace_ethdev.cocci
index d5de41e117..3afa1fb386 100644
--- a/devtools/cocci/namespace_ethdev.cocci
+++ b/devtools/cocci/namespace_ethdev.cocci
@@ -16,7 +16,8 @@ exception_matches = 
["ETH_VLAN_FILTER_CLASSIFY","ETH_VLAN_FILTER_ANY",
  "RTE_FDIR_NO","RTE_FDIR_REPORT","ETH_MAX_RX_CLIENTS_E1H",
  "ETH_MAX_AGGREGATION_QUEUES_E1","ETH_RSS_ENGINE_NUM","ETH_NUM_MAC_FILTERS",
  "ETH_MAX_NUM_RX_QUEUES_PER_VF_QUAD","ETH_RSS_IND_TABLE_ENTRIES_NUM",
-"ETH_RSS_KEY_SIZE_REGS","ETH_NUM_STATISTIC_COUNTERS","ETH_SPEED_"]
+"ETH_RSS_KEY_SIZE_REGS","ETH_NUM_STATISTIC_COUNTERS","ETH_SPEED_10G",
+"ETH_SPEED_25G"]
  
  if any(x in I for x in exception_matches):

  coccinelle .J= I;



Thanks Aman,

I confirm 'ETH_SPEED_NUM_*' issue is resolved.


There are a few more quirks, can you please check if they are fixable,
if so they can be in v2 of this patch:

1) 'ETH_TUNNEL_FILTER_' ones seems not updated, like:
ETH_TUNNEL_FILTER_OMAC -> RTE_ETH_TUNNEL_FILTER_OMAC
ETH_TUNNEL_FILTER_OIP  -> RTE_ETH_TUNNEL_FILTER_OIP

But need to be careful some of the already has RTE_ prefix, like:
RTE_TUNNEL_FILTER_IMAC_IVLAN
RTE_TUNNEL_FILTER_IMAC_IVLAN_TENID
...


2) Script seems not updating the ones with macro defines with line
continuation, there are a few different instance of them, if it is
easy we can update script, else they can be ignored. Samples:

drivers/net/ice/ice_ethdev.c:
   #define ICE_RSS_HF_ALL ( \
   ETH_RSS_IPV4 | \
   ETH_RSS_IPV6 | \
   ETH_RSS_NONFRAG_IPV4_UDP | \
   ETH_RSS_NONFRAG_IPV6_UDP | \
   ETH_RSS_NONFRAG_IPV4_TCP | \
   ETH_RSS_NONFRAG_IPV6_TCP | \
   ETH_RSS_NONFRAG_IPV4_SCTP | \
   ETH_RSS_NONFRAG_IPV6_SCTP | \
   ETH_RSS_FRAG_IPV4 | \
   ETH_RSS_FRAG_IPV6)

drivers/net/hns3/hns3_rxtx.c:
   #define HNS3_DEV_TX_CSKUM_TSO_OFFLOAD_MASK (\
   DEV_TX_OFFLOAD_IPV4_CKSUM | \
   DEV_TX_OFFLOAD_TCP_CKSUM | \
   DEV_TX_OFFLOAD_UDP_CKSUM | \
   DEV_TX_OFFLOAD_SCTP_CKSUM | \
   DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | \
   DEV_TX_OFFLOAD_OUTER_UDP_CKSUM | \
   DEV_TX_OFFLOAD_TCP_TSO | \
   DEV_TX_OFFLOAD_VXLAN_TNL_TSO | \
   DEV_TX_OFFLOAD_GRE_TNL_TSO | \
   DEV_TX_OFFLOAD_GENEVE_TNL_TSO)


3) in bonding (eth_bond_private.h),
RTE_RETA_GROUP_SIZE & ETH_RSS_RETA_SIZE_512 seems not updated,
bonding on its own doesn't matter much, but may be good to investigate
why it is not updated, what is missed.


4) Similarly, in 'mlx5/mlx5_rxq.c', ETH_MQ_RX_RSS seems not updated,
not much matter on its own, but may be good to investigate


5) This is optional but script updates old 'ETH_MIRROR_*' too, but
those macros are removed from latest upstream, so may be excluded.

RE: [dpdk-dev] [Bug 826] red_autotest random failures

2021-12-10 Thread Liguzinski, WojciechX 
Hi,

Unfortunately, I haven’t been able to move the investigation much further.
I have been running those tests on machines with higher amount of RAM than 4GB, 
but with hugepages set there to 1GB and using the script provided by Lincoln.
For several runs red_autotest tests didn’t fail even once, not giving any clue 
what might be the cause of what’s happening on CI.

+Adding Marcin Danilewicz
To let you know, Marcin Danilewicz will be taking over my tasks, so for any 
further aspects please include or direct messages to him.

Best Regards,
Wojciech


From: Liguzinski, WojciechX 
Sent: Tuesday, November 30, 2021 8:51 AM
To: Brandon Lo 
Cc: Lincoln Lavoie ; Dumitrescu, Cristian 
; Thomas Monjalon ; David 
Marchand ; Ajmera, Megha ; 
Singh, Jasvinder ; dev ; Aaron Conole 
; Yigit, Ferruh ; c...@dpdk.org; 
Zegota, AnnaX 
Subject: RE: [dpdk-dev] [Bug 826] red_autotest random failures

Ok, thanks Brandon for the tip :)
Let’s see if I can setup the machine with such configuration.

Cheers,
Wojciech

From: Brandon Lo mailto:b...@iol.unh.edu>>
Sent: Monday, November 29, 2021 6:58 PM
To: Liguzinski, WojciechX 
mailto:wojciechx.liguzin...@intel.com>>
Cc: Lincoln Lavoie mailto:lylav...@iol.unh.edu>>; 
Dumitrescu, Cristian 
mailto:cristian.dumitre...@intel.com>>; Thomas 
Monjalon mailto:tho...@monjalon.net>>; David Marchand 
mailto:david.march...@redhat.com>>; Ajmera, Megha 
mailto:megha.ajm...@intel.com>>; Singh, Jasvinder 
mailto:jasvinder.si...@intel.com>>; dev 
mailto:dev@dpdk.org>>; Aaron Conole 
mailto:acon...@redhat.com>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; 
c...@dpdk.org; Zegota, AnnaX 
mailto:annax.zeg...@intel.com>>
Subject: Re: [dpdk-dev] [Bug 826] red_autotest random failures

On Wed, Nov 24, 2021 at 2:48 AM Liguzinski, WojciechX 
mailto:wojciechx.liguzin...@intel.com>> wrote:
Hi,

Thanks Lincoln, I will also have a try with such script.

Cheers,
Wojciech

Hello Wojciech,

I also recommend trying to run the test with around 4GB of RAM and 2GB of 
hugepages to see if it fails. That is roughly the number of resources we have 
per machine that is completely dedicated to unit tests. The amount of RAM 
available can sometimes increase depending on how many jobs are running per 
machine, but 4GB is the lowest it can go for the unit test job.

Thanks,
Brandon



--
Brandon Lo
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
b...@iol.unh.edu
www.iol.unh.edu

[PATCH 1/3] crypto/ipsec_mb: fix qp setup null pointer dereference

2021-12-10 Thread Ciara Power 
When setting up a qp in a secondary process, the local qp pointer is set
to the stored device qp, configured by the primary process for that
device, but only if that device qp is not NULL.
If the device qp was not set up correctly by the primary process and has
a NULL value, the local qp variable stays at the default initialised
value, NULL. This causes a NULL pointer dereference later in the
function when using the qp value.

This is fixed by always setting the local qp to the value of the device
qp stored, and then checking if qp is NULL, returning an error if it is.

Coverity issue: 374382
Fixes: 72a169278a56 ("crypto/ipsec_mb: support multi-process")
Cc: sta...@dpdk.org

Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c 
b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
index 189262c4ad..6efa417d67 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
@@ -221,8 +221,11 @@ ipsec_mb_qp_setup(struct rte_cryptodev *dev, uint16_t 
qp_id,
IMB_VERSION_STR, IMB_MP_REQ_VER_STR);
return -EINVAL;
 #endif
-   if (dev->data->queue_pairs[qp_id] != NULL)
-   qp = dev->data->queue_pairs[qp_id];
+   qp = dev->data->queue_pairs[qp_id];
+   if (qp == NULL) {
+   IPSEC_MB_LOG(ERR, "Primary process hasn't configured 
device qp.");
+   return -EINVAL;
+   }
} else {
/* Free memory prior to re-allocation if needed. */
if (dev->data->queue_pairs[qp_id] != NULL)
-- 
2.25.1

[PATCH 2/3] crypto/ipsec_mb: fix qp cleanup null pointer dereference

2021-12-10 Thread Ciara Power 
The qp was being used in the cleanup without checking if it was non NULL.
A check is now added to verify qp is non NULL before use.

Coverity issue: 374375
Fixes: c75542ae4200 ("crypto/ipsec_mb: introduce IPsec_mb framework")
Cc: roy.fan.zh...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c 
b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
index 6efa417d67..1ebd23e8f0 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
@@ -285,6 +285,8 @@ ipsec_mb_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
return 0;
 
 qp_setup_cleanup:
+   if (qp == NULL)
+   return ret;
 #if IMB_VERSION(1, 1, 0) > IMB_VERSION_NUM
if (qp->mb_mgr)
free_mb_mgr(qp->mb_mgr);
@@ -294,8 +296,7 @@ ipsec_mb_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->mb_mgr_mz)
rte_memzone_free(qp->mb_mgr_mz);
 #endif
-   if (qp)
-   rte_free(qp);
+   rte_free(qp);
return ret;
 }
 
-- 
2.25.1

[PATCH 3/3] crypto/ipsec_mb: fix tainted data for session

2021-12-10 Thread Ciara Power 
Downcasting a void * to struct aesni_gcm_session * caused the session
data to be treated as tainted.
Removing the void * temporary variable and adding a cast avoids this
issue.

Coverity issue: 374377
Fixes: 746825e5c0ea ("crypto/ipsec_mb: move aesni_gcm PMD")
Cc: piotrx.bronow...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Ciara Power 
---
 drivers/crypto/ipsec_mb/pmd_aesni_gcm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
index 2c203795ab..e5ad629fe5 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
@@ -713,19 +713,17 @@ aesni_gcm_process_bulk(struct rte_cryptodev *dev,
__rte_unused union rte_crypto_sym_ofs ofs,
struct rte_crypto_sym_vec *vec)
 {
-   void *sess_priv;
struct aesni_gcm_session *s;
struct gcm_context_data gdata_ctx;
IMB_MGR *mb_mgr;
 
-   sess_priv = get_sym_session_private_data(sess, dev->driver_id);
-   if (unlikely(sess_priv == NULL)) {
+   s = (struct aesni_gcm_session *) get_sym_session_private_data(sess,
+   dev->driver_id);
+   if (unlikely(s == NULL)) {
aesni_gcm_fill_error_code(vec, EINVAL);
return 0;
}
 
-   s = sess_priv;
-
/* get per-thread MB MGR, create one if needed */
mb_mgr = get_per_thread_mb_mgr();
if (unlikely(mb_mgr == NULL))
-- 
2.25.1

[PATCH] build/eal: add OS defines for C conditional checks

2021-12-10 Thread Bruce Richardson 
Define a set of macros in the build configuration to allow C runtime
code to check the current OS environment. This saves the user having to
use ifdefs for e.g. disabling particular tests on Windows. See included
documentation changes for usage examples.

Signed-off-by: Bruce Richardson 
---
 doc/guides/contributing/coding_style.rst | 42 ++--
 lib/eal/meson.build  |  7 
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/doc/guides/contributing/coding_style.rst 
b/doc/guides/contributing/coding_style.rst
index 0ec37c019b..e52ecb2b60 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -136,6 +136,12 @@ For example:
 Conditional Compilation
 ~~~
 
+.. note::
+
+ Conditional compilation should be used only when absolutely necessary, as it 
increases the number of target binaries that need to be built and tested.
+ See below for details of some utility macros/defines available to allow 
ifdefs/macros to be replaced by C conditional in some cases.
+
+
 * When code is conditionally compiled using ``#ifdef`` or ``#if``, a comment 
may be added following the matching
   ``#endif`` or ``#else`` to permit the reader to easily discern where 
conditionally compiled code regions end.
 * This comment should be used only for (subjectively) long regions, regions 
greater than 20 lines, or where a series of nested ``#ifdef``'s may be 
confusing to the reader.
@@ -165,9 +171,41 @@ Conditional Compilation
  /* Or here. */
  #endif /* !COMPAT_43 */
 
-.. note::
+Defines to Avoid Conditional Compilation
+
+
+In many cases in DPDK, one wants to optionally compile code based on the 
target platform,
+or runtime environment.
+While this can be done using the conditional compilation directives,
+e.g. ``#ifdef RTE_EXEC_ENV_LINUX``, present in DPDK for many releases,
+this can also be done in many cases using regular ``if`` statements and the 
following defines:
+
+* ``RTE_ENV_FREEBSD``, ``RTE_ENV_LINUX``, ``RTE_ENV_WINDOWS`` - these define 
ids for each operating system environment.
+* ``RTE_EXEC_ENV`` - this defines the id of the current environment, i.e. one 
of the items in list above.
+* ``RTE_EXEC_ENV_IS_FREEBSD``, ``RTE_EXEC_ENV_IS_LINUX``, 
``RTE_EXEC_ENV_IS_WINDOWS`` - 0/1 values indicating if the current environment 
is that specified,
+  shortcuts for checking e.g. ``RTE_EXEC_ENV == RTE_ENV_WINDOWS``
+
+Examples of use:
+
+.. code-block:: c
+
+  /* report a unit tests as unsupported on Windows */
+  if (RTE_EXEC_ENV_IS_WINDOWS)
+ return TEST_SKIPPED;
+
+  /* set different default values depending on OS Environment */
+  switch (RTE_EXEC_ENV) {
+ case RTE_ENV_FREEBSD:
+ default = x;
+ break;
+ case RTE_ENV_LINUX:
+ default = y;
+ break;
+ case RTE_ENV_WINDOWS:
+ default = z;
+ break;
+  }
 
- Conditional compilation should be used only when absolutely necessary, as it 
increases the number of target binaries that need to be built and tested.
 
 C Types
 ---
diff --git a/lib/eal/meson.build b/lib/eal/meson.build
index 1722924f67..056beb9461 100644
--- a/lib/eal/meson.build
+++ b/lib/eal/meson.build
@@ -10,6 +10,13 @@ if not is_windows
 subdir('unix')
 endif
 
+exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2}
+foreach env, id:exec_envs
+dpdk_conf.set('RTE_ENV_' + env.to_upper(), id)
+dpdk_conf.set10('RTE_EXEC_ENV_IS_' + env.to_upper(), (exec_env == env))
+endforeach
+dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env])
+
 dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
 subdir(exec_env)
 
-- 
2.32.0

[RFC PATCH] net/af_xdp: reenable secondary process support

2021-12-10 Thread Ciara Loftus 
Secondary process support had been disabled for the AF_XDP PMD
because there was no logic in place to share the AF_XDP socket
file descriptors between the processes. This commit introduces
this logic using the IPC APIs.

Since AF_XDP rings are single-producer single-consumer, rx/tx
in the secondary process is disabled. However other operations
including retrieval of stats are permitted.

Signed-off-by: Ciara Loftus 
---
 doc/guides/nics/af_xdp.rst |   9 ++
 doc/guides/nics/features/af_xdp.ini|   1 +
 doc/guides/rel_notes/release_22_03.rst |   4 +
 drivers/net/af_xdp/rte_eth_af_xdp.c| 210 +++--
 4 files changed, 210 insertions(+), 14 deletions(-)

diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index c9d0e1ad6c..40ace58de0 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -143,4 +143,13 @@ Limitations
   NAPI context from a watchdog timer instead of from softirqs. More information
   on this feature can be found at [1].
 
+- **Secondary Processes**
+
+  Rx and Tx are not supported for secondary processes due to the 
single-producer
+  single-consumer nature of the AF_XDP rings. However other operations 
including
+  statistics retrieval are permitted.
+  The maximum number of queues permitted for PMDs operating in this model is 8
+  as this is the maximum number of fds that can be sent through the IPC APIs as
+  defined by RTE_MP_MAX_FD_NUM.
+
   [1] https://lwn.net/Articles/837010/
\ No newline at end of file
diff --git a/doc/guides/nics/features/af_xdp.ini 
b/doc/guides/nics/features/af_xdp.ini
index 54b738e616..8e7e075aaf 100644
--- a/doc/guides/nics/features/af_xdp.ini
+++ b/doc/guides/nics/features/af_xdp.ini
@@ -9,4 +9,5 @@ Power mgmt address monitor = Y
 MTU update   = Y
 Promiscuous mode = Y
 Stats per queue  = Y
+Multiprocess aware   = Y
 x86-64   = Y
diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa9..ec719e9738 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -55,6 +55,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Updated AF_XDP PMD.**
+
+  * Re-enabled secondary process support. RX/TX is not supported.
+
 
 Removed Items
 -
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c 
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 96c2c9d939..8608a4f379 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -81,6 +81,18 @@ RTE_LOG_REGISTER_DEFAULT(af_xdp_logtype, NOTICE);
 
 #define ETH_AF_XDP_ETH_OVERHEAD(RTE_ETHER_HDR_LEN + 
RTE_ETHER_CRC_LEN)
 
+#define ETH_AF_XDP_MP_KEY "afxdp_mp_send_fds"
+
+static int afxdp_dev_count;
+
+/* Message header to synchronize fds via IPC */
+struct ipc_hdr {
+   char port_name[RTE_DEV_NAME_MAX_LEN];
+   /* The file descriptors are in the dedicated part
+* of the Unix message to be translated by the kernel.
+*/
+};
+
 struct xsk_umem_info {
struct xsk_umem *umem;
struct rte_ring *buf_ring;
@@ -148,6 +160,10 @@ struct pmd_internals {
struct pkt_tx_queue *tx_queues;
 };
 
+struct pmd_process_private {
+   int rxq_xsk_fds[RTE_MAX_QUEUES_PER_PORT];
+};
+
 #define ETH_AF_XDP_IFACE_ARG   "iface"
 #define ETH_AF_XDP_START_QUEUE_ARG "start_queue"
 #define ETH_AF_XDP_QUEUE_COUNT_ARG "queue_count"
@@ -857,11 +873,12 @@ static int
 eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 {
struct pmd_internals *internals = dev->data->dev_private;
+   struct pmd_process_private *process_private = dev->process_private;
struct xdp_statistics xdp_stats;
struct pkt_rx_queue *rxq;
struct pkt_tx_queue *txq;
socklen_t optlen;
-   int i, ret;
+   int i, ret, fd;
 
for (i = 0; i < dev->data->nb_rx_queues; i++) {
optlen = sizeof(struct xdp_statistics);
@@ -877,8 +894,9 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*stats)
stats->ibytes += stats->q_ibytes[i];
stats->imissed += rxq->stats.rx_dropped;
stats->oerrors += txq->stats.tx_dropped;
-   ret = getsockopt(xsk_socket__fd(rxq->xsk), SOL_XDP,
-   XDP_STATISTICS, &xdp_stats, &optlen);
+   fd = process_private->rxq_xsk_fds[i];
+   ret = fd >= 0 ? getsockopt(fd, SOL_XDP, XDP_STATISTICS,
+  &xdp_stats, &optlen) : -1;
if (ret != 0) {
AF_XDP_LOG(ERR, "getsockopt() failed for 
XDP_STATISTICS.\n");
return -1;
@@ -945,8 +963,10 @@ eth_dev_close(struct rte_eth_dev *dev)
struct pkt_rx_queue *rxq;
int i;
 
-   if (rte_eal_process_type() != RTE_P

DPDK Release Status Meeting 2021-12-09

2021-12-10 Thread Mcnamara, John 
Release status meeting minutes 2021-12-09
=

Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens

Participants:
* ARM
* Canonical
* Intel
* Marvell
* Nvidia
* Red Hat


Release Dates
-

The following are the proposed dates for 22.03:

* 22.03 V1 2021-12-31
* 22.03 Merge  2022-02-11
* 22.03 Release2022-03-11

See also http://core.dpdk.org/roadmap/#dates



And some provisional dates for the subsequent releases:

* 22.07 V1 2022-05-06
* 22.07 Merge  2022-06-10
* 22.07 Release2022-07-15



* 22.11 V1 2022-09-09
* 22.11 Merge  2022-10-18
* 22.11 Release2022-11-18



Subtrees


* next-net
  * Some patches merged from mlx tree

* next-net-intel
  * Some patches merged to next-net


* next-net-mlx
  * Some patches merged to next-net

* next-net-brcm
  * No update

* next-net-mrvl
  - No update

* next-eventdev
  * No update

* next-virtio
  * Not many new series yet

* next-crypto
  * No update on tree
  * Some patches from Marvell and Intel QAT



* main

  * Low activity at the moment
  * Regression on vmxnet3 - under investigation
  * Will work on tooling prior to V1
  * There is a crash when using latest libabigail (stick to version 1.8)

LTS
---



* There is a proposal to make 19.11 LTS into a 3 year release. This depends on 
companies providing testing for the additional releases:

* 21.11.1 in progress
* 20.11.4 in progress
* 19.11.11 in progress



* Distros
  * v20.11 in Debian 11
  * v20.11 in Ubuntu 21.04




Defects
---

* Bugzilla links, 'Bugs',  added for hosted projects
  * https://www.dpdk.org/hosted-projects/


Opens
-

* None


DPDK Release Status Meetings


The DPDK Release Status Meeting is intended for DPDK Committers to discuss the 
status of the master tree and sub-trees, and for project managers to track 
progress or milestone dates.

The meeting occurs on every Thursday at 9:30 UTC. on https://meet.jit.si/DPDK

If you wish to attend just send an email to "John McNamara 
john.mcnam...@intel.com" for the invite.

Re: [PATCH 3/3] net/mlx5: fix missing adjustment MPRQ stride devargs

2021-12-10 Thread Ferruh Yigit 

On 12/9/2021 12:33 PM, Kevin Traynor wrote:

On 08/12/2021 15:40, Matan Azrad wrote:

Hi Ferruh

Thanks for the review.

Please see inside some clarifications.

From: Ferruh Yigit

On 12/8/2021 12:52 PM, Michael Baum wrote:


On 12/07/2021 3:41 PM, ferruh.yi...@intel.com wrote:


On 11/23/2021 6:38 PM, michae...@nvidia.com wrote:

From: Michael Baum

In Multy-Packet RQ creation, the user can choose the number of
strides


Multi-Packet ?


Yes, you're right. It should have been Multi-Packet, thank you for that.




and their size in bytes. The user updates it using specific devargs
for both of these parameters.
The above two parameters determine the size of the WQE which is
actually their product of multiplication.

If the user selects values that are not in the supported range, the
PMD changes them to default values. However, apart from the range
limitations for each parameter individually there is also a minimum
value on their multiplication. When the user selects values that
their multiplication are lower than minimum value, no adjustment is
made and the creation of the WQE fails.

This patch adds an adjustment in these cases as well. When the user

selects values whose multiplication is lower than the minimum, they
are replaced with the default values.

Fixes: ecb160456aed ("net/mlx5: add device parameter for MPRQ stride
size") Cc:sta...@dpdk.org



Again, not sure if we can backport this patch, this looks a behavior
change more than a fix.

Previously if the user provided values ends up being invalid, PMD
seems returning error.
With this patch, instead of returning error PMD prefers to use
default values and doesn't return error.


It isn't behavior change.
It existed before, except that it is concentrated into one function.



I am not sure if it is correct thing to ignore (adjust) user provided
values, but that can be up to the PMD as long as the behavior is

documented.


Adjustment is the likely thing to do because the range depends on the

device and the user does not necessarily know it.

This behavior is documented here
https://doc.dpdk.org/guides/nics/mlx5.html#run-time-configuration
(Run-time configuration -> Driver options -> mprq_log_stride_num/size)



It is documented that adjustments will be done if any specific argument is
not in the range of the device capability.

It is not clear what will happen if the calculated value from both variables are
not valid.


The driver should adjust it to a legal value.


If it is not documented before, and previously it was returning error, now
adjusting values to make it work looks like behavior change to me.


The driver should not return an error - the driver should adjust to a legal 
value in case of illegal values by the user.
It is documented in the devargs description.

Not behavior change but a bug fix; previously, the adjustment may return an 
error(which is a bug) or cause unexpected behavior in the HW(which is an old FW 
bug).
Now, no error, no unexpected behavior - bug should be fixed for any FW version.



I can understand both arguments. It is a behaviour change as the user will see 
a different behaviour for a given set of values.

However, each parameter is already validated and defaults are provided as 
backup. The combination not being checked could be seen a piece of missed 
validation for those values and a bug. In this case, given it is unlikely any 
user would be happy with the WQE creation failure, i think it is ok to backport 
the missing validation/adjustment.


This is more of a process question, than technical detail in the driver, so
@Luca, @Kevin, @Christian, can you please comment? I will follow your
suggestion.



Thanks for raising it Ferruh.




Proceeding with patch then, updated fixes tag for 2/3 in next-net.