Re: [PATCH] Revert "build: disable gcc 10 zero-length-bounds warning"

[Kevin Traynor]

On 11/10/2024 18:57, Stephen Hemminger wrote:
> The zero length array warning can be re-enabled.
> The zero length marker fields are now removed by
> commit 9e152e674c77 ("mbuf: remove marker fields")
> in DPDK 24.03.
> 
> This reverts commit cfacbcb5a23bc26cb913528c372adddabbb33ca1.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  config/meson.build | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 

Acked-by: Kevin Traynor 

Re: [PATCH 2/2] devtools: deduplicate function to mark fixes

[Kevin Traynor]

On 18/04/2023 15:07, Thomas Monjalon wrote:
> In the commit 8070d8fecb4e ("devtools: add fixes flag to commit listing")
> the function to mark a commit for "stable" was duplicated for "Fixes:" mark.
> 
> The code is a bit smaller by using a single function for both marks.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  devtools/git-log-fixes.sh | 22 ++
>  1 file changed, 6 insertions(+), 16 deletions(-)
> 
> diff --git a/devtools/git-log-fixes.sh b/devtools/git-log-fixes.sh
> index 4690dd4545..005e46f715 100755
> --- a/devtools/git-log-fixes.sh
> +++ b/devtools/git-log-fixes.sh
> @@ -84,31 +84,21 @@ origin_version () #  ...
>   done | sort -uV | head -n1
>  }
>  
> -# print a marker for stable tag presence
> -stable_tag () # 
> +# print a marker for pattern presence in the commit message
> +git_log_mark () #   
>  {
> - if git log --format='%b' -1 $1 | grep -qi '^Cc: *sta...@dpdk.org' ; then
> - echo 'S'
> + if git log --format='%b' -1 $1 | grep -qi "$2" ; then
> + echo "$3"
>   else
>   echo '-'
>   fi
>  }
>  
> -# print a marker for fixes tag presence
> -fixes_tag () # 
> -{
> -if git log --format='%b' -1 $1 | grep -qi '^Fixes: *' ; then
> -echo 'F'
> -else
> -echo '-'
> -fi
> -}
> -
>  git log --oneline --reverse $range |
>  while read id headline ; do
>   origins=$(origin_filter $id)
> - stable=$(stable_tag $id)
> - fixes=$(fixes_tag $id)
> + stable=$(git_log_mark $id '^Cc: *sta...@dpdk.org' 'S')
> + fixes=$(git_log_mark $id '^Fixes:' 'F')
>   [ "$stable" = "S" ] || [ "$fixes" = "F" ] || [ -n "$origins" ] || 
> continue
>   version=$(commit_version $id)
>   if [ -n "$origins" ] ; then

Acked-by: Kevin Traynor 

Re: [PATCH 1/2] devtools: fix check of multiple commits fixed at once

[Kevin Traynor]

On 18/04/2023 15:07, Thomas Monjalon wrote:
> When looking for fixes to backport,
> only the first origin commit hash (from "Fixes:") was checked.
> There is very little chance that the next commits being fixed
> have a wrong hash in the commit log of the fix,
> but it is fixed by checking them all before proceeding further.
> 
> Fixes: 752d8e097ec1 ("scripts: show fixes with release version of bug")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  devtools/git-log-fixes.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/devtools/git-log-fixes.sh b/devtools/git-log-fixes.sh
> index 8a4a8470c2..4690dd4545 100755
> --- a/devtools/git-log-fixes.sh
> +++ b/devtools/git-log-fixes.sh
> @@ -68,7 +68,7 @@ origin_version () #  ...
>  {
>   for origin in $* ; do
>   # check hash is valid
> - git rev-parse -q --verify $1 >&- || continue
> + git rev-parse -q --verify $origin >&- || continue
>   # get version of this bug origin
>   local origver=$(commit_version $origin)
>   local roothashes="$(origin_filter $origin)"

These still apply and working well.

Acked-by: Kevin Traynor 

Re: [PATCH 1/2] eal/linux: fix VFIO hotplug with multiprocess

[Kevin Traynor]

On 02/10/2024 14:31, David Marchand wrote:
> On Tue, Sep 17, 2024 at 10:20 AM Maxime Coquelin
>  wrote:
>> On 9/16/24 14:30, David Marchand wrote:
>>> At the moment, if VFIO is not available at DPDK init, it won't be
>>> available unless a subsequent rte_vfio_enable() is done.
>>>
>>> Yet, even if rte_vfio_enable() is called again in primary and secondary
>>> processes, a secondary process will never get to know that VFIO has been
>>> enabled in the primary process as the MP requests handler is only
>>> registered in EAL init.
>>>
>>> On the other hand, moving the MP requests handler registration earlier
>>> in EAL init is ok, as secondary process are supposed to be waiting on
>>> eal_mcfg_wait_complete() until the primary process calls
>>> eal_mcfg_complete().
>>>
>>> Move vfio_mp_sync_setup() in rte_vfio_enable().
>>>
>>> Besides, rte_eal_vfio_setup() is useless and its name with a rte_ prefix
>>> is ambiguous as it gives the impression it is an exported/public symbol.
>>> Remove it and directly call rte_vfio_enable() where needed.
>>>
>>> Signed-off-by: David Marchand 
>>> ---
>>>   lib/eal/linux/eal.c  | 18 +-
>>>   lib/eal/linux/eal_vfio.c |  9 ++---
>>>   2 files changed, 7 insertions(+), 20 deletions(-)
>>>
>>
>> Should it be considered as a fix, and so a candidate for stable?
>> Or do you think it is too risky to change the behaviour?
> 
> Cc: stable maintainers (fyi)
> 
> I don't think it is risky: existing applications which relied on multi
> process had no choice but to make sure VFIO was properly setup before
> DPDK init.
> Yet, a change in behavior impact is always hard to estimate.
> 
> (same comment for the second patch of the series)
> 
> 

They seem borderline fixes for usability. I think it's a good candidate
for 22.11/23.11.

For 21.11, it is the last release and the behaviour has been like that
for 3 years, so would probably skip that one.

DPDK 21.11.8 released

[Kevin Traynor]

 deletions(-)
Abdullah Ömer Yamaç (1):
  hash: fix RCU reclamation size

Anatoly Burakov (7):
  net/e1000/base: fix link power down
  fbarray: fix incorrect lookahead behavior
  fbarray: fix incorrect lookbehind behavior
  fbarray: fix lookahead ignore mask handling
  fbarray: fix lookbehind ignore mask handling
  fbarray: fix finding for unaligned length
  malloc: fix multi-process wait condition handling

Apeksha Gupta (2):
  bus/dpaa: fix memory leak in bus scan
  common/dpaax: fix node array overrun

Bing Zhao (3):
  net/mlx5: fix end condition of reading xstats
  net/mlx5: fix uplink port probing in bonding mode
  common/mlx5: remove unneeded field when modify RQ table

Bruce Richardson (3):
  ethdev: fix device init without socket-local memory
  dma/idxd: fix default for workqueue options
  dma/idxd: add verbose option to config script

Chaoyong He (1):
  app/testpmd: fix help string of BPF load command

Chengwen Feng (1):
  net/hns3: check Rx DMA address alignmnent

Chenming Chang (1):
  hash: fix return code description in Doxygen

Chinh Cao (1):
  net/ice/base: fix return type of bitmap hamming weight

Ciara Loftus (2):
  net/af_xdp: fix port ID in Rx mbuf
  net/af_xdp: count mbuf allocation failures

Ciara Power (1):
  test/crypto: fix vector global buffer overflow

Conor Fogarty (1):
  hash: check name when creating a hash

Dariusz Sosnowski (1):
  net/mlx5: fix MTU configuration

David Marchand (12):
  bus/pci: fix build with musl 1.2.4 / Alpine 3.19
  eal/unix: support ZSTD compression for firmware
  net/ice: fix check for outer UDP checksum offload
  app/testpmd: fix outer IP checksum offload
  net/i40e: fix outer UDP checksum offload for X710
  telemetry: lower log level on socket error
  vdpa/sfc: remove dead code
  eal/linux: lower log level on allocation attempt failure
  buildtools: fix build with clang 17 and ASan
  net/vmxnet3: fix init logs
  config: fix warning for cross build with meson >= 1.3.0
  net: fix outer UDP checksum in Intel prepare helper

Dengdui Huang (5):
  net/hns3: fix offload flag of IEEE 1588
  net/hns3: fix Rx timestamp flag
  net/hns3: fix double free for Rx/Tx queue
  net/hns3: fix variable overflow
  app/testpmd: handle IEEE1588 init failure

Ed Czeck (1):
  net/ark: fix index arithmetic

Edwin Brossette (1):
  net/ixgbe: do not create delayed interrupt handler twice

Eric Joyner (1):
  net/ice/base: fix GCS descriptor field offsets

Ferruh Yigit (1):
  app/testpmd: fix build on signed comparison

Gagandeep Singh (3):
  common/dpaax/caamflib: fix PDCP-SDAP watchdog error
  bus/dpaa: fix bus scan for DMA devices
  common/dpaax: fix IOVA table cleanup

Ganapati Kundapura (2):
  cryptodev: fix build without crypto callbacks
  cryptodev: validate crypto callbacks from next node

Gowrishankar Muthukrishnan (3):
  crypto/cnxk: fix minimal input normalization
  test/crypto: fix asymmetric capability test
  test/crypto: remove unused stats in setup

Gregory Etelson (1):
  net/mlx5: fix Arm build with GCC 9.1

Haifei Luo (1):
  net/mlx5: fix indexed pool with invalid index

Haoqian He (1):
  vhost: cleanup resubmit info before inflight setup

Hemant Agrawal (1):
  baseband/la12xx: forbid secondary process

Hernan Vargas (1):
  app/bbdev: fix interrupt tests

Jack Bond-Preston (1):
  crypto/openssl: optimize 3DES-CTR context init

Jacob Keller (1):
  net/ice/base: fix size when allocating children arrays

Jesse Brandeburg (1):
  net/ice/base: fix sign extension

Jiawei Wang (1):
  net/mlx5: fix hash Rx queue release in flow sample

Jiawen Wu (14):
  net/txgbe: fix tunnel packet parsing
  net/txgbe: fix flow filters in VT mode
  net/txgbe: fix Tx hang on queue disable
  net/txgbe: restrict configuration of VLAN strip offload
  net/txgbe: reconfigure more MAC Rx registers
  net/txgbe: fix VF promiscuous and allmulticast
  net/ngbe: keep PHY power down while device probing
  net/txgbe: fix hotplug remove
  net/ngbe: fix hotplug remove
  net/txgbe: fix MTU range
  net/ngbe: fix MTU range
  net/txgbe: fix memory leaks
  net/ngbe: fix memory leaks
  net/txgbe: fix Rx interrupt

Jie Hai (2):
  net/hns3: disable SCTP verification tag for RSS hash input
  net/hns3: fix uninitialized variable in FEC query

Joel Kavanagh (2):
  test/crypto: fix allocation comment
  doc: fix typo in l2fwd-crypto guide

Julien Meunier (1):
  net/fm10k: fix cleanup during init failure

Jun Yang (1):
  crypto/dpaa2_sec: fix event queue user context

Karen Kelly (1):
  doc: add baseline mode in l3fwd-power guide

Kevin Laatz (1):
  dma/idxd: add generic option for queue config

Kevin Traynor (6):
  doc: fix testpmd ring size command
  eal: fix logs for '

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 18/09/2024 08:50, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Thursday, September 5, 2024 3:38 PM
>> To: sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ; Ali
>> Alnubani ; David Christensen ;
>> Hemant Agrawal ; Ian Stokes
>> ; Jerin Jacob ; John McNamara
>> ; Ju-Hyoung Lee ; Kevin
>> Traynor ; Luca Boccassi ; Pei Zhang
>> ; Raslan Darawsheh ; NBU-
>> Contact-Thomas Monjalon (EXTERNAL) ;
>> yangh...@redhat.com
>> Subject: 21.11.8 patches review and test
>>
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.8.
>>
>> The planned date for the final release is 18th September.
>>
>> 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.8-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
>>
>> Thanks.
>>
>> Kevin
>>
>> ---
> 
> Hello,
> 
> We ran the following functional tests with Nvidia hardware on 21.11.8-rc1:
> - Basic functionality:
>   Send and receive multiple types of traffic.
> - testpmd xstats counter test.
> - testpmd timestamp test.
> - Changing/checking link status through testpmd.
> - rte_flow tests 
> (https://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads)
> - RSS tests.
> - VLAN filtering, stripping, and insertion tests.
> - Checksum and TSO tests.
> - ptype tests.
> - link_status_interrupt example application tests.
> - l3fwd-power example application tests.
> - Multi-process example applications tests.
> - Hardware LRO tests.
> - Buffer Split tests.
> - Tx scheduling tests.
> 
> Functional tests ran on:
> - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: 
> MLNX_OFED_LINUX-24.07-0.6.1.0 / Firmware: 22.42.1000
> - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-24.07-0.6.1.0 
> / Firmware: 28.42.1000
> - DPU: BlueField-2 / DOCA SW version: 2.8 / Firmware: 24.42.1000
> 
> Additionally, we ran build tests with multiple configurations on the 
> following OS/driver combinations (all passed):
> - Debian 12 with MLNX_OFED_LINUX-24.07-0.6.1.0.
> - Ubuntu 20.04.6 with MLNX_OFED_LINUX-24.07-0.6.1.0.
> - Ubuntu 20.04.6 with rdma-core master (dd9c687).
> - Ubuntu 20.04.6 with rdma-core v28.0.
> - Fedora 40 with rdma-core v48.0.
> - Fedora 42 (Rawhide) with rdma-core v51.0.
> - OpenSUSE Leap 15.6 with rdma-core v49.1.
> 
> We don't see new issues caused by the changes in this release.
> 

Thanks Ali for this and your help. I will add to the release notes,
Kevin.

> Thanks,
> Ali

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 17/09/2024 17:21, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Tuesday, September 17, 2024 7:14 PM
>> To: Ali Alnubani ; sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Hemant Agrawal ; Ian Stokes
>> ; Jerin Jacob ; John McNamara
>> ; Ju-Hyoung Lee ; Luca
>> Boccassi ; Pei Zhang ; Raslan
>> Darawsheh ; NBU-Contact-Thomas Monjalon (EXTERNAL)
>> ; yangh...@redhat.com
>> Subject: Re: 21.11.8 patches review and test
>>
>> On 11/09/2024 14:10, Ali Alnubani wrote:
>>>> -Original Message-
>>>> From: Kevin Traynor 
>>>> Sent: Wednesday, September 11, 2024 3:20 PM
>>>> To: Ali Alnubani ; sta...@dpdk.org
>>>> Cc: dev@dpdk.org; Abhishek Marathe ;
>>>> Hemant Agrawal ; Ian Stokes
>>>> ; Jerin Jacob ; John McNamara
>>>> ; Ju-Hyoung Lee ; Luca
>>>> Boccassi ; Pei Zhang ; Raslan
>>>> Darawsheh ; NBU-Contact-Thomas Monjalon
>>>> (EXTERNAL) ; yangh...@redhat.com
>>>> Subject: Re: 21.11.8 patches review and test
>>>>
>>>> On 10/09/2024 20:12, Ali Alnubani wrote:
>>>>>> -Original Message-
>>>>>> From: Kevin Traynor 
>>>>>> Sent: Friday, September 6, 2024 12:53 PM
>>>>>> To: Ali Alnubani ; sta...@dpdk.org
>>>>>> Cc: dev@dpdk.org; Abhishek Marathe
>>>> ;
>>>>>> David Christensen ; Hemant Agrawal
>>>>>> ; Ian Stokes ; Jerin
>>>> Jacob
>>>>>> ; John McNamara ; Ju-
>>>>>> Hyoung Lee ; Luca Boccassi ;
>>>> Pei
>>>>>> Zhang ; Raslan Darawsheh ;
>>>> NBU-
>>>>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>>>>> yangh...@redhat.com
>>>>>> Subject: Re: 21.11.8 patches review and test
>>>>>>
>>>>>> On 05/09/2024 15:02, Kevin Traynor wrote:
>>>>>>> On 05/09/2024 14:29, Ali Alnubani wrote:
>>>>>>>>> -Original Message-
>>>>>>>>> From: Kevin Traynor 
>>>>>>>>> Sent: Thursday, September 5, 2024 3:38 PM
>>>>>>>>> To: sta...@dpdk.org
>>>>>>>>> Cc: dev@dpdk.org; Abhishek Marathe
>>>> ;
>>>>>> Ali
>>>>>>>>> Alnubani ; David Christensen
>>>>>> ;
>>>>>>>>> Hemant Agrawal ; Ian Stokes
>>>>>>>>> ; Jerin Jacob ; John
>>>> McNamara
>>>>>>>>> ; Ju-Hyoung Lee ;
>>>>>> Kevin
>>>>>>>>> Traynor ; Luca Boccassi ;
>>>> Pei
>>>>>> Zhang
>>>>>>>>> ; Raslan Darawsheh ;
>>>> NBU-
>>>>>>>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>>>>>>>> yangh...@redhat.com
>>>>>>>>> Subject: 21.11.8 patches review and test
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Here is a list of patches targeted for stable release 21.11.8.
>>>>>>>>>
>>>>>>>>> The planned date for the final release is 18th September.
>>>>>>>>>
>>>>>>>>> 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.8-rc1
>>>>>>>>>
>>>>>>>>> These patches are located at branch 21.11 of dpdk-stable repo:
>>>>>>>>> https://dpdk.org/browse/dpdk-stable/
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Kevin
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>
>>>>>>>> Hi Kevin,
>>>>>>>>
>>>>>>>> I see this build failure in Debian 12 and Fedora 40:
>>>>>>>>
&

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 11/09/2024 14:10, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Wednesday, September 11, 2024 3:20 PM
>> To: Ali Alnubani ; sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Hemant Agrawal ; Ian Stokes
>> ; Jerin Jacob ; John McNamara
>> ; Ju-Hyoung Lee ; Luca
>> Boccassi ; Pei Zhang ; Raslan
>> Darawsheh ; NBU-Contact-Thomas Monjalon
>> (EXTERNAL) ; yangh...@redhat.com
>> Subject: Re: 21.11.8 patches review and test
>>
>> On 10/09/2024 20:12, Ali Alnubani wrote:
>>>> -Original Message-
>>>> From: Kevin Traynor 
>>>> Sent: Friday, September 6, 2024 12:53 PM
>>>> To: Ali Alnubani ; sta...@dpdk.org
>>>> Cc: dev@dpdk.org; Abhishek Marathe
>> ;
>>>> David Christensen ; Hemant Agrawal
>>>> ; Ian Stokes ; Jerin
>> Jacob
>>>> ; John McNamara ; Ju-
>>>> Hyoung Lee ; Luca Boccassi ;
>> Pei
>>>> Zhang ; Raslan Darawsheh ;
>> NBU-
>>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>>> yangh...@redhat.com
>>>> Subject: Re: 21.11.8 patches review and test
>>>>
>>>> On 05/09/2024 15:02, Kevin Traynor wrote:
>>>>> On 05/09/2024 14:29, Ali Alnubani wrote:
>>>>>>> -Original Message-----
>>>>>>> From: Kevin Traynor 
>>>>>>> Sent: Thursday, September 5, 2024 3:38 PM
>>>>>>> To: sta...@dpdk.org
>>>>>>> Cc: dev@dpdk.org; Abhishek Marathe
>> ;
>>>> Ali
>>>>>>> Alnubani ; David Christensen
>>>> ;
>>>>>>> Hemant Agrawal ; Ian Stokes
>>>>>>> ; Jerin Jacob ; John
>> McNamara
>>>>>>> ; Ju-Hyoung Lee ;
>>>> Kevin
>>>>>>> Traynor ; Luca Boccassi ;
>> Pei
>>>> Zhang
>>>>>>> ; Raslan Darawsheh ;
>> NBU-
>>>>>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>>>>>> yangh...@redhat.com
>>>>>>> Subject: 21.11.8 patches review and test
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Here is a list of patches targeted for stable release 21.11.8.
>>>>>>>
>>>>>>> The planned date for the final release is 18th September.
>>>>>>>
>>>>>>> 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.8-rc1
>>>>>>>
>>>>>>> These patches are located at branch 21.11 of dpdk-stable repo:
>>>>>>> https://dpdk.org/browse/dpdk-stable/
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Kevin
>>>>>>>
>>>>>>> ---
>>>>>>
>>>>>> Hi Kevin,
>>>>>>
>>>>>> I see this build failure in Debian 12 and Fedora 40:
>>>>>>
>>>>>> $ meson --werror --buildtype=debugoptimized build && ninja -C build
>>>>>> [..]
>>>>>> drivers/net/softnic/rte_eth_softnic_meter.c:916:25: error: 's' may be
>> used
>>>> uninitialized [-Werror=maybe-uninitialized]
>>>>>>
>>>>>> Will update with the rest of our functional testing later during the next
>> couple
>>>> of weeks.
>>>>>>
>>>>>> Regards,
>>>>>> Ali
>>>>>
>>>>> ok, thanks. I will check it out.
>>>> Hi Ali,
>>>>
>>>> It looks like a false positive, as the stats [0] are initialised in
>>>> mtr_stats_convert() before they are used. The code is unchanged since
>>>> the last release so probably it's compiler/distro change for this release.
>>>>
>>>> I've built with this meson command using latest gcc and clang on a F40
>>>> and not seeing this issue [1].
>>>>
>>>> Are you using same compiler versions ? Any other details needed to
>>>> 

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 10/09/2024 20:12, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Friday, September 6, 2024 12:53 PM
>> To: Ali Alnubani ; sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> David Christensen ; Hemant Agrawal
>> ; Ian Stokes ; Jerin Jacob
>> ; John McNamara ; Ju-
>> Hyoung Lee ; Luca Boccassi ; Pei
>> Zhang ; Raslan Darawsheh ; NBU-
>> Contact-Thomas Monjalon (EXTERNAL) ;
>> yangh...@redhat.com
>> Subject: Re: 21.11.8 patches review and test
>>
>> On 05/09/2024 15:02, Kevin Traynor wrote:
>>> On 05/09/2024 14:29, Ali Alnubani wrote:
>>>>> -Original Message-
>>>>> From: Kevin Traynor 
>>>>> Sent: Thursday, September 5, 2024 3:38 PM
>>>>> To: sta...@dpdk.org
>>>>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Ali
>>>>> Alnubani ; David Christensen
>> ;
>>>>> Hemant Agrawal ; Ian Stokes
>>>>> ; Jerin Jacob ; John McNamara
>>>>> ; Ju-Hyoung Lee ;
>> Kevin
>>>>> Traynor ; Luca Boccassi ; Pei
>> Zhang
>>>>> ; Raslan Darawsheh ; NBU-
>>>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>>>> yangh...@redhat.com
>>>>> Subject: 21.11.8 patches review and test
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Here is a list of patches targeted for stable release 21.11.8.
>>>>>
>>>>> The planned date for the final release is 18th September.
>>>>>
>>>>> 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.8-rc1
>>>>>
>>>>> These patches are located at branch 21.11 of dpdk-stable repo:
>>>>> https://dpdk.org/browse/dpdk-stable/
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Kevin
>>>>>
>>>>> ---
>>>>
>>>> Hi Kevin,
>>>>
>>>> I see this build failure in Debian 12 and Fedora 40:
>>>>
>>>> $ meson --werror --buildtype=debugoptimized build && ninja -C build
>>>> [..]
>>>> drivers/net/softnic/rte_eth_softnic_meter.c:916:25: error: 's' may be used
>> uninitialized [-Werror=maybe-uninitialized]
>>>>
>>>> Will update with the rest of our functional testing later during the next 
>>>> couple
>> of weeks.
>>>>
>>>> Regards,
>>>> Ali
>>>
>>> ok, thanks. I will check it out.
>> Hi Ali,
>>
>> It looks like a false positive, as the stats [0] are initialised in
>> mtr_stats_convert() before they are used. The code is unchanged since
>> the last release so probably it's compiler/distro change for this release.
>>
>> I've built with this meson command using latest gcc and clang on a F40
>> and not seeing this issue [1].
>>
>> Are you using same compiler versions ? Any other details needed to
>> reproduce ?
>>
>> thanks,
>> Kevin.
>>
>> [0]
>> https://git.dpdk.org/dpdk-
>> stable/tree/drivers/net/softnic/rte_eth_softnic_meter.c?h=21.11#n906
>>
>> [1]
>> $ clang --version
>> clang version 18.1.6 (Fedora 18.1.6-3.fc40)
>> $ gcc --version
>> gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1)
>>
>> commit 680818068d31764357075cde440232ce5ab8b786 (HEAD -> 21.11, tag:
>> v21.11.8-rc1, origin/21.11)
>> Author: Kevin Traynor 
>> Date:   Thu Sep 5 10:34:16 2024 +0100
>>
>> version: 21.11.8-rc1
>>
>> e.g.
>> $ meson --werror --buildtype=debugoptimized build-gcc
>> ...
>> $ ninja -C build-gcc
>> ninja: Entering directory `build-gcc'
>> [3071/3071] Linking target app/test/dpdk-test
>>
>>
>>
>>> Kevin.
> 
> Hi Kevin, apologies for the late response,
> 
> The build failure doesn't reproduce for me on some environments either.
> I tried to compare the log of 2 builds (one that reproduced, and one that 
> didn't), and the only difference I saw was related to AVX512 support.
> 
> Build passed on an AMD EPYC 7713 system (3rd Gen EPYC, no AVX512 support):
> [..]
> Fetching val

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 05/09/2024 15:02, Kevin Traynor wrote:
> On 05/09/2024 14:29, Ali Alnubani wrote:
>>> -Original Message-
>>> From: Kevin Traynor 
>>> Sent: Thursday, September 5, 2024 3:38 PM
>>> To: sta...@dpdk.org
>>> Cc: dev@dpdk.org; Abhishek Marathe ; Ali
>>> Alnubani ; David Christensen ;
>>> Hemant Agrawal ; Ian Stokes
>>> ; Jerin Jacob ; John McNamara
>>> ; Ju-Hyoung Lee ; Kevin
>>> Traynor ; Luca Boccassi ; Pei Zhang
>>> ; Raslan Darawsheh ; NBU-
>>> Contact-Thomas Monjalon (EXTERNAL) ;
>>> yangh...@redhat.com
>>> Subject: 21.11.8 patches review and test
>>>
>>> Hi all,
>>>
>>> Here is a list of patches targeted for stable release 21.11.8.
>>>
>>> The planned date for the final release is 18th September.
>>>
>>> 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.8-rc1
>>>
>>> These patches are located at branch 21.11 of dpdk-stable repo:
>>> https://dpdk.org/browse/dpdk-stable/
>>>
>>> Thanks.
>>>
>>> Kevin
>>>
>>> ---
>>
>> Hi Kevin,
>>
>> I see this build failure in Debian 12 and Fedora 40:
>>
>> $ meson --werror --buildtype=debugoptimized build && ninja -C build
>> [..]
>> drivers/net/softnic/rte_eth_softnic_meter.c:916:25: error: 's' may be used 
>> uninitialized [-Werror=maybe-uninitialized]
>>
>> Will update with the rest of our functional testing later during the next 
>> couple of weeks.
>>
>> Regards,
>> Ali
> 
> ok, thanks. I will check it out.
Hi Ali,

It looks like a false positive, as the stats [0] are initialised in
mtr_stats_convert() before they are used. The code is unchanged since
the last release so probably it's compiler/distro change for this release.

I've built with this meson command using latest gcc and clang on a F40
and not seeing this issue [1].

Are you using same compiler versions ? Any other details needed to
reproduce ?

thanks,
Kevin.

[0]
https://git.dpdk.org/dpdk-stable/tree/drivers/net/softnic/rte_eth_softnic_meter.c?h=21.11#n906

[1]
$ clang --version
clang version 18.1.6 (Fedora 18.1.6-3.fc40)
$ gcc --version
gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1)

commit 680818068d31764357075cde440232ce5ab8b786 (HEAD -> 21.11, tag:
v21.11.8-rc1, origin/21.11)
Author: Kevin Traynor 
Date:   Thu Sep 5 10:34:16 2024 +0100

version: 21.11.8-rc1

e.g.
$ meson --werror --buildtype=debugoptimized build-gcc
...
$ ninja -C build-gcc
ninja: Entering directory `build-gcc'
[3071/3071] Linking target app/test/dpdk-test



> Kevin.

Re: 21.11.8 patches review and test

[Kevin Traynor]

On 05/09/2024 14:29, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Thursday, September 5, 2024 3:38 PM
>> To: sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ; Ali
>> Alnubani ; David Christensen ;
>> Hemant Agrawal ; Ian Stokes
>> ; Jerin Jacob ; John McNamara
>> ; Ju-Hyoung Lee ; Kevin
>> Traynor ; Luca Boccassi ; Pei Zhang
>> ; Raslan Darawsheh ; NBU-
>> Contact-Thomas Monjalon (EXTERNAL) ;
>> yangh...@redhat.com
>> Subject: 21.11.8 patches review and test
>>
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.8.
>>
>> The planned date for the final release is 18th September.
>>
>> 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.8-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
>>
>> Thanks.
>>
>> Kevin
>>
>> ---
> 
> Hi Kevin,
> 
> I see this build failure in Debian 12 and Fedora 40:
> 
> $ meson --werror --buildtype=debugoptimized build && ninja -C build
> [..]
> drivers/net/softnic/rte_eth_softnic_meter.c:916:25: error: 's' may be used 
> uninitialized [-Werror=maybe-uninitialized]
> 
> Will update with the rest of our functional testing later during the next 
> couple of weeks.
> 
> Regards,
> Ali

ok, thanks. I will check it out.
Kevin.

Bug 1531

[Kevin Traynor]

Hello Jianwen,

In reference to https://bugs.dpdk.org/show_bug.cgi?id=1531#c3 reported
by Yopper, is there is a fix needed for dpdk main branch or LTS branches ?

Also, if you could register in bugzilla, then we could track txgbe
issues in one place, which makes it easier.

thanks,
Kevin.

21.11.8 patches review and test

[Kevin Traynor]

CTP verification tag for RSS hash input
  net/hns3: fix uninitialized variable in FEC query

Joel Kavanagh (2):
  test/crypto: fix allocation comment
  doc: fix typo in l2fwd-crypto guide

Julien Meunier (1):
  net/fm10k: fix cleanup during init failure

Jun Yang (1):
  crypto/dpaa2_sec: fix event queue user context

Karen Kelly (1):
  doc: add baseline mode in l3fwd-power guide

Kevin Laatz (1):
  dma/idxd: add generic option for queue config

Kevin Traynor (2):
  doc: fix testpmd ring size command
  eal: fix logs for '--lcores'

Konstantin Ananyev (2):
  bpf: fix MOV instruction evaluation
  bpf: fix load hangs with six IPv6 addresses

Long Wu (1):
  net/nfp: fix disabling 32-bit build

Luca Vizzarro (1):
  vhost: fix build with GCC 13

Maayan Kashani (1):
  app/testpmd: fix parsing for connection tracking item

Mateusz Pacuszka (1):
  net/ice/base: fix check for existing switch rule

Mattias Rönnblom (1):
  net/af_packet: align Rx/Tx structs to cache line

Michael Baum (1):
  ethdev: fix GENEVE option item conversion

Mingjin Ye (1):
  bus/vdev: fix device reinitialization

Nithin Dabilpuram (1):
  net/cnxk: fix outbound security with higher packet burst

Paul Greenwalt (1):
  net/ice/base: fix potential TLV length overflow

Piotr Pietruszewski (1):
  net/ixgbe/base: revert advertising for X550 2.5G/5G

Piotr Skajewski (1):
  net/ixgbe/base: fix 5G link speed reported on VF

Radoslaw Tyl (1):
  net/ixgbe/base: fix PHY ID for X550

Rahul Bhansali (1):
  net/cnxk: fix promiscuous state after MAC change

Rohit Raj (1):
  bus/dpaa: remove redundant file descriptor check

Satha Rao (1):
  net/virtio: fix MAC table update

Shai Brandes (3):
  net/ena: fix bad checksum handling
  net/ena: fix return value check
  net/ena: fix checksum handling

Sivaprasad Tummala (1):
  app/testpmd: fix lcore ID restriction

Stefan Wegrzyn (1):
  net/ice/base: fix pointer to variable outside scope

Stephen Hemminger (11):
  pcapng: add memcpy check
  net/virtio-user: add memcpy check
  net/tap: fix file descriptor check in isolated flow
  event/sw: fix warning from useless snprintf
  net/ixgbe: do not update link status in secondary process
  app/dumpcap: handle SIGTERM and SIGHUP
  app/pdump: handle SIGTERM and SIGHUP
  doc: remove reference to mbuf pkt field
  app/testpmd: cleanup cleanly from signal
  app/testpmd: fix early exit from signal
  app/testpmd: fix interactive mode on Windows

Sunil Kumar Kori (1):
  net/cnxk: fix RSS config

Tyler Retzlaff (3):
  eal/windows: install sched.h file
  latencystats: fix literal float suffix
  common/mlx5: fix unsigned/signed mismatch

Varun Sethi (1):
  common/dpaax/caamflib: fix PDCP AES-AES watchdog error

Venkat Kumar Ande (11):
  net/axgbe: fix MDIO access for non-zero ports and CL45 PHYs
  net/axgbe: reset link when link never comes back
  net/axgbe: fix fluctuations for 1G Bel Fuse SFP
  net/axgbe: update DMA coherency values
  net/axgbe: disable interrupts during device removal
  net/axgbe: fix SFP codes check for DAC cables
  net/axgbe: fix connection for SFP+ active cables
  net/axgbe: check only minimum speed for cables
  net/axgbe: fix Tx flow on 30H HW
  net/axgbe: delay AN timeout during KR training
  net/axgbe: fix linkup in PHY status

Vladimir Medvedkin (2):
  net/ice: fix memory leaks in raw pattern parsing
  net/ice: fix return value for raw pattern parsing

Waldemar Dworakowski (1):
  net/ice/base: fix board type definition

Wenwu Ma (2):
  dmadev: fix structure alignment
  dma/idxd: fix setup with Ubuntu 24.04

Yahui Cao (1):
  net/ice/base: fix masking when reading context

Yingming Mao (1):
  doc: fix mbuf flags

Zerun Fu (2):
  bus/pci: fix UIO resource mapping in secondary process
  bus/pci: fix FD in secondary process

Zhichao Zeng (2):
  telemetry: fix connection parameter parsing
  net/ice/base: fix temporary failures reading NVM

Re: [PATCH] meson: use built-in 'modules' helper for python dependencies

[Kevin Traynor]

On 24/06/2024 10:15, David Marchand wrote:
> On Sun, Jun 23, 2024 at 2:30 PM  wrote:
>>
>> From: Luca Boccassi 
>>
>> We now require Meson 0.53 or later, so we can use this feature introduced
>> in 0.51. This also fixes a build failure on SUSE Leap 15.6.
> 
> @Luca
> The patch lgtm, but could you develop on what was wrong with SUSE?
> 
> 
>> Cc: sta...@dpdk.org
> 
> @Kevin.
> Just a note, this patch is probably not relevant to 21.11 as the
> switch to meson 0.53.2 was done in 22.11.
> 
Ack. thanks for letting me know.

>>
>> Signed-off-by: Luca Boccassi 
> 
> 

[PATCH] eal: fix logs for '--lcores'

[Kevin Traynor]

The argument is '--lcores' but it is being logged as '--lcore'
in several places.

e.g.
$ dpdk-testpmd -l 8,10,12 --lcores 8,10,12
EAL: Option --lcore is ignored, because (-l) is set!

Fix the spelling in logs and tests.

Fixes: 117eaa70584b ("eal: add error check for core options")
Signed-off-by: Kevin Traynor 
---
 app/test/test_eal_flags.c   | 2 +-
 lib/eal/common/eal_common_options.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 6cb4b06757..71d8dba731 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -672,5 +672,5 @@ test_missing_c_flag(void)
launch_proc(argv28) == 0 || launch_proc(argv30) == 0) {
printf("Error - "
-  "process ran without error with invalid --lcore flag\n");
+  "process ran without error with invalid --lcores 
flag\n");
return -1;
}
diff --git a/lib/eal/common/eal_common_options.c 
b/lib/eal/common/eal_common_options.c
index e541f07939..f1a5e329a5 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -1688,5 +1688,5 @@ eal_parse_common_option(int opt, const char *optarg,
EAL_LOG(ERR, "Option -c is ignored, because (%s) is 
set!",
(core_parsed == LCORE_OPT_LST) ? "-l" :
-   (core_parsed == LCORE_OPT_MAP) ? "--lcore" :
+   (core_parsed == LCORE_OPT_MAP) ? "--lcores" :
"-c");
return -1;
@@ -1721,5 +1721,5 @@ eal_parse_common_option(int opt, const char *optarg,
EAL_LOG(ERR, "Option -l is ignored, because (%s) is 
set!",
(core_parsed == LCORE_OPT_MSK) ? "-c" :
-   (core_parsed == LCORE_OPT_MAP) ? "--lcore" :
+   (core_parsed == LCORE_OPT_MAP) ? "--lcores" :
"-l");
return -1;
@@ -1902,8 +1902,8 @@ eal_parse_common_option(int opt, const char *optarg,
 
if (core_parsed) {
-   EAL_LOG(ERR, "Option --lcore is ignored, because (%s) 
is set!",
+   EAL_LOG(ERR, "Option --lcores is ignored, because (%s) 
is set!",
(core_parsed == LCORE_OPT_LST) ? "-l" :
(core_parsed == LCORE_OPT_MSK) ? "-c" :
-   "--lcore");
+   "--lcores");
return -1;
}
-- 
2.45.0

Re: [PATCH v2] doc: update LTS maintenance to 3 years

[Kevin Traynor]

On 23/05/2024 10:15, Xueming Li wrote:
> LGTM
> 
> Acked-by: Xueming Li 
> ____
> From: Kevin Traynor 
> Sent: Thursday, May 23, 2024 5:12 PM
> To: Luca Boccassi ; Morten Brørup 
> 
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ; 
> dev@dpdk.org ; david.march...@redhat.com 
> ; christian.ehrha...@canonical.com 
> ; Xueming Li ; 
> ferruh.yi...@amd.com ; john.mcnam...@intel.com 
> ; techbo...@dpdk.org 
> Subject: Re: [PATCH v2] doc: update LTS maintenance to 3 years
> 
> Ping Xueming/Christian,
> 
> Any comment on this, can you ack if you think it's a good idea ?
> 
> On 28/03/2024 10:25, Kevin Traynor wrote:
>> On 28/03/2024 10:01, Luca Boccassi wrote:
>>> On Mon, 25 Mar 2024 at 10:02, Morten Brørup  
>>> wrote:
>>>>
>>>>> From: Thomas Monjalon [mailto:tho...@monjalon.net]
>>>>> Sent: Monday, 25 March 2024 00.14
>>>>>
>>>>> 17/01/2024 17:24, Kevin Traynor:
>>>>>> The existing official policy was to maintain LTS releases for 2 years.
>>>>>>
>>>>>> 19.11 and 20.11 LTS releases were maintained for 3 years and there was
>>>>>> not significant issues caused by code divergence from main etc.
>>>>>>
>>>>>> Update the policy to indicate 3 years maintenance for LTS releases, but
>>>>>> note that it depends on community support.
>>>>>>
>>>>>> Signed-off-by: Kevin Traynor 
>>>>>
>>>>> More opinions, comments or acks?
>>>>
>>>> It is an improvement.
>>>>
>>>> Acked-by: Morten Brørup 
>>>
>>> Acked-by: Luca Boccassi 
>>>
>>
>> Xueming/Christian - any comments on this ?
>>
>> If it sounds ok, can you Ack ?
>>
>> thanks,
>> Kevin.
>>
>>
>>
> 
> 

Summarizing the Acks on this patch...

This has Acks from reps from the companies involved with validating LTS
releases, Nvidia (Raslan), Intel (John), Red Hat (Kevin implicit) and
current LTS maintainers Luca, Xueming, Kevin.

It has also has an Ack from Morten and as it is a policy change, it was
approved by the techboard at the last meeting.

thanks,
Kevin.

Re: [PATCH v2] doc: update LTS maintenance to 3 years

[Kevin Traynor]

Ping Xueming/Christian,

Any comment on this, can you ack if you think it's a good idea ?

On 28/03/2024 10:25, Kevin Traynor wrote:
> On 28/03/2024 10:01, Luca Boccassi wrote:
>> On Mon, 25 Mar 2024 at 10:02, Morten Brørup  
>> wrote:
>>>
>>>> From: Thomas Monjalon [mailto:tho...@monjalon.net]
>>>> Sent: Monday, 25 March 2024 00.14
>>>>
>>>> 17/01/2024 17:24, Kevin Traynor:
>>>>> The existing official policy was to maintain LTS releases for 2 years.
>>>>>
>>>>> 19.11 and 20.11 LTS releases were maintained for 3 years and there was
>>>>> not significant issues caused by code divergence from main etc.
>>>>>
>>>>> Update the policy to indicate 3 years maintenance for LTS releases, but
>>>>> note that it depends on community support.
>>>>>
>>>>> Signed-off-by: Kevin Traynor 
>>>>
>>>> More opinions, comments or acks?
>>>
>>> It is an improvement.
>>>
>>> Acked-by: Morten Brørup 
>>
>> Acked-by: Luca Boccassi 
>>
> 
> Xueming/Christian - any comments on this ?
> 
> If it sounds ok, can you Ack ?
> 
> thanks,
> Kevin.
> 
> 
> 

[PATCH] doc: fix testpmd ring size command

[Kevin Traynor]

The documentation is missing the 'config' word.

In app, 'help ports' shows the correct syntax:

port config (port_id) (rxq|txq) (queue_id) ring_size (value)

Fixes: 1a77cffa8143 ("app/testpmd: enable queue ring size configure")
Cc: sta...@dpdk.org

Signed-off-by: Kevin Traynor 
---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 2fbf9220d8..ecd040504e 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2033,5 +2033,5 @@ port config - queue ring size
 Configure a rx/tx queue ring size::
 
-   testpmd> port (port_id) (rxq|txq) (queue_id) ring_size (value)
+   testpmd> port config (port_id) (rxq|txq) (queue_id) ring_size (value)
 
 Only take effect after command that (re-)start the port or command that setup 
specific queue.
-- 
2.44.0

DPDK 21.11.7 released

[Kevin Traynor]

 link to Windows DevX in mlx5 guide

Andrew Boyer (2):
  net/ionic: fix device close
  doc: fix typos in cryptodev overview

Bing Zhao (3):
  net/mlx5: fix counters map in bonding mode
  net/mlx5: fix age position in hairpin split
  net/mlx5: fix drop action release timing

Bruce Richardson (9):
  kernel/freebsd: fix module build on FreeBSD 14
  build: fix linker warnings about undefined symbols
  net/vmxnet3: fix initialization on FreeBSD
  eventdev: improve Doxygen comments on configure struct
  eventdev: fix Doxygen processing of vector struct
  net/i40e: remove incorrect 16B descriptor read block
  net/iavf: remove incorrect 16B descriptor read block
  net/ice: remove incorrect 16B descriptor read block
  test: do not count skipped tests as executed

Chaoyong He (1):
  net/nfp: fix resource leak for PF initialization

Chengwen Feng (13):
  eal: verify strdup return
  bus/dpaa: verify strdup return
  bus/fslmc: verify strdup return
  bus/vdev: verify strdup return
  dma/idxd: verify strdup return
  event/cnxk: verify strdup return
  net/failsafe: fix memory leak in args parsing
  app/dumpcap: verify strdup return
  app/pdump: verify strdup return
  app/crypto-perf: verify strdup return
  test: verify strdup return
  examples/qos_sched: fix memory leak in args parsing
  net/hns3: remove QinQ insert support for VF

Ciara Power (1):
  crypto/ipsec_mb: fix incorrectly setting cipher keys

Dariusz Sosnowski (1):
  net/mlx5: fix VLAN handling in meter split

David Marchand (7):
  hash: remove some dead code
  regexdev: fix logtype register
  ci: update versions of actions in GHA
  vhost: fix virtqueue access check in vhost-user setup
  test/event: skip test if no driver is present
  net/iavf: remove error logs for VLAN offloading
  app/testpmd: fix --stats-period option check

Dengdui Huang (8):
  net/hns3: refactor VF mailbox message struct
  net/hns3: refactor PF mailbox message struct
  net/hns3: fix VF multiple count on one reset
  net/hns3: fix disable command with firmware
  net/hns3: fix reset level comparison
  app/testpmd: fix crash in multi-process forwarding
  net/hns3: refactor send mailbox function
  net/hns3: refactor handle mailbox function

Edwin Brossette (2):
  net/virtio: remove duplicate queue xstats
  net/ixgbevf: fix RSS init for x550 NICs

Eli Britstein (1):
  net/mlx5: prevent ioctl failure log flooding

Emi Aoki (1):
  doc: fix typo in profiling guide

Ferruh Yigit (3):
  common/mlx5: fix calloc parameters
  net/bnx2x: fix calloc parameters
  net/nfp: fix calloc parameters

Fidel Castro (1):
  test/power: fix typo in error message

Flore Norceide (1):
  doc: fix typo in packet framework guide

Ganapati Kundapura (1):
  test/event: fix crash in Tx adapter freeing

Hao Chen (1):
  vhost: fix deadlock during vDPA SW live migration

Harman Kalra (1):
  common/cnxk: fix mbox region copy

Hernan Vargas (1):
  doc: fix configuration in baseband 5GNR driver guide

Holly Nichols (1):
  test/cfgfile: fix typo in error messages

Huisong Li (2):
  doc: add traffic manager in features table
  doc: add link speeds configuration in features table

Jie Hai (4):
  net/hns3: enable PFC for all user priorities
  net/hns3: support new device
  net/axgbe: fix Rx and Tx queue state
  net/nfp: fix Rx and Tx queue state

Jonathan Erb (1):
  telemetry: fix empty JSON dictionaries

Joyce Kong (1):
  config: fix CPU instruction set for cross-build

Kaiwen Deng (2):
  net/i40e: remove redundant judgment in flow parsing
  net/ice: fix tunnel TSO capabilities

Kalesh AP (4):
  net/bnxt: fix 50G and 100G forced speed
  net/bnxt: fix speed change from 200G to 25G on Thor
  net/bnxt: fix backward firmware compatibility
  net/bnxt: fix null pointer dereference

Kevin Traynor (3):
  net/ixgbe: increase VF reset timeout
  version: 21.11.7-rc1
  version: 21.11.7

Kiran Kumar K (1):
  net/cnxk: fix flow RSS configuration

Kishore Padmanabha (1):
  net/bnxt: fix number of Tx queues being created

Kommula Shiva Shankar (1):
  common/cnxk: fix RSS RETA configuration

Konstantin Ananyev (1):
  examples/l3fwd: fix Rx over not ready port

Masoumeh Farhadi Nia (1):
  examples/ipsec-secgw: fix typo in error message

Maxime Coquelin (1):
  vhost: fix memory leak in Virtio Tx split path

Michael Baum (3):
  net/mlx5: fix jump action validation
  net/mlx5: fix GENEVE TLV option management
  common/mlx5: fix duplicate read of general capabilities

Mingjin Ye (1):
  test: fix probing in secondary process

Morten Brørup (3):
  event/dlb2: remove superfluous memcpy
  net/bnx2x: fix warnings about memcpy lengths
  net/mlx5: fix warning about copy length

Nithin Dabilpuram (2):
  common

Re: 21.11.7 patches review and test

[Kevin Traynor]

On 29/04/2024 12:21, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Thursday, April 18, 2024 3:34 PM
>> To: sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Ali Alnubani ; David Christensen
>> ; Hemant Agrawal ;
>> Ian Stokes ; Jerin Jacob ; John
>> McNamara ; Ju-Hyoung Lee
>> ; Kevin Traynor ; Luca
>> Boccassi ; Pei Zhang ; Raslan
>> Darawsheh ; NBU-Contact-Thomas Monjalon
>> (EXTERNAL) ; yangh...@redhat.com
>> Subject: 21.11.7 patches review and test
>>
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.7.
>>
>> The planned date for the final release is 30th April.
>>
>> 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.7-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
>>
>> Thanks.
>>
>> Kevin
>>
>> ---
> 
> Hello,
> 
> We ran the following functional tests with Nvidia hardware on 21.11.7-rc1:
> - Basic functionality:
>   Send and receive multiple types of traffic.
> - testpmd xstats counter test.
> - testpmd timestamp test.
> - Changing/checking link status through testpmd.
> - rte_flow tests 
> (https://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads)
> - RSS tests.
> - VLAN filtering, stripping, and insertion tests.
> - Checksum and TSO tests.
> - ptype tests.
> - link_status_interrupt example application tests.
> - l3fwd-power example application tests.
> - Multi-process example applications tests.
> - Hardware LRO tests.
> - Buffer Split tests.
> - Tx scheduling tests.
> 
> Functional tests ran on:
> - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: 
> MLNX_OFED_LINUX-24.01-0.3.3.1 / Firmware: 22.40.1000
> - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-24.01-0.3.3.1 
> / Firmware: 28.40.1000
> - DPU: BlueField-2 / DOCA SW version: 2.6.0 / Firmware: 24.40.1000
> 
> Additionally, we ran build tests with multiple configurations on the 
> following OS/driver combinations (all passed):
> - Debian 12 with MLNX_OFED_LINUX-24.01-0.3.3.1.
> - Ubuntu 20.04.6 with MLNX_OFED_LINUX-24.01-0.3.3.1.
> - Ubuntu 20.04.6 with rdma-core master (3be5661).
> - Ubuntu 20.04.6 with rdma-core v28.0.
> - Fedora 38 with rdma-core v44.0.
> - Fedora 40 (Rawhide) with rdma-core v48.0.
> - OpenSUSE Leap 15.5 with rdma-core v42.0.
> - Windows Server 2019 with Clang 16.0.6.
> 
> We don't see new issues caused by the changes in this release.
> 

Thanks for testing Ali. I will add into the release notes.

Kevin.

> Thanks,
> Ali

Re: 21.11.7 patches review and test

[Kevin Traynor]

On 22/04/2024 09:38, YangHang Liu wrote:
> RedHat QE tested below 18 scenarios on RHEL 9.4 and didn't find any new
> dpdk issues.
> 
>-
>- VM with device assignment(PF) throughput testing(1G hugepage size):
>PASS
>- VM with device assignment(PF) throughput testing(2M hugepage size) :
>PASS
>- VM with device assignment(VF) throughput testing: PASS
>- PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
>- PVP vhost-user 2Q throughput testing: PASS
>- PVP vhost-user 1Q - cross numa node throughput testing: PASS
>- VM 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  reconnect with dpdk-client, qemu-server: PASS
>- PVP 1Q live migration testing: PASS
>- PVP 1Q cross numa node live migration testing: PASS
>- VM with ovs+dpdk+vhost-user 1Q live migration testing: PASS
>- VM with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
>- VM with ovs+dpdk+vhost-user 2Q live migration testing: PASS
>- VM with ovs+dpdk+vhost-user 4Q live migration testing: PASS
>- Host PF + DPDK testing: PASS
>- Host VF + DPDK testing: PASS
> 
> Test Versions:
> 
>- qemu-kvm-8.2.0
>- kernel 5.14
>- libvirt 10.0
>- git log
> 
>     Commit e9b8b369deed1d368079e2591fa8df4a4b9dc94a
>  Author: Kevin Traynor 
>  Date:   Thu Apr 18 13:19:53 2024 +0100
>   version: 21.11.7-rc1
>   Signed-off-by: Kevin Traynor <
> ktray...@redhat.com>
> 
>- Test device : X540-AT2 NIC(ixgbe, 10G)
> 
> Tested-by: Yanghang Liu
> 

Thanks YangHang. I will add your validation notes to the release notes,

Kevin.

> 
> On Thu, Apr 18, 2024 at 8:34 PM Kevin Traynor  wrote:
> 
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.7.
>>
>> The planned date for the final release is 30th April.
>>
>> 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.7-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
>>
>> Thanks.
>>
>> Kevin
>>
>> ---
>> Ajit Khaparde (2):
>>   net/bnxt: fix array overflow
>>   net/bnxt: modify locking for representor Tx
>>
>> Akhil Goyal (1):
>>   common/cnxk: fix memory leak in CPT init
>>
>> Akshay Dorwat (1):
>>   net/ionic: fix RSS query
>>
>> Alan Elder (2):
>>   net: add macros for VLAN metadata parsing
>>   net/netvsc: fix VLAN metadata parsing
>>
>> Ali Alnubani (1):
>>   doc: update link to Windows DevX in mlx5 guide
>>
>> Andrew Boyer (2):
>>   net/ionic: fix device close
>>   doc: fix typos in cryptodev overview
>>
>> Bing Zhao (3):
>>   net/mlx5: fix counters map in bonding mode
>>   net/mlx5: fix age position in hairpin split
>>   net/mlx5: fix drop action release timing
>>
>> Bruce Richardson (9):
>>   kernel/freebsd: fix module build on FreeBSD 14
>>   build: fix linker warnings about undefined symbols
>>   net/vmxnet3: fix initialization on FreeBSD
>>   eventdev: improve Doxygen comments on configure struct
>>   eventdev: fix Doxygen processing of vector struct
>>   net/i40e: remove incorrect 16B descriptor read block
>>   net/iavf: remove incorrect 16B descriptor read block
>>   net/ice: remove incorrect 16B descriptor read block
>>   test: do not count skipped tests as executed
>>
>> Chaoyong He (1):
>>   net/nfp: fix resource leak for PF initialization
>>
>> Chengwen Feng (13):
>>   eal: verify strdup return
>>   bus/dpaa: verify strdup return
>>   bus/fslmc: verify strdup return
>>   bus/vdev: verify strdup return
>>   dma/idxd: verify strdup return
>>   event/cnxk: verify strdup return
>>   net/failsafe: fix memory leak in args parsing
>>   app/dumpcap: verify strdup return
>>   app/pdump: verify strdup return
>>   app/crypto-perf: verify strdup return
>>   test: v

Re: 21.11.7 patches review and test

[Kevin Traynor]

On 26/04/2024 10:04, Xu, HailinX wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Thursday, April 18, 2024 8:34 PM
>> To: sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Ali Alnubani ; David Christensen
>> ; Hemant Agrawal ;
>> Stokes, Ian ; Jerin Jacob ;
>> Mcnamara, John ; Ju-Hyoung Lee
>> ; Kevin Traynor ; Luca
>> Boccassi ; Pei Zhang ; Raslan
>> Darawsheh ; Thomas Monjalon
>> ; yangh...@redhat.com
>> Subject: 21.11.7 patches review and test
>>
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 21.11.7.
>>
>> The planned date for the final release is 30th April.
>>
>> 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.7-rc1
>>
>> These patches are located at branch 21.11 of dpdk-stable repo:
>> https://dpdk.org/browse/dpdk-stable/
>>
>> Thanks.
>>
>> Kevin
> 
> Update the test status for Intel part. completed dpdk21.11.7-rc1 all 
> validation. No new issue is found.
> 
> # Basic Intel(R) NIC testing
> * Build & CFLAG compile: cover the build test combination with latest 
> GCC/Clang version and the popular OS revision such as
>   Ubuntu20.04, Ubuntu22.04, Fedora39, RHEL8.9, RHEL9.2, FreeBSD14.0, SUSE15, 
> CentOS7.9, OpenAnolis8.8 etc.
> - All test done. No new dpdk issue is found.
> * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum 
> offload/VLAN/VXLAN, etc. 
> - All test done. No new dpdk issue is found.
> * VF(i40e, ixgbe): test scenarios including 
> VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.  
> - All test done. No new dpdk issue is found.
> * PF/VF(ice): test scenarios including Switch features/Package 
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible 
> Descriptor, etc.
> - All test done. No new dpdk issue is found.
> * Intel NIC single core/NIC performance: test scenarios including PF/VF 
> single core performance test, etc.
> - All test done. No new dpdk issue is found.
> * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - 
> QAT&SW/FIB library, etc.
> - All test done. No new dpdk issue is found.
>   
> # 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 8.0, etc.
> - All test done. No new dpdk issue is found.
> * Cryptodev: 
>   *Function test: test scenarios including Cryptodev API testing/CompressDev 
> ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
> - All test done. No new dpdk issue is found.
>   *Performance test: test scenarios including Thoughput Performance/Cryptodev 
> Latency, etc.
> - All test done. No new dpdk issue is found.
> 
> Regards,
> Xu, Hailin


Thanks for the report Hailin. I will add to the release notes,

Kevin.

21.11.7 patches review and test

[Kevin Traynor]

Hi all,

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

The planned date for the final release is 30th April.

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.7-rc1

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

Thanks.

Kevin

---
Ajit Khaparde (2):
  net/bnxt: fix array overflow
  net/bnxt: modify locking for representor Tx

Akhil Goyal (1):
  common/cnxk: fix memory leak in CPT init

Akshay Dorwat (1):
  net/ionic: fix RSS query

Alan Elder (2):
  net: add macros for VLAN metadata parsing
  net/netvsc: fix VLAN metadata parsing

Ali Alnubani (1):
  doc: update link to Windows DevX in mlx5 guide

Andrew Boyer (2):
  net/ionic: fix device close
  doc: fix typos in cryptodev overview

Bing Zhao (3):
  net/mlx5: fix counters map in bonding mode
  net/mlx5: fix age position in hairpin split
  net/mlx5: fix drop action release timing

Bruce Richardson (9):
  kernel/freebsd: fix module build on FreeBSD 14
  build: fix linker warnings about undefined symbols
  net/vmxnet3: fix initialization on FreeBSD
  eventdev: improve Doxygen comments on configure struct
  eventdev: fix Doxygen processing of vector struct
  net/i40e: remove incorrect 16B descriptor read block
  net/iavf: remove incorrect 16B descriptor read block
  net/ice: remove incorrect 16B descriptor read block
  test: do not count skipped tests as executed

Chaoyong He (1):
  net/nfp: fix resource leak for PF initialization

Chengwen Feng (13):
  eal: verify strdup return
  bus/dpaa: verify strdup return
  bus/fslmc: verify strdup return
  bus/vdev: verify strdup return
  dma/idxd: verify strdup return
  event/cnxk: verify strdup return
  net/failsafe: fix memory leak in args parsing
  app/dumpcap: verify strdup return
  app/pdump: verify strdup return
  app/crypto-perf: verify strdup return
  test: verify strdup return
  examples/qos_sched: fix memory leak in args parsing
  net/hns3: remove QinQ insert support for VF

Ciara Power (1):
  crypto/ipsec_mb: fix incorrectly setting cipher keys

Dariusz Sosnowski (1):
  net/mlx5: fix VLAN handling in meter split

David Marchand (7):
  hash: remove some dead code
  regexdev: fix logtype register
  ci: update versions of actions in GHA
  vhost: fix virtqueue access check in vhost-user setup
  test/event: skip test if no driver is present
  net/iavf: remove error logs for VLAN offloading
  app/testpmd: fix --stats-period option check

Dengdui Huang (8):
  net/hns3: refactor VF mailbox message struct
  net/hns3: refactor PF mailbox message struct
  net/hns3: fix VF multiple count on one reset
  net/hns3: fix disable command with firmware
  net/hns3: fix reset level comparison
  app/testpmd: fix crash in multi-process forwarding
  net/hns3: refactor send mailbox function
  net/hns3: refactor handle mailbox function

Edwin Brossette (2):
  net/virtio: remove duplicate queue xstats
  net/ixgbevf: fix RSS init for x550 NICs

Eli Britstein (1):
  net/mlx5: prevent ioctl failure log flooding

Emi Aoki (1):
  doc: fix typo in profiling guide

Ferruh Yigit (3):
  common/mlx5: fix calloc parameters
  net/bnx2x: fix calloc parameters
  net/nfp: fix calloc parameters

Fidel Castro (1):
  test/power: fix typo in error message

Flore Norceide (1):
  doc: fix typo in packet framework guide

Ganapati Kundapura (1):
  test/event: fix crash in Tx adapter freeing

Hao Chen (1):
  vhost: fix deadlock during vDPA SW live migration

Harman Kalra (1):
  common/cnxk: fix mbox region copy

Hernan Vargas (1):
  doc: fix configuration in baseband 5GNR driver guide

Holly Nichols (1):
  test/cfgfile: fix typo in error messages

Huisong Li (2):
  doc: add traffic manager in features table
  doc: add link speeds configuration in features table

Jie Hai (4):
  net/hns3: enable PFC for all user priorities
  net/hns3: support new device
  net/axgbe: fix Rx and Tx queue state
  net/nfp: fix Rx and Tx queue state

Jonathan Erb (1):
  telemetry: fix empty JSON dictionaries

Joyce Kong (1):
  config: fix CPU instruction set for cross-build

Kaiwen Deng (2):
  net/i40e: remove redundant judgment in flow parsing
  net/ice: fix tunnel TSO capabilities

Kalesh AP (4):
  net/bnxt: fix 50G and 100G forced speed
  net/bnxt: fix speed change from 200G to 25G on Thor
  net/bnxt: fix backward firmware compatibility
  net/bnxt: fix null pointer dereference

Kevin Traynor (1):
  net/ixgbe: increase VF

Re: [PATCH v2] doc: update LTS maintenance to 3 years

[Kevin Traynor]

On 28/03/2024 10:01, Luca Boccassi wrote:
> On Mon, 25 Mar 2024 at 10:02, Morten Brørup  
> wrote:
>>
>>> From: Thomas Monjalon [mailto:tho...@monjalon.net]
>>> Sent: Monday, 25 March 2024 00.14
>>>
>>> 17/01/2024 17:24, Kevin Traynor:
>>>> The existing official policy was to maintain LTS releases for 2 years.
>>>>
>>>> 19.11 and 20.11 LTS releases were maintained for 3 years and there was
>>>> not significant issues caused by code divergence from main etc.
>>>>
>>>> Update the policy to indicate 3 years maintenance for LTS releases, but
>>>> note that it depends on community support.
>>>>
>>>> Signed-off-by: Kevin Traynor 
>>>
>>> More opinions, comments or acks?
>>
>> It is an improvement.
>>
>> Acked-by: Morten Brørup 
> 
> Acked-by: Luca Boccassi 
> 

Xueming/Christian - any comments on this ?

If it sounds ok, can you Ack ?

thanks,
Kevin.

Re: Deprecated packet modification flow actions

[Kevin Traynor]

On 15/03/2024 09:24, Dariusz Sosnowski wrote:
>> NFP plans support RTE_FLOW_ACTION_TYPE_MODIFY_FIELD flow action in
>> 24.07 or 24.11.
>> For remove of legacy flow, does there also correspond patches in OVS project?
> I am not familiar with any patches to OVS. Thanks for raising this.
> 
> For the record, in latest commit on main branch in OVS (commit fa0dfa18d534) 
> I see that the following modify actions are used:
> 
> RTE_FLOW_ACTION_TYPE_SET_MAC_SRC
> RTE_FLOW_ACTION_TYPE_SET_MAC_DST
> RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC
> RTE_FLOW_ACTION_TYPE_SET_IPV4_DST
> RTE_FLOW_ACTION_TYPE_SET_TTL
> RTE_FLOW_ACTION_TYPE_SET_TP_SRC
> RTE_FLOW_ACTION_TYPE_SET_TP_DST
> RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC
> RTE_FLOW_ACTION_TYPE_SET_IPV6_DST
> 
> We'd need to sync with OVS developers, but I assume we cannot just remove 
> these without providing a proper replacement, so the functionality is not 
> broken.

Yes, but I'd add that this is a general point about the API, regardless
of OVS or other projects.


> I think that, once there's an agreement on the timeline of implementing 
> MODIFY_FIELD in PMDs, we'd need to work
> with OVS to migrate it to MODIFY_FIELD. After OVS uses MODIFY_FIELD actions, 
> deprecated actions could be safely removed from OVS and DPDK.
> 

Ideally, there would be some overlap where both methods are present and
fully supported for a couple of releases. That would ease integration
for users, rather than having an abrupt switchover date.

OVS only takes DPDK LTS versions, so it could only take the next YY.11
release with this change.

Any OVS patches to switchover would need to be ready/reviewed in OVS
before the DPDK YY.11 release integration, otherwise it could delay
updating DPDK version and missing other new functionality/new drivers etc.

There is an OVS 'dpdk-latest' experimental branch that is paired with
head of DPDK main branch. You can send OVS patches to it for new DPDK
changes to refine and test with, in advance of a DPDK YY.11 release.

> What do you all think?
> > Also, this opens a question about other upstream projects using
deprecated actions. Do you know if there are other projects besides OVS?
> 

A quick search through some projects and I didn't see them used elsewhere.

thanks,
Kevin.

> Best regards,
> Dariusz Sosnowski
> 

Re: [PATCH stable-22.11] kni: fix build with Linux 6.8

[Kevin Traynor]

On 12/03/2024 10:40, Jiri Slaby wrote:
> On 12. 03. 24, 11:26, Kevin Traynor wrote:
>> On 12/03/2024 08:59, David Marchand wrote:
>>> Hello Jiri,
>>>
>>> On Tue, Mar 12, 2024 at 9:57 AM Jiri Slaby  wrote:
>>>>
>>>> strlcpy() was removed in commit d26270061ae6 (string: Remove strlcpy()), 
>>>> use
>>>> strscpy() instead.
>>>>
>>>> The patches fixes this:
>>>> kernel/linux/kni/kni_net.c: In function ‘kni_get_drvinfo’:
>>>> kernel/linux/kni/kni_net.c:835:9: error: implicit declaration of function 
>>>> ‘strlcpy’; did you mean ‘strscpy’?
>>>>
>>>> Intended esp. for stable/22.11. It should go wherever kni is still in
>>>> the tree.
>>>
>>> Thanks for the patch.
>>>
>>> Cc: stable and LTS maintainers.
>>>
>>>>
>>>> Signed-off-by: Jiri Slaby 
>>>
>>>
>>
>> Thanks Jiri and David. I will take this for 21.11 LTS also.
> 
> Just heads up: I've just realized, that strscpy() was introduces only in
> 
> commit 30035e45753b708e7d47a98398500ca005e02b86
> Author: Chris Metcalf 
> Date:   Wed Apr 29 12:52:04 2015 -0400
> 
>  string: provide strscpy()
> 
> in v4.3. If you support older kernels, the patch needs modifications. 
> Like some #if's depending on the kernel version or some HAVE_STRSCPY 
> defines.
> 
> thanks,

ok, thanks for letting us know. We should be fine for supported kernels
from kernel.org but it will probably an issue for Centos7 with older
DPDK LTS, though it is EoL very shortly.

Re: [PATCH stable-22.11] kni: fix build with Linux 6.8

[Kevin Traynor]

On 12/03/2024 08:59, David Marchand wrote:
> Hello Jiri,
> 
> On Tue, Mar 12, 2024 at 9:57 AM Jiri Slaby  wrote:
>>
>> strlcpy() was removed in commit d26270061ae6 (string: Remove strlcpy()), use
>> strscpy() instead.
>>
>> The patches fixes this:
>> kernel/linux/kni/kni_net.c: In function ‘kni_get_drvinfo’:
>> kernel/linux/kni/kni_net.c:835:9: error: implicit declaration of function 
>> ‘strlcpy’; did you mean ‘strscpy’?
>>
>> Intended esp. for stable/22.11. It should go wherever kni is still in
>> the tree.
> 
> Thanks for the patch.
> 
> Cc: stable and LTS maintainers.
> 
>>
>> Signed-off-by: Jiri Slaby 
> 
> 

Thanks Jiri and David. I will take this for 21.11 LTS also.

Re: [PATCH] vhost: fix virtqueue access lock check for handlers

[Kevin Traynor]

On 07/03/2024 10:36, David Marchand wrote:
> As the vhost library may receive a request for an unsupported request,
> it is necessary to check msg_handler before checking if locking queue
> pairs is requested.
> 
> Coverity issue: 415049
> Fixes: 5e8fcc60b59d ("vhost: enhance virtqueue access lock asserts")
> 
> Signed-off-by: David Marchand 
> ---
>  lib/vhost/vhost_user.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> index 7fe1687f08..414192500e 100644
> --- a/lib/vhost/vhost_user.c
> +++ b/lib/vhost/vhost_user.c
> @@ -3171,7 +3171,7 @@ vhost_user_msg_handler(int vid, int fd)
>* inactive, so it is safe. Otherwise taking the access_lock
>* would cause a dead lock.
>*/
> - if (msg_handler->lock_all_qps) {
> + if (msg_handler != NULL && msg_handler->lock_all_qps) {
>   if (!(dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)) {
>       vhost_user_lock_all_queue_pairs(dev);
>   unlock_required = 1;

Acked-by: Kevin Traynor 

Re: [PATCH] examples/l3fwd: fix conf propagation to RX queues

[Kevin Traynor]

On 16/02/2024 12:02, Kamil Vojanec wrote:
> When configuring RX queues, the default port configuration was used,
> even though it was modified before. This results in the
> 'relax-rx-offload' not being respected for RX queues.
> This commit uses 'rte_eth_dev_conf_get()' to obtain the device
> configuration structure instead.
> 
> Fixes: 4b01cabfb0 ("examples/l3fwd: add option to relax Rx offload")
> Signed-off-by: Kamil Vojanec 
> ---
>  examples/l3fwd/main.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index 3bf28aec0c..2b714a362a 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -1388,6 +1388,7 @@ l3fwd_poll_resource_setup(void)
>   fflush(stdout);
>   /* init RX queues */
>   for(queue = 0; queue < qconf->n_rx_queue; ++queue) {
> + struct rte_eth_conf local_conf;
>   struct rte_eth_rxconf rxq_conf;
>  
>   portid = qconf->rx_queue_list[queue].port_id;
> @@ -1408,8 +1409,14 @@ l3fwd_poll_resource_setup(void)
>   "Error during getting device (port %u) 
> info: %s\n",
>   portid, strerror(-ret));
>  
> + ret = rte_eth_dev_conf_get(portid, &local_conf);
> + if (ret != 0)
> + rte_exit(EXIT_FAILURE,
> + "Error during getting device (port %u) 
> configuration: %s\n",
> + portid, strerror(-ret));
> +
>   rxq_conf = dev_info.default_rxconf;
> - rxq_conf.offloads = port_conf.rxmode.offloads;
> + rxq_conf.offloads = local_conf.rxmode.offloads;
>       if (!per_port_pool)
>   ret = rte_eth_rx_queue_setup(portid, queueid,
>   nb_rxd, socketid,

Acked-by: Kevin Traynor 

Re: [PATCH] net/ixgbe: increase vf reset timeout

[Kevin Traynor]

Hi Bruce,

I see you are the lucky delegate for this patch :-)

https://patchwork.dpdk.org/project/dpdk/patch/20240130100027.39466-1-ktray...@redhat.com/

Just wondering if any comment and if it's planned for 23.03 or later
release ?

thanks,
Kevin.

On 30/01/2024 10:00, Kevin Traynor wrote:
> When vf issues a reset to pf there is a 50 msec wait plus an additional
> max of 1 msec for the pf to indicate the reset is complete before
> timeout.
> 
> In some cases, it is seen that the reset is timing out, in which case
> the reset does not complete and an error is returned.
> 
> In order to account for this, continue to wait an initial 50 msecs,
> but then allow a max of an additional 50 msecs for the command to
> complete.
> 
> Fixes: af75078fece3 ("first public release")
> 
> Signed-off-by: Kevin Traynor 
> ---
>  drivers/net/ixgbe/base/ixgbe_type.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ixgbe/base/ixgbe_type.h 
> b/drivers/net/ixgbe/base/ixgbe_type.h
> index 1094df5891..35212a561b 100644
> --- a/drivers/net/ixgbe/base/ixgbe_type.h
> +++ b/drivers/net/ixgbe/base/ixgbe_type.h
> @@ -1801,5 +1801,5 @@ enum {
>  #define IXGBE_VFRE_ENABLE_ALL0x
>  
> -#define IXGBE_VF_INIT_TIMEOUT200 /* Number of retries to clear RSTI 
> */
> +#define IXGBE_VF_INIT_TIMEOUT1 /* Number of retries to clear 
> RSTI */
>  
>  /* RDHMPN and TDHMPN bitmasks */

Re: [PATCH] ethdev: recommend against using locks in event callbacks

[Kevin Traynor]

On 01/02/2024 08:43, David Marchand wrote:
> As described in a recent bugzilla opened against the net/iavf driver,
> a driver may call a event callback from other calls of the ethdev API.
> 
> Nothing guarantees in the ethdev API against such behavior.
> 
> Add a notice against using locks in those callbacks.
> 
> Bugzilla ID: 1337
> 
> Signed-off-by: David Marchand 
> ---
>  lib/ethdev/rte_ethdev.h | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 21e3a21903..5c6b104fb4 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
>   RTE_ETH_EVENT_MAX   /**< max value of this enum */
>  };
>  
> -/** User application callback to be registered for interrupts. */
> +/**
> + * User application callback to be registered for interrupts.
> + *
> + * Note: there is no guarantee in the DPDK drivers that a callback won't be
> + *   called in the middle of other parts of the ethdev API. For example,
> + *   imagine that thread A calls rte_eth_dev_start() and as part of this
> + *   call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
> + *   associated callback is ran on thread A. In that example, if the
> + *   application protects its internal data using locks before calling
> + *   rte_eth_dev_start(), and the callback takes a same lock, a deadlock
> + *   occurs. Because of this, it is highly recommended NOT to take locks 
> in
> + *   those callbacks.
> + */
>  typedef int (*rte_eth_dev_cb_fn)(uint16_t port_id,
>   enum rte_eth_event_type event, void *cb_arg, void *ret_param);
>  

Acked-by: Kevin Traynor 

Re: [PATCH] ethdev: recommend against using locks in event callbacks

[Kevin Traynor]

On 06/02/2024 20:33, Ferruh Yigit wrote:
> On 2/1/2024 10:08 AM, Kevin Traynor wrote:
>> On 01/02/2024 08:43, David Marchand wrote:
>>> As described in a recent bugzilla opened against the net/iavf driver,
>>> a driver may call a event callback from other calls of the ethdev API.
>>>
>>> Nothing guarantees in the ethdev API against such behavior.
>>>
>>> Add a notice against using locks in those callbacks.
>>>
>>> Bugzilla ID: 1337
>>>
>>> Signed-off-by: David Marchand 
>>> ---
>>>  lib/ethdev/rte_ethdev.h | 14 +-
>>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
>>> index 21e3a21903..5c6b104fb4 100644
>>> --- a/lib/ethdev/rte_ethdev.h
>>> +++ b/lib/ethdev/rte_ethdev.h
>>> @@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
>>> RTE_ETH_EVENT_MAX   /**< max value of this enum */
>>>  };
>>>  
>>> -/** User application callback to be registered for interrupts. */
>>> +/**
>>> + * User application callback to be registered for interrupts.
>>> + *
>>> + * Note: there is no guarantee in the DPDK drivers that a callback won't be
>>> + *   called in the middle of other parts of the ethdev API. For 
>>> example,
>>> + *   imagine that thread A calls rte_eth_dev_start() and as part of 
>>> this
>>> + *   call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
>>> + *   associated callback is ran on thread A. In that example, if the
>>> + *   application protects its internal data using locks before calling
>>> + *   rte_eth_dev_start(), and the callback takes a same lock, a 
>>> deadlock
>>> + *   occurs. Because of this, it is highly recommended NOT to take 
>>> locks in
>>> + *   those callbacks.
>>> + */
>>
>> That is a good practical recommendation for an application developer.
>>
>> I wonder if it should taken further so that the API formally states the
>> callback MUST be non-blocking?
>>
> 
> Application still can manage the locks in a safe way, but needs to be
> aware of above condition and possible deadlock.
> 

Just to explain a bit more, if you look at the original issue in the
Bugzilla [0], I think there was an assumption that
rte_eth_dev_configure() would not block or deadlock with the
eal-intr-thread. So then it was assumed that waiting for the lock in the
callback was ok, because rte_eth_dev_configure() would return and
callback would obtain the lock.

So i'm showing that in this example the lack of a guarantee or clarity
or bad assumption about the behavior of rte_eth_dev_configure() made it
difficult for an app developer to know if their locks were safe or not.
That's why I was thinking about something more formal.

> I think above note is sufficient instead of forbidding locks in
> callbacks completely.
> 

In the end the difference between "highly recommended NOT to" and "must
not" is not much and either way is probably enough to scare someone
enough to avoid them.

[0] https://bugs.dpdk.org/show_bug.cgi?id=1337#c0

Re: [PATCH] ethdev: recommend against using locks in event callbacks

[Kevin Traynor]

On 01/02/2024 08:43, David Marchand wrote:
> As described in a recent bugzilla opened against the net/iavf driver,
> a driver may call a event callback from other calls of the ethdev API.
> 
> Nothing guarantees in the ethdev API against such behavior.
> 
> Add a notice against using locks in those callbacks.
> 
> Bugzilla ID: 1337
> 
> Signed-off-by: David Marchand 
> ---
>  lib/ethdev/rte_ethdev.h | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 21e3a21903..5c6b104fb4 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
>   RTE_ETH_EVENT_MAX   /**< max value of this enum */
>  };
>  
> -/** User application callback to be registered for interrupts. */
> +/**
> + * User application callback to be registered for interrupts.
> + *
> + * Note: there is no guarantee in the DPDK drivers that a callback won't be
> + *   called in the middle of other parts of the ethdev API. For example,
> + *   imagine that thread A calls rte_eth_dev_start() and as part of this
> + *   call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
> + *   associated callback is ran on thread A. In that example, if the
> + *   application protects its internal data using locks before calling
> + *   rte_eth_dev_start(), and the callback takes a same lock, a deadlock
> + *   occurs. Because of this, it is highly recommended NOT to take locks 
> in
> + *   those callbacks.
> + */

That is a good practical recommendation for an application developer.

I wonder if it should taken further so that the API formally states the
callback MUST be non-blocking?

>  typedef int (*rte_eth_dev_cb_fn)(uint16_t port_id,
>   enum rte_eth_event_type event, void *cb_arg, void *ret_param);
>  

Re: [PATCH 4/4] net/nfp: fix stop cpp service problem

[Kevin Traynor]

On 30/01/2024 12:07, Ferruh Yigit wrote:
> On 1/24/2024 9:25 AM, Chaoyong He wrote:
>> From: Long Wu 
>>
>> Stop cpp service if all representors are closed and cpp service is running.
>>
>> Fixes: bab0e6f48b6d ("net/nfp: fix infinite loop")
>> Cc: chaoyong...@corigine.com
>> Cc: sta...@dpdk.org
>>
> 
> This fix is using a new function that is introduced in previous patches
> in this set, so this fix can't be backported.
> 
> Can you please change the order of the patches in this set, make this
> patch first patch in the set and update it to use old version of
> functions, so it can be backported?
> Later you can update old function with new one in the patch that
> introduces the new functions.
> 

Agree, it makes sense to put fixes at the start of the series to make
the backport easier. If it's not possible for some reason, then you can
also send a rebased revision of the fix to the stable mailing list with
the correct prefix
(http://doc.dpdk.org/guides/contributing/patches.html#backporting-patches-for-stable-releases)

> 
> Also instead of saying "cpp service problem" in the title, can you
> please describe the problem, I guess the problem you are referring is
> something like, "CPP service is consuming resources even there is no
> device remaining that requires it" ? Or is it something else?
> 

+1

>> Signed-off-by: Long Wu 
>> Reviewed-by: Chaoyong He 
>> Reviewed-by: Peng Zhang 
>> ---
>>  drivers/net/nfp/flower/nfp_flower_representor.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/net/nfp/flower/nfp_flower_representor.c 
>> b/drivers/net/nfp/flower/nfp_flower_representor.c
>> index bf67dc3ba2..2e8eb13e4e 100644
>> --- a/drivers/net/nfp/flower/nfp_flower_representor.c
>> +++ b/drivers/net/nfp/flower/nfp_flower_representor.c
>> @@ -400,6 +400,9 @@ nfp_flower_repr_dev_close(struct rte_eth_dev *dev)
>>  /* Stop flower service first */
>>  nfp_flower_service_stop(app_fw_flower);
>>  
>> +/* Disable cpp service if need */
>> +nfp_service_disable(&pf_dev->cpp_service_info);
>> +
>>  /* Now it is safe to free all PF resources */
>>  nfp_uninit_app_fw_flower(pf_dev);
>>  nfp_pf_uninit(pf_dev);
> 

[PATCH] net/ixgbe: increase vf reset timeout

[Kevin Traynor]

When vf issues a reset to pf there is a 50 msec wait plus an additional
max of 1 msec for the pf to indicate the reset is complete before
timeout.

In some cases, it is seen that the reset is timing out, in which case
the reset does not complete and an error is returned.

In order to account for this, continue to wait an initial 50 msecs,
but then allow a max of an additional 50 msecs for the command to
complete.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Kevin Traynor 
---
 drivers/net/ixgbe/base/ixgbe_type.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/base/ixgbe_type.h 
b/drivers/net/ixgbe/base/ixgbe_type.h
index 1094df5891..35212a561b 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -1801,5 +1801,5 @@ enum {
 #define IXGBE_VFRE_ENABLE_ALL  0x
 
-#define IXGBE_VF_INIT_TIMEOUT  200 /* Number of retries to clear RSTI */
+#define IXGBE_VF_INIT_TIMEOUT  1 /* Number of retries to clear RSTI */
 
 /* RDHMPN and TDHMPN bitmasks */
-- 
2.43.0

Minutes of Technical Board meeting 24-January-2024

[Kevin Traynor]

Members Attending
-
Aaron Conole
Bruce Richardson
Hemant Agrawal
Honappa Nagarahalli
Jerin Jacob
Kevin Traynor (Chair)
Konstantin Ananyev
Maxime Coquelin
Morten Brorup
Stephen Hemminger
Thomas Monjalon

NOTE: The technical board meetings are on every second Wednesday at 3 pm
UTC.
Meetings are public, and DPDK community members are welcome to attend.
Agenda and minutes can be found at http://core.dpdk.org/techboard/minutes

Next meeting will be on Wednesday 2024-Feb-07 @ 3pm UTC, and will
be chaired by Konstantin.

Agenda Items


Arg parsing (Bruce)
---
- 3 series proposed as per last TB minutes
http://inbox.dpdk.org/dev/dbapr08mb581405e7cf23732b8941b10c98...@dbapr08mb5814.eurprd08.prod.outlook.com
- Discussion about these series and if merging it contradicts with
longer term function based initialization
- There is still a need to handle arguments for the foreseeable future
- Consensus for adding helpers to argparse lib that eal will depend on
- Drivers may use an extension of argparse library in time
- Call for patch reviews

3 year LTS maintenance? [Kevin]
---
- Current documented policy is for 2 years
- 19.11/20.11 LTS were maintained for 3 year and it went smoothly
- Proposal is to formally document 3 year LTS maintenance
- http://inbox.dpdk.org/dev/20240117162419.223820-1-ktray...@redhat.com
- Needs ack from LTS maintainers and companies involved in validation


Application logging [Thomas]

- Should applications use rte_logs or printf ?
- rte_log is useful because it can be enabled/disabled
- interactive items like testpmd stats are better suited to printf
- driver specific directories should use rte_log

gov/tech board meeting items [All]
--
- Thomas is starting investigation about DPDK with AI
- Discussed possibility of cloud companies publishing DPDK capability
and performance reports on dpdk website
- Some may prefer to publish on their own website
- If anyone has contacts or can help coordinate please reach out to Nathan

[PATCH v2] doc: update LTS maintenance to 3 years

[Kevin Traynor]

The existing official policy was to maintain LTS releases for 2 years.

19.11 and 20.11 LTS releases were maintained for 3 years and there was
not significant issues caused by code divergence from main etc.

Update the policy to indicate 3 years maintenance for LTS releases, but
note that it depends on community support.

Signed-off-by: Kevin Traynor 

---

v2: fix typo in commit message
---
 doc/guides/contributing/stable.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/guides/contributing/stable.rst 
b/doc/guides/contributing/stable.rst
index 8156b72b20..289769a61d 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -54,5 +54,6 @@ LTS Release
 A stable release can be designated as an LTS release based on community
 agreement and a commitment from a maintainer. The current policy is that each
-year's November (X.11) release will be maintained as an LTS for 2 years.
+year's November (X.11) release will be maintained as an LTS for 3 years,
+however that is dependent on continued community support for validation.
 
 After the X.11 release, an LTS branch will be created for it at
-- 
2.43.0

[PATCH] doc: update LTS maintenance to 3 years

[Kevin Traynor]

The existing official policy was to maintain LTS releases for 2 years.

19.11 and 20.11 LTS releases were maintained for 3 years and there was
not significant issues caused by code divergence from main etc.

Update the policy to indicate 3 years maintenance for LTS releases, but
note that it dependents on community support.

Signed-off-by: Kevin Traynor 
---
 doc/guides/contributing/stable.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/guides/contributing/stable.rst 
b/doc/guides/contributing/stable.rst
index 8156b72b20..289769a61d 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -54,5 +54,6 @@ LTS Release
 A stable release can be designated as an LTS release based on community
 agreement and a commitment from a maintainer. The current policy is that each
-year's November (X.11) release will be maintained as an LTS for 2 years.
+year's November (X.11) release will be maintained as an LTS for 3 years,
+however that is dependent on continued community support for validation.
 
 After the X.11 release, an LTS branch will be created for it at
-- 
2.43.0

DPDK 21.11.6 released

[Kevin Traynor]

: fix Rx and Tx queue state
  net/vmxnet3: fix Rx and Tx queue state
  app/testpmd: fix primary process not polling all queues
  net/hns3: fix typo in function name
  net/hns3: fix some return values
  net/hns3: fix some error logs
  net/hns3: keep set/get algo key functions local
  net/hns3: fix uninitialized hash algo value
  app/procinfo: fix RSS info
  app/procinfo: adjust format of RSS info
  test/bonding: fix uninitialized RSS configuration

Jieqiang Wang (1):
  hash: align SSE lookup to scalar implementation

Joshua Washington (1):
  ethdev: account for smaller MTU when setting default

Juraj Linkeš (1):
  config/arm: fix aarch32 build with GCC 13

Kaiwen Deng (1):
  net/ice: fix TM configuration clearing

Kevin Traynor (5):
  Revert "net/iavf: fix tunnel TSO path selection"
  doc: update versions recommendations for i40e and ice
  Revert "net/iavf: fix abnormal disable HW interrupt"
  version: 21.11.6-rc1
  version: 21.11.6

Kommula Shiva Shankar (1):
  common/cnxk: fix pool buffer size in opaque mode

Long Li (1):
  net/netvsc: increase VSP response timeout to 60 seconds

Long Wu (3):
  test/bonding: remove unreachable statement
  test/bonding: add missing check
  net/bonding: fix possible overrun

Madhuker Mythri (1):
  net/tap: fix RSS for fragmented packets

Martin Weiser (1):
  net/ice: write timestamp to first segment in scattered Rx

Maxime Coquelin (6):
  vhost: fix missing vring call check on virtqueue access
  vhost: fix missing check on virtqueue access
  vhost: fix check on virtqueue access in async registration
  vhost: fix check on virtqueue access in in-flight getter
  net/virtio: fix descriptor addresses in 32-bit build
  vhost: fix missing lock protection in power monitor API

Min Zhou (1):
  test/hash: fix creation error log

Mingjin Ye (1):
  net/ice: fix crash on closing representor ports

Nagadheeraj Rottela (1):
  crypto/nitrox: fix panic with high number of segments

Pavan Nikhilesh (1):
  event/cnxk: fix getwork mode devargs parsing

Qi Zhang (2):
  net/iavf: fix Tx preparation
  net/ice: fix Tx preparation

Qiming Yang (2):
  bus/pci: fix device ID log
  net/ice: fix initial link status

Radu Nicolau (3):
  net/iavf: fix ESN session update
  net/iavf: fix Tx offload mask
  net/iavf: fix Tx offload flags check

Rahul Bhansali (1):
  eventdev/eth_rx: fix timestamp field register in mbuf

Rakesh Kudurumalla (1):
  common/cnxk: fix xstats for different packet sizes

Rongwei Liu (1):
  net/mlx5: fix matcher layout size calculation

Ruifeng Wang (1):
  ethdev: fix 32-bit build with GCC 13

Satheesh Paul (1):
  common/cnxk: fix default flow action setting

Saurabh Singhal (1):
  net/iavf: unregister interrupt handler before FD close

Sivaramakrishnan Venkat (1):
  test/crypto: fix typo in asym tests

Srikanth Yalavarthi (1):
  eal/unix: fix firmware reading with external xz helper

Stephen Hemminger (6):
  random: initialize state for unregistered non-EAL threads
  app/procinfo: remove unnecessary rte_malloc
  app/dumpcap: fix mbuf pool ring type
  meter: fix RFC4115 trTCM API Doxygen
  pdump: fix error number on IPC response
  app/dumpcap: allow multiple invocations

Timothy Miskell (1):
  net/ice: fix L1 check interval

Tomasz Duszynski (1):
  rawdev: fix device class in log message

Tyler Retzlaff (1):
  malloc: remove return from void functions

Viacheslav Galaktionov (2):
  net/sfc: set max Rx packet length for representors
  net/sfc: account for data offset on Tx

Viacheslav Ovsiienko (1):
  net/mlx5: fix multi-segment Tx inline data length

Visa Hankala (1):
  net/bonding: fix header for C++

Vladimir Medvedkin (2):
  fib: fix adding default route overwriting entire table
  fib6: fix adding default route as first route

Weiguo Li (2):
  net/enic: avoid extra unlock in MTU set
  net/sfc: remove null dereference in log

Wenjing Qiao (1):
  net/iavf: fix VLAN offload strip flag

Wenwu Ma (1):
  net/virtio: fix link state interrupt vector setting

Yiding Zhou (1):
  net/iavf: fix port stats clearing

Zhichao Zeng (1):
  net/ice: fix DCF port statistics

Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s

[Kevin Traynor]

On 11/01/2024 12:21, Maryam Tahhan wrote:
> On 11/01/2024 11:35, Ferruh Yigit wrote:
>> Devarg is user interface, changing it impacts the user.
>>
>> Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
>> when user upgrades DPDK to '22.11.4', which is not expected.
>>
>> dev_arg is not API/ABI but as it impacts the user, it is in the gray
>> area to backport to the LTS release.
> Fair enough
>>
>>
>> Current patch doesn't have Fixes tag or stable tag, so it doesn't
>> request to be backported to LTS release. I took this as an improvement,
>> more than a fix.
> 
> This was overlooked by me apologies. It's been a while since I've 
> contributed to DPDK and I must've missed this detail in the contribution 
> guide.
>> As far as I understand existing code (that use 'use_cni' dev_arg)
>> supports only single netdev, this patch adds support for multiple netdevs.
> 
> The use_cni implementation will no longer work with the AF_XDP DP as the 
> use_cni was originally implemented as it has hard coded what's now an 
> incorrect path for the UDS.
> 
>>
>> So what do you think keep LTS with 'use_cni' dev_arg, is there a
>> requirement to update LTS release?
>> If so, can it be an option to keep 'use_cni' for backward compatibility
>> but add only add 'uds_path' and remove 'use_cni' in next LTS?
> 
> 
> Yeah we can go back to the version of the patch that had the 'use_cni' 
> flag that was used in combination with the path argument. We can add 
> better documentation re the "use_cni" misnomer... What we can then do is 
> if no path argument is set by the user assume their intent and and 
> generate the path internally in the AF_XDP PMD (which was suggested by 
> Shibin at some stage). That way there should be no surprises to the End 
> User.
> 

That plan sounds like it wouldn't impact a user upgrading from 23.11.0
to 23.11.X which is always the main concern.

> Long term I would like to keep a (renamed) path argument (in case the 
> path does ever change from the AF_XDP DP POV) and use it also in 
> combination with another (maybe boolean) param for passing pinned bpf 
> maps rather than another separate path.
> 
> WDYT? Would this work for the LTS release?
> 
> 

Is it needed on LTS branch? If the current limitation was an oversight
or it's not really usable as intended, then I'd say yes. If not, then
please consider the questions in
http://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-be-backported

Seems like it's for
Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
so it would be only relevant for 23.11 only, so 23.11 maintainer (TBC)
should ack.

I suggest if you feel it should be backported, add the Fixes: and stable
tags, and 23.11 maintainer can review at some point before backport.

thanks,
Kevin.

Re: 21.11.6 patches review and test

[Kevin Traynor]

On 10/01/2024 01:28, Xu, HailinX wrote:
> Hi Kevin,
> 
> Intel have started testing, I'm sorry for not sent test results. Because some 
> personnel were on vacation before and should be able to produce results this 
> week.
> I will send the test report as soon as possible, I am deeply sorry for any 
> inconvenience caused to you.
> 

Hi Hailin,

Thanks for the update. It's no problem, that timeframe is perfectly fine.

If you let me know when the validation is finished and assuming the
results are ok, we can make the release then.

thanks,
Kevin.

> 
> Regards,
> Xu, Hailin
> 
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Tuesday, January 9, 2024 5:49 PM
>> To: sta...@dpdk.org; Mcnamara, John 
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Ali Alnubani ; benjamin.wal...@intel.com; David
>> Christensen ; Hemant Agrawal
>> ; Stokes, Ian ; Jerin Jacob
>> ; Ju-Hyoung Lee ; Luca
>> Boccassi ; Pei Zhang ;
>> qian.q...@intel.com; Raslan Darawsheh ; Thomas
>> Monjalon ; yangh...@redhat.com;
>> yuan.p...@intel.com; zhaoyan.c...@intel.com
>> Subject: Re: 21.11.6 patches review and test
>>
>> On 20/12/2023 13:22, 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.
>>>
>>
>> I have validation reports for Red Hat and Nvidia. Thank you.
>>
>> Is there any validation results from Intel, or an ETA ?
>>
>>> 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
>>>
>>
> 

Re: 21.11.6 patches review and test

[Kevin Traynor]

On 20/12/2023 13:22, 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.
> 

I have validation reports for Red Hat and Nvidia. Thank you.

Is there any validation results from Intel, or an ETA ?

> 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
> 

Re: 21.11.6 patches review and test

[Kevin Traynor]

On 03/01/2024 14:43, Ali Alnubani wrote:
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Wednesday, December 20, 2023 3:23 PM
>> To: sta...@dpdk.org
>> Cc: 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) ;
>> yangh...@redhat.com; yuan.p...@intel.com; zhaoyan.c...@intel.com
>> Subject: 21.11.6 patches review and test
>>
>> 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.
>>
> 
> Hello,
> 
> We ran the following functional tests with Nvidia hardware on 21.11.6-rc1:
> - Basic functionality:
>   Send and receive multiple types of traffic.
> - testpmd xstats counter test.
> - testpmd timestamp test.
> - Changing/checking link status through testpmd.
> - rte_flow tests 
> (https://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads)
> - RSS tests.
> - VLAN filtering, stripping, and insertion tests.
> - Checksum and TSO tests.
> - ptype tests.
> - link_status_interrupt example application tests.
> - l3fwd-power example application tests.
> - Multi-process example applications tests.
> - Hardware LRO tests.
> - Regex application tests.
> - Buffer Split tests.
> - Tx scheduling tests.
> 
> Functional tests ran on:
> - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: 
> MLNX_OFED_LINUX-23.10-1.1.9.0 / Firmware: 22.39.2048
> - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-23.10-1.1.9.0 
> / Firmware: 28.39.2048
> - DPU: BlueField-2 / DOCA SW version: 2.5.0 / Firmware: 24.39.2048
> 
> Additionally, we ran build tests with multiple configurations on the 
> following OS/driver combinations (all passed):
> - Ubuntu 20.04.6 with MLNX_OFED_LINUX-23.10-1.1.9.0.
> - Ubuntu 20.04.6 with rdma-core master (9016f34).
> - Ubuntu 20.04.6 with rdma-core v28.0.
> - Fedora 38 with rdma-core v44.0.
> - Fedora 40 (Rawhide) with rdma-core v48.0.
> - OpenSUSE Leap 15.5 with rdma-core v42.0.
> - Windows Server 2019 with Clang 16.0.6.
> 
> We don't see new issues caused by the changes in this release.
> 
> Thanks,
> Ali

Thanks Ali. Will add to the validation notes,
Kevin.

Re: [BUG] [bonding] bonding member delete bug

[Kevin Traynor]

On 08/01/2024 15:55, Ferruh Yigit wrote:
> On 12/18/2023 6:37 AM, Simon Jones wrote:
>> Oh, it's fixed by 0911d4ec and f5e72e8e
>>
> 
> Thanks Simon for reporting.
> 
> Do you know if the above fixes backported to the 21.11.x LTS release?
> 

Yes, 0911d4ec as part of 18.11 [0] and f5e72e8e backported to 21.11
branch since v21.11.2 [1]

[0]
https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=0911d4ec01839c9149a0df5758d00d9d57a47cea

[1]
https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=5a8afc69afabd3c69efbc1b0c048f31d06f7d875

thanks,
Kevin.

> 
>> 
>> Simon Jones
>>
>>
>> Simon Jones mailto:batmanu...@gmail.com>> 于2023
>> 年12月18日周一 10:51写道：
>>
>> Hi all,
>>
>> I'm using DPDK-21.11 in ovs-dpdk.
>>
>> I found a "bonding member delete bug" .
>>
>> 1. How to reproduce
>>
>> ```
>> NOTICE: bondctl is a tool I develop, it's to control DPDK.
>>
>> ### step 1, Add bonding device bond0.
>> bondctl add bond0 mode active-backup
>>
>> ### step 2, Add member m1 into bond0.
>> bondctl set :00:0a.0 master bond0 
>>
>> ### step 3, Add bond0 into ovs bridge.
>> ovs-vsctl add-port brp0 bond0 -- set interface bond0 type=dpdk
>> options:dpdk-devargs=net_bonding-bond0
>> (this command call @bond_ethdev_start at last.)
>>
>> ### step 4, Delete bond0 from ovs bridge.
>> ovs-vsctl del-port br-phy bond0
>> (this command call @bond_ethdev_stop at last.)
>>
>> ### step 5, Delete m1 from bond0.
>> bondctl set :00:0a.0 nomaster
>>
>> ### step 6, Delete bond0.
>> bondctl del bond0
>>
>> ### step 7, Add bond0.
>> bondctl add bond0 mode active-backup
>>
>> ### step 8, Add member m1 into bond0.
>> bondctl set :00:0a.0 master bond0
>> (this command call @bond_ethdev_start at last.)
>>
>> ### Then got error message.
>> 2023-12-15T08:24:04.153Z|00017|dpdk|ERR|Port 0 must be stopped to
>> allow configurr
>> ation
>> 2023-12-15T08:24:04.153Z|00018|dpdk|ERR|bond_cmd_set_master(581) -
>> can not confii
>> g slave :00:0a.0!
>> ```
>>
>> 2. Debug
>>
>> I found the reason is, when member port is DOWN, then add operation
>> will call "eth_dev->data->dev_started = 1;", but no one add active
>> member port, so when delete bond0, will NOT call @rte_eth_dev_stop,
>> then add bond0 again, got error. Detail is:
>> ```
>> ### After step 1-3, add bond0 into ovs-dpdk
>> bond_ethdev_start
>>     eth_dev->data->dev_started = 1;
>>     for (i = 0; i < internals->slave_count; i++) {
>>         if (slave_configure(eth_dev, slave_ethdev) != 0) {
>>         if (slave_start(eth_dev, slave_ethdev) != 0) {
>>             rte_eth_dev_start
>>
>> ### NOTICE, as member port is DOWN, so will NOT
>> call @activate_slave, so @active_slave_count is 0.
>> bond_ethdev_lsc_event_callback
>>     activate_slave(bonded_eth_dev, port_id);
>>
>> ### After step 4, delete bond0 from ovs-dpdk, NOTICE,
>> as @active_slave_count is 0, so will NOT call @rte_eth_dev_stop
>> bond_ethdev_stop
>>     for (i = 0; i < internals->slave_count; i++) {
>>         if (find_slave_by_id(internals->active_slaves,
>>                 internals->active_slave_count, slave_id) !=
>>                         internals->active_slave_count) {
>>             ret = rte_eth_dev_stop(slave_id);
>>
>> ### After step 5-7, delete bond0 and then add bond0
>>
>> ### After step 8, add bond0, as it's NOT call @rte_eth_dev_stop, so
>> call @rte_eth_dev_start again will got error.
>> 2023-12-15T08:24:04.153Z|00017|dpdk|ERR|Port 0 must be stopped to
>> allow configurr
>> ation
>>
>> ```
>>
>> 3. My question
>>
>> Is this bug fixed ? Which commit ?
>>
>> If NOT, how to fix this bug? I think it's better to
>> call @rte_eth_dev_stop for every member, even it's DOWN. How about this?
>>
>> Thanks~
>>
>>
>> 
>> Simon Jones
>>
> 

21.11.6 patches review and test

[Kevin Traynor]

/windows: fix build with recent MinGW

Harman Kalra (1):
  mempool/cnxk: fix free from non-EAL threads

Harry van Haaren (1):
  event/sw: fix ordering corruption with op release

Hernan Vargas (3):
  baseband/acc: fix ACC100 HARQ input alignment
  test/bbdev: fix Python script subprocess
  test/bbdev: assert failed test for queue configure

Huisong Li (13):
  net/hns3: fix order in NEON Rx
  app/testpmd: remove useless check in TSO command
  app/testpmd: fix tunnel TSO capability check
  app/testpmd: add explicit check for tunnel TSO
  app/testpmd: fix tunnel TSO configuration
  net/hns3: extract common function to obtain revision ID
  net/hns3: fix setting DCB capability
  net/hns3: fix LRO offload to report
  net/hns3: fix crash for NEON and SVE
  doc: fix hns3 build option about max queue number
  doc: update features in hns3 guide
  doc: fix RSS flow description in hns3 guide
  examples/ethtool: fix pause configuration

Ivan Malov (1):
  net/sfc: add missing error code indication to MAE init path

Jiawei Wang (3):
  net/mlx5: fix decap action checking in sample flow
  net/mlx5: fix E-Switch mirror flow rule validation
  net/mlx5: fix validation of sample encap flow action

Jiawen Wu (9):
  net/txgbe: add Tx queue maximum limit
  net/txgbe: fix GRE tunnel packet checksum
  net/ngbe: fix flow control
  net/txgbe: reconfigure MAC Rx when link update
  net/ngbe: reconfigure MAC Rx when link update
  net/txgbe: keep link down after device close
  net/ngbe: keep link down after device close
  net/txgbe: check process type in close operation
  net/ngbe: check process type in close operation

Jie Hai (39):
  net/af_packet: fix Rx and Tx queue state
  net/af_xdp: fix Rx and Tx queue state
  net/avp: fix Rx and Tx queue state
  net/bnx2x: fix Rx and Tx queue state
  net/bnxt: fix Rx and Tx queue state
  net/bonding: fix Rx and Tx queue state
  net/cxgbe: fix Rx and Tx queue state
  net/dpaa: fix Rx and Tx queue state
  net/dpaa2: fix Rx and Tx queue state
  net/e1000: fix Rx and Tx queue state
  net/ena: fix Rx and Tx queue state
  net/enetc: fix Rx and Tx queue state
  net/enic: fix Rx and Tx queue state
  net/hinic: fix Rx and Tx queue state
  net/ipn3ke: fix Rx and Tx queue state
  net/memif: fix Rx and Tx queue state
  net/mlx4: fix Rx and Tx queue state
  net/mvneta: fix Rx and Tx queue state
  net/mvpp2: fix Rx and Tx queue state
  net/ngbe: fix Rx and Tx queue state
  net/null: fix Rx and Tx queue state
  net/octeon_ep: fix Rx and Tx queue state
  net/pfe: fix Rx and Tx queue state
  net/ring: fix Rx and Tx queue state
  net/sfc: fix Rx and Tx queue state
  net/softnic: fix Rx and Tx queue state
  net/txgbe: fix Rx and Tx queue state
  net/vhost: fix Rx and Tx queue state
  net/virtio: fix Rx and Tx queue state
  net/vmxnet3: fix Rx and Tx queue state
  app/testpmd: fix primary process not polling all queues
  net/hns3: fix typo in function name
  net/hns3: fix some return values
  net/hns3: fix some error logs
  net/hns3: keep set/get algo key functions local
  net/hns3: fix uninitialized hash algo value
  app/procinfo: fix RSS info
  app/procinfo: adjust format of RSS info
  test/bonding: fix uninitialized RSS configuration

Jieqiang Wang (1):
  hash: align SSE lookup to scalar implementation

Joshua Washington (1):
  ethdev: account for smaller MTU when setting default

Juraj Linkeš (1):
  config/arm: fix aarch32 build with GCC 13

Kaiwen Deng (1):
  net/ice: fix TM configuration clearing

Kevin Traynor (3):
  Revert "net/iavf: fix tunnel TSO path selection"
  doc: update versions recommendations for i40e and ice
  Revert "net/iavf: fix abnormal disable HW interrupt"

Kommula Shiva Shankar (1):
  common/cnxk: fix pool buffer size in opaque mode

Long Li (1):
  net/netvsc: increase VSP response timeout to 60 seconds

Long Wu (3):
  test/bonding: remove unreachable statement
  test/bonding: add missing check
  net/bonding: fix possible overrun

Madhuker Mythri (1):
  net/tap: fix RSS for fragmented packets

Martin Weiser (1):
  net/ice: write timestamp to first segment in scattered Rx

Maxime Coquelin (6):
  vhost: fix missing vring call check on virtqueue access
  vhost: fix missing check on virtqueue access
  vhost: fix check on virtqueue access in async registration
  vhost: fix check on virtqueue access in in-flight getter
  net/virtio: fix descriptor addresses in 32-bit build
  vhost: fix missing lock protection in power monitor API

Min Zhou (1):
  test/hash: fix creation error log

Mingjin Ye (1):
  net/ice: fix crash on closing representor ports

Nagadheeraj Rottela (1):
  crypto/nitrox: fix panic with high numbe

Re: [PATCH v2] doc: update matching list for i40e and ice driver

[Kevin Traynor]

On 01/11/2023 11:42, Kevin Traynor wrote:

On 11/11/2022 05:27, Qiming Yang wrote:

Add recommended matching list for ice PMD in DPDK 22.07 and
i40e PMD in DPDK 22.07 and 22.11.

Signed-off-by: Qiming Yang 
---
   doc/guides/nics/i40e.rst | 8 
   doc/guides/nics/ice.rst  | 2 ++
   2 files changed, 10 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a0992dbc6c..a6c7dbd080 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -101,6 +101,10 @@ For X710/XL710/XXV710,
  +--+---+--+
  | DPDK version | Kernel driver version | Firmware version |
  +==+===+==+
+   |22.11 | 2.20.12   |   9.01   |
+   +--+---+--+
+   |22.07 | 2.19.3|   8.70   |
+   +--+---+--+
  |22.03 | 2.17.15   |   8.30   |
  +--+---+--+
  |21.11 | 2.17.4|   8.30   |
@@ -156,6 +160,10 @@ For X722,
  +--+---+--+
  | DPDK version | Kernel driver version | Firmware version |
  +==+===+==+
+   |22.11 | 2.20.12   |   6.00   |
+   +--+---+--+
+   |22.07 | 2.19.3|   5.60   |
+   +--+---+--+
  |22.03 | 2.17.15   |   5.50   |
  +--+---+--+
  |21.11 | 2.17.4|   5.30   |



The text above the table says:

"It is highly recommended to upgrade the i40e kernel driver and firmware
to avoid the compatibility issues with i40e PMD. Here is the suggested
matching list which has been tested and verified. The detailed
information can refer to chapter Tested Platforms/Tested NICs in release
notes."

The table is only showing the out-of-tree Kernel driver versions. The
tested section shows that in-tree Kernel drivers are tested with as well.

The issue is that this section says "Here is the suggested matching
list" and only lists out-of-tree drivers.

It is probably just a left over from when in-tree drivers had version
numbers but it is causing some confusion for users as it implies that
the Intel recommendation is to use out-of-tree drivers and not in-tree.

So I suggest that another column is added here to also show the in-tree
kernel driver tested with.

What do you think ?



Any thoughts on this ?

It would be best to list both, but it might be too much when in-tree 
drivers are being tested on multiple kernels etc.


Removing the column could work, but may lose some info for older releases.

So I just sent a patch to update the text:
http://inbox.dpdk.org/dev/20231110121407.444282-1-ktray...@redhat.com


diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index c7f82c261d..ce075e067c 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -64,6 +64,8 @@ The detailed information can refer to chapter Tested 
Platforms/Tested NICs in re
  
+---+---+-+---+--+---+
  |22.03  | 1.8.3 |  1.3.28 |  1.3.35   |1.3.8 
|3.2|
  
+---+---+-+---+--+---+
+   |22.07  | 1.9.11|  1.3.30 |  1.3.37   |1.3.10|  
  4.0|
+   
+---+---+-+---+--+---+
   
   Pre-Installation Configuration

   --

[PATCH] doc: update matching list recommendations

[Kevin Traynor]

Update documentation to stop recommending that
out-of-tree Linux Kernel drivers are used for
i40e and ice.

Cc: sta...@dpdk.org

Signed-off-by: Kevin Traynor 

---
Sent mail explaining background here:
http://inbox.dpdk.org/dev/d212cb6e-53fd-b017-0d93-ff0b01476...@redhat.com/
---
 doc/guides/nics/i40e.rst | 13 -
 doc/guides/nics/ice.rst  | 15 +--
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 791e9553bc..8b2a94060c 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -89,11 +89,14 @@ Windows Prerequisites
   <https://git.dpdk.org/dpdk-kmods/tree/windows/netuio/README.rst>`_.
 
-Recommended Matching List
--
+Kernel driver and Firmware Matching List
+
 
 It is highly recommended to upgrade the i40e kernel driver and firmware to
-avoid the compatibility issues with i40e PMD. Here is the suggested matching
-list which has been tested and verified. The detailed information can refer
-to chapter Tested Platforms/Tested NICs in release notes.
+avoid the compatibility issues with i40e PMD. The table below shows a
+summary of the DPDK versions with corresponding out-of-tree Linux kernel
+drivers and Firmware. The full list of in-tree and out-of-tree Linux kernel
+drivers from kernel.org and Linux distributions that were tested and verified
+are listed in the Tested Platforms section of the Release notes for each
+release.
 
 For X710/XL710/XXV710,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 6e71aac3c2..0f7a797ad5 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -42,11 +42,14 @@ Windows Prerequisites
 
 
-Recommended Matching List
--
+Kernel driver, DDP and Firmware Matching List
+-
 
-It is highly recommended to upgrade the ice kernel driver, firmware and DDP 
package
-to avoid the compatibility issues with ice PMD.
-Here is the suggested matching list which has been tested and verified.
-The detailed information can refer to chapter Tested Platforms/Tested NICs in 
release notes.
+It is highly recommended to upgrade the ice kernel driver, firmware and DDP
+package to avoid the compatibility issues with ice PMD. The table below shows
+a summary of the DPDK versions with corresponding out-of-tree Linux kernel
+drivers, DDP package and Firmware. The full list of in-tree and out-of-tree
+Linux kernel drivers from kernel.org and Linux distributions that were tested
+and verified are listed in the Tested Platforms section of the Release notes
+for each release.
 

+---+---+-+---+--+---+
-- 
2.41.0

Re: [21.11 PATCH v1] net/mlx5: fix matcher layout size calculation

[Kevin Traynor]

On 03/11/2023 03:07, Rongwei Liu wrote:

Initially, the rdma-core library only supported misc0 to misc3 fields in
matching resources, misc4 and misc5 fields were added to handle new
features. The matcher layout, passing from DPDK to rdma-core, shouldn't
exceed the size of the engaged library version capabilities.

For now, there is no way to know what is the maximum capability of
rdma-core, and DPDK should limit the matcher layout to misc3 if
possible (no matching on fields misc4 and misc5 are requested by the
application).

The check if misc4 and misc5 features were requested was based on checking
the values against zeroes. The matching mask should be checked instead.

Fixes: 630a587bfb37 ("net/mlx5: support matching on VXLAN reserved field")
Cc:rongw...@nvidia.com
Cc:sta...@dpdk.org
Signed-off-by: Rongwei Liu
Acked-by: Viacheslav Ovsiienko
---
  drivers/net/mlx5/mlx5_flow_dv.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)


Thanks Rongwei. I added upstream commit hash, removed cc's and applied 
to branch 21.11 [0]. fyi - patches only for backport should go to 
sta...@dpdk.org only. Just makes things a bit easier for email filters, 
patchwork, ci etc.


regards,
Kevin

[0] 
https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=6de3135f1e2ec52d25505ae1ea3ef9a242ddcd5d

Re: [PATCH v2] doc: update matching list for i40e and ice driver

[Kevin Traynor]

On 11/11/2022 05:27, Qiming Yang wrote:

Add recommended matching list for ice PMD in DPDK 22.07 and
i40e PMD in DPDK 22.07 and 22.11.

Signed-off-by: Qiming Yang 
---
  doc/guides/nics/i40e.rst | 8 
  doc/guides/nics/ice.rst  | 2 ++
  2 files changed, 10 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a0992dbc6c..a6c7dbd080 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -101,6 +101,10 @@ For X710/XL710/XXV710,
 +--+---+--+
 | DPDK version | Kernel driver version | Firmware version |
 +==+===+==+
+   |22.11 | 2.20.12   |   9.01   |
+   +--+---+--+
+   |22.07 | 2.19.3|   8.70   |
+   +--+---+--+
 |22.03 | 2.17.15   |   8.30   |
 +--+---+--+
 |21.11 | 2.17.4|   8.30   |
@@ -156,6 +160,10 @@ For X722,
 +--+---+--+
 | DPDK version | Kernel driver version | Firmware version |
 +==+===+==+
+   |22.11 | 2.20.12   |   6.00   |
+   +--+---+--+
+   |22.07 | 2.19.3|   5.60   |
+   +--+---+--+
 |22.03 | 2.17.15   |   5.50   |
 +--+---+--+
 |21.11 | 2.17.4|   5.30   |



The text above the table says:

"It is highly recommended to upgrade the i40e kernel driver and firmware 
to avoid the compatibility issues with i40e PMD. Here is the suggested 
matching list which has been tested and verified. The detailed 
information can refer to chapter Tested Platforms/Tested NICs in release 
notes."


The table is only showing the out-of-tree Kernel driver versions. The 
tested section shows that in-tree Kernel drivers are tested with as well.


The issue is that this section says "Here is the suggested matching 
list" and only lists out-of-tree drivers.


It is probably just a left over from when in-tree drivers had version 
numbers but it is causing some confusion for users as it implies that 
the Intel recommendation is to use out-of-tree drivers and not in-tree.


So I suggest that another column is added here to also show the in-tree 
kernel driver tested with.


What do you think ?


diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index c7f82c261d..ce075e067c 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -64,6 +64,8 @@ The detailed information can refer to chapter Tested 
Platforms/Tested NICs in re
 
+---+---+-+---+--+---+
 |22.03  | 1.8.3 |  1.3.28 |  1.3.35   |1.3.8 | 
   3.2|
 
+---+---+-+---+--+---+
+   |22.07  | 1.9.11|  1.3.30 |  1.3.37   |1.3.10|  
  4.0|
+   
+---+---+-+---+--+---+
  
  Pre-Installation Configuration

  --

Re: [PATCH v1 06/11] test/bbdev: assert failed test for queue configure

[Kevin Traynor]

On 23/10/2023 10:07, Maxime Coquelin wrote:

With LTS maintainers actually added... sorry.

On 10/23/23 11:05, Maxime Coquelin wrote:



On 10/19/23 14:12, Chautru, Nicolas wrote:

Hi Maxime,


-Original Message-
From: Maxime Coquelin 
Sent: Thursday, October 19, 2023 10:47 AM
To: Chautru, Nicolas ; Vargas, Hernan
; dev@dpdk.org; gak...@marvell.com; Rix, Tom

Cc: Zhang, Qi Z 
Subject: Re: [PATCH v1 06/11] test/bbdev: assert failed test for
queue configure

Hi Nicolas,

On 10/19/23 10:41, Chautru, Nicolas wrote:

Hi Maxime,

Do we really want to make these kind of changes on to the stable
release, it

tends to artificially increase the amount of churn on the stable
release which
can be counterproductive for such changes which don't add much value
if any
to user/developper.

Happy to follow your suggestion but a general feedback is lack of
appetite for

very large amount of changes in stable patches which inhibit
adoption, so
would expect to put things there that we would genuinely flag as a bug.

Kindly share your thoughts.


Checking for configuration failure in a test application is quite
useful in my
opinion, as it can help catching regressions, isn't it?


I don’t personally think this (or for other commit on that serie) hits
that bar for being required in stable release. This ends up being
counterproductive having stable release with a huge amount of commits
that are not really required, and it ends up being a reason for people
not to move to stable release.
But if you are really convinced, ok to follow your reco.


Adding LTS maintainers if they want to step in.

Personally, I think ot should be backported.



We wrote the policy [0] with exactly this type of discussion in mind :-)

"All patches accepted on the main branch with a Fixes: tag should be 
backported to the relevant stable/LTS branches, unless the submitter 
indicates otherwise. If there are exceptions, they will be discussed on 
the mailing lists."


The idea behind the policy is to try and avoid spending time on 
subjective discussions about how bad the bug being fixed should be 
before it is backported, and to avoid different LTS maintainers making 
different judgements about the same fixes on different branches.


So we try to keep it simple - if it's a bugfix, backport it. If there's 
a specific reason not too, fine.


So if it's fixing something, please add the Fixes: tag and we'll take it 
from there into the LTS.


thanks,
Kevin.

[0] 
http://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-be-backported



Maxime



Maxime

Thanks
Nic



-Original Message-
From: Maxime Coquelin 
Sent: Tuesday, October 17, 2023 9:43 PM
To: Vargas, Hernan ; dev@dpdk.org;
gak...@marvell.com; Rix, Tom 
Cc: Chautru, Nicolas ; Zhang, Qi Z

Subject: Re: [PATCH v1 06/11] test/bbdev: assert failed test for
queue configure



On 9/29/23 20:13, Hernan Vargas wrote:

Stop test if rte_bbdev_queue_configure fails to configure queue.

Signed-off-by: Hernan Vargas 
---
     app/test-bbdev/test_bbdev.c | 3 ++-
     1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/app/test-bbdev/test_bbdev.c
b/app/test-bbdev/test_bbdev.c index 65805977aead..cf224dca5d04
100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -366,7 +366,8 @@ test_bbdev_configure_stop_queue(void)
  * - queue should be started if deferred_start ==
  */
     ts_params->qconf.deferred_start = 0;
-    rte_bbdev_queue_configure(dev_id, queue_id, &ts_params->qconf);
+    TEST_ASSERT_SUCCESS(rte_bbdev_queue_configure(dev_id, queue_id,

&ts_params->qconf),

+    "Failed test for rte_bbdev_queue_configure");
     rte_bbdev_start(dev_id);

     TEST_ASSERT_SUCCESS(return_value =

rte_bbdev_queue_info_get(dev_id,

If should be a fix IMO.
With fixes tag added and stable cc'ed:

Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

Re: [PATCH] bitops: mark new symbols as stable

[Kevin Traynor]

On 23/10/2023 08:09, Joyce Kong wrote:

-Original Message-
From: David Marchand 
Sent: Wednesday, October 18, 2023 5:11 PM
To: dev@dpdk.org
Cc: tho...@monjalon.net; techbo...@dpdk.org; Joyce Kong
; Tyler Retzlaff 
Subject: [PATCH] bitops: mark new symbols as stable

Calling an experimental symbol from an inline helper triggers a warning when
such code is not compiled with experimental API.
This can be seen when rte_bitops.h gets (indirectly) included in OVS builds.

On the other hand, rte_clz32, rte_clz64, rte_ctz32, rte_ctz64, rte_popcount32,
rte_popcount64 are inline helpers for abstracting common bit counting
functions. This part of the API is unlikely to change.

Mark those symbols as stable.

Fixes: 18898c4d06f9 ("eal: use abstracted bit count functions")

Signed-off-by: David Marchand 


Reviewed-by: Joyce Kong 



Acked-by: Kevin Traynor 


---
Copying Techboard for info, as this goes against the usual policy of marking
new API as experimental.



Approved in techboard meeting:
http://inbox.dpdk.org/dev/0520f6a2-d98f-260d-8998-9bff8b879...@redhat.com/


---
  lib/eal/include/rte_bitops.h | 48 
  1 file changed, 48 deletions(-)

diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h index
6b8ae8d3ac..174d25216d 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -280,9 +280,6 @@ rte_bit_relaxed_test_and_clear64(unsigned int nr,
volatile uint64_t *addr)  #ifdef RTE_TOOLCHAIN_MSVC

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of leading 0-bits in v.
   *
   * @param v
@@ -290,7 +287,6 @@ rte_bit_relaxed_test_and_clear64(unsigned int nr,
volatile uint64_t *addr)
   * @return
   *   The count of leading zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_clz32(uint32_t v)
  {
@@ -302,9 +298,6 @@ rte_clz32(uint32_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of leading 0-bits in v.
   *
   * @param v
@@ -312,7 +305,6 @@ rte_clz32(uint32_t v)
   * @return
   *   The count of leading zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_clz64(uint64_t v)
  {
@@ -324,9 +316,6 @@ rte_clz64(uint64_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of trailing 0-bits in v.
   *
   * @param v
@@ -334,7 +323,6 @@ rte_clz64(uint64_t v)
   * @return
   *   The count of trailing zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_ctz32(uint32_t v)
  {
@@ -346,9 +334,6 @@ rte_ctz32(uint32_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of trailing 0-bits in v.
   *
   * @param v
@@ -356,7 +341,6 @@ rte_ctz32(uint32_t v)
   * @return
   *   The count of trailing zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_ctz64(uint64_t v)
  {
@@ -368,9 +352,6 @@ rte_ctz64(uint64_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of 1-bits in v.
   *
   * @param v
@@ -378,7 +359,6 @@ rte_ctz64(uint64_t v)
   * @return
   *   The count of 1-bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_popcount32(uint32_t v)
  {
@@ -386,9 +366,6 @@ rte_popcount32(uint32_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of 1-bits in v.
   *
   * @param v
@@ -396,7 +373,6 @@ rte_popcount32(uint32_t v)
   * @return
   *   The count of 1-bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_popcount64(uint64_t v)
  {
@@ -406,9 +382,6 @@ rte_popcount64(uint64_t v)  #else

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of leading 0-bits in v.
   *
   * @param v
@@ -416,7 +389,6 @@ rte_popcount64(uint64_t v)
   * @return
   *   The count of leading zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_clz32(uint32_t v)
  {
@@ -424,9 +396,6 @@ rte_clz32(uint32_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of leading 0-bits in v.
   *
   * @param v
@@ -434,7 +403,6 @@ rte_clz32(uint32_t v)
   * @return
   *   The count of leading zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_clz64(uint64_t v)
  {
@@ -442,9 +410,6 @@ rte_clz64(uint64_t v)  }

  /**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior
notice
- *
   * Get the count of trailing 0-bits in v.
   *
   * @param v
@@ -452,7 +417,6 @@ rte_clz64(uint64_t v)
   * @return
   *   The count of trailing zero bits.
   */
-__rte_experimental
  static inline unsigned int
  rte_ctz32(uint32_t v)
  {

Minutes of Technical Board meeting 18-October-23

[Kevin Traynor]

Members Attending
-
Aaron Conole
Bruce Richardson
Hemant Agrawal
Honappa Nagarahalli
Jerin Jacob
Kevin Traynor (Chair)
Konstantin Ananyev
Maxime Coquelin
Stephen Hemminger
Thomas Monjalon

NOTE: The technical board meetings are on every second Wednesday at 3 pm
UTC.
Meetings are public, and DPDK community members are welcome to attend.
Agenda and minutes can be found at http://core.dpdk.org/techboard/minutes

Next meeting will be on Wednesday 2023-Nov-02 @ 3pm UTC, and will
be chaired by Aaron.

Agenda Items


Experimental API promotion (David)
--
- Some experimental API being called from inline helper triggering a
warning in applications not compile with experimental API (e.g. OVS)
- Patch submitted to promote those API to stable early
(https://patchwork.dpdk.org/project/dpdk/patch/20231018091123.1594324-1-david.march...@redhat.com/)
- Simple signature, not likely to need to be changed
- Promotion to stable API approved
- Some increased documentation on endianness needed
- Checks can be added to CI to prevent a re-occurrence as a later step

Increase max lcores for AMD EPYC CPUs (Sivaprasad)
--
- Patch to increase max core count for native AMD EPYC builds
(http://inbox.dpdk.org/dev/20230925151027.558546-1-sivaprasad.tumm...@amd.com)
- There is some asks for more than 128 worker cores
- Discussion about generally increasing the default max core count and
trade-offs with memory consumption but this is longer term issue
- Acceptance for the direction of this patch in the short term
- Details of whether it should be for EPYC only or x86 to be figured out
on mailing list

Conclusion of joint meeting yesterday between two boards (Nathan)
-
- Exploring option of adding developer in UNH for DTS
- Ben presented some ideas around developer focused campaigns for 2024
-- reports/code challenges/swag as well as continuing user stories/blogs
- Discussion on exploring how DPDK can help with Cloud/Security/AI

Website meeting minutes/invite (Kevin/Thomas)
-
- Any TB minutes available but missing from list Thomas sent, please let
him know
- Thomas will send patch with updated TB minutes and new meeting invite

AOB
---
- UNH lab will give update on 2023 progress in next TB meeting
-- Discussion may start on 2024 priorities
-- Aaron will poll for 2024 items soon

- Ferruh would like more reviews on bonding patches that have specific
APIs and change ethdev structs
(https://patchwork.dpdk.org/project/dpdk/list/?series=29900&state=*)

- Some maintainers have changed priorities and have less time now
-- There is a need for more maintainers to help with patch review/merging

[PATCH] docs: add note about experimental API in LTS

[Kevin Traynor]

The justification and impact for changing experimental API on LTS
branches is different from the main branch. So the policy that is
being used for allowing experimental APIs to change is stricter on
the LTS branches.

This was not documented anywhere, so add some documentation.

Suggested-by: David Marchand 
Signed-off-by: Kevin Traynor 
---
 doc/guides/contributing/stable.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/guides/contributing/stable.rst 
b/doc/guides/contributing/stable.rst
index 9ee7b4b7cc..8156b72b20 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -127,4 +127,12 @@ but may be considered in some cases where:
 * An existing feature in LTS is not usable as intended without it.
 
+APIs marked as ``experimental`` are not considered part of the ABI version
+and can be changed without prior notice. This is necessary for the API to be
+improved and stabilized and become part of the ABI version in the future.
+
+However, in LTS releases ``experimental`` API should not be changed as there
+will not be a future ABI version on the branch and compatibility with previous
+release of an LTS version is of the highest importance.
+
 The Stable Mailing List
 ---
-- 
2.41.0

Re: [PATCH] config/x86: config support for AMD EPYC processors

[Kevin Traynor]

On 16/10/2023 06:20, Tummala, Sivaprasad wrote:

[AMD Official Use Only - General]

Hi DPDK Techboard,

Request to add this topic for discussion in the next techboard meeting.



Hi Sivaprasad,

Are you or a representative (Ferruh?) able to attend the techboard 
meeting (3pm UTC Wednesday) to discuss this item?


thanks,
Kevin.


Thanks & Regards,
Sivaprasad


-Original Message-
From: Tummala, Sivaprasad 
Sent: Monday, October 16, 2023 10:44 AM
To: David Marchand 
Cc: bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru; dev@dpdk.org;
dpdk-techboard ; Thomas Monjalon

Subject: RE: [PATCH] config/x86: config support for AMD EPYC processors

[AMD Official Use Only - General]

Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.


[AMD Official Use Only - General]


-Original Message-
From: David Marchand 
Sent: Friday, October 6, 2023 1:21 PM
To: Tummala, Sivaprasad 
Cc: bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru;
dev@dpdk.org; dpdk-techboard ; Thomas Monjalon

Subject: Re: [PATCH] config/x86: config support for AMD EPYC
processors

Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.


On Mon, Sep 25, 2023 at 5:11 PM Sivaprasad Tummala
 wrote:


From: Sivaprasad Tummala 

By default, max lcores are limited to 128 for x86 platforms.
On AMD EPYC processors, this limit needs to be increased to leverage
all the cores.

The patch adjusts the limit specifically for native compilation on
AMD EPYC CPUs.

Signed-off-by: Sivaprasad Tummala 


This patch is a revamp of


http://inbox.dpdk.org/dev/BY5PR12MB3681C3FC6676BC03F0B42CCC96789@BY5PR

12MB3681.namprd12.prod.outlook.com/
for which a discussion at techboard is supposed to have taken place.
But I didn't find a trace of it.

One option that had been discussed in the previous thread was to
increase the max number of cores for x86.
I am unclear if this option has been properly evaluated/debatted.

Can the topic be brought again at techboard?


Hi David,

The patch is intended to detect AMD platforms and enable all CPU cores by 
default
on native builds.

As an optimization for memory footprint, users can override this by specifying 
"-
Dmax_lcores" option based on DPDK lcores required for their usecases.

Sure, will request to add this topic for discussion at techboard.


Thanks.

--
David Marchand

Re: [PATCH 4/4] pcapng: move timestamp calculation into pdump

[Kevin Traynor]

On 06/10/2023 10:10, David Marchand wrote:

On Wed, Oct 4, 2023 at 7:13 PM Stephen Hemminger
 wrote:


On Mon, 2 Oct 2023 10:15:25 +0200
David Marchand  wrote:





Bugzilla ID: 1291 ?

This patch (and patch 3) updates some pcapng API, is it worth a RN update?


Fixes: c882eb544842 ("pcapng: fix timestamp wrapping in output files")


Is it worth backporting?
I would say no, as some API update was needed to fix the issue.
But on the other hand, this is an experimental API, so I prefer to ask.



Signed-off-by: Stephen Hemminger 


Good question.
Is experimental API allowed to change in a stable release?


I don't think this is cleary described in our ABI policy.
An experimental API may be changed at any time, but nothing is said
wrt backports.

Breaking an API is always a pain, and for a LTS release it would
probably be badly accepted by users.



yes, I agree. IIRC, this arose sometime in the past with a branch that 
Luca was maintaining and I think the consensus among LTS maintainers was 
not to change experimental API on stable branches.



Cc: Kevin for his opinion.

We may need a clarification on this topic in the doc.




Perhaps it's not a "rule" since experimental API comes with no 
guarantee, but I can add something to the docs that it is a guideline 
not to break experimental API on stable branch.

Re: [PATCH v2 1/1] net/mana: enable 32 bit build for mana driver

[Kevin Traynor]

On 20/09/2023 11:03, Ferruh Yigit wrote:

On 9/20/2023 4:06 AM, Wei Hu wrote:

-Original Message-
From: Ferruh Yigit 
Sent: Tuesday, September 19, 2023 7:05 PM
To: Wei Hu ; dev@dpdk.org; Long Li

Cc: sta...@dpdk.org; Kevin Traynor ; Luca Boccassi

Subject: Re: [PATCH v2 1/1] net/mana: enable 32 bit build for mana driver

On 9/19/2023 3:44 AM, Wei Hu wrote:

-Original Message-
From: Ferruh Yigit 
Sent: Tuesday, September 19, 2023 1:41 AM
To: Wei Hu ; dev@dpdk.org; Long Li

Cc: sta...@dpdk.org; Kevin Traynor ; Luca
Boccassi 
Subject: Re: [PATCH v2 1/1] net/mana: enable 32 bit build for mana
driver

On 9/13/2023 1:23 PM, Wei Hu wrote:

Enable 32 bit build on x86 Linux. Fixed build warnings and errors
when building in 32 bit.

Cc: sta...@dpdk.org



This is not a fix, but adding 32bit support to the driver, so not
sure about backporting. cc'ed Kevin & Luca for guidance.

I will drop the tag while merging unles otherwise suggested by LTS
maintainers.


Hi Ferruh,

We have a customer who needs it to be on 22.11.x. That is why I put "Cc:

sta...@dpdk.org" in it.




Got it, lets get comment from the LTS maintainers.




Signed-off-by: Wei Hu 



Hi Wei,

Patch looks good, but it basically fixes the format specifiers that
will cause build error for 32 bit.

Is there any other change required to make driver functional for 32
bit, or does it become functional with this change?
And if it does can you please confirm explicityly that driver tested
on
32 bit with this patch?


Another patch, " net/mana: add 32 bit short doorbell", is required to
make mana fully functional  with 32 bit applications. This patch is to
fix some build time errors and warnings when build in 32 bit.  These
patches can be independently built and they are addressing two different

issues. So, I put them into two independent patches.


I have tested it on 32 bit applications. They can run with this patch.
Just mana would not work as the applications still use 64 bit long door bells,

which do not work for 32 bit apps.




Thanks Wei, for clarification.

As this patch enables the 32bit build of driver in meson, can you please add
comment log that 32bit driver is not functional yet?

Or maybe meson update can be moved to short doorbell patch, where driver
becomes functional for 32 bit, this patch can mention in commit log that is
preparation for 32 bit support, what do you think?


Thanks Ferruh. I would like to add comment log that 32bit driver is not fully
functioning yet until short doorbell support is added. Meanwhile still keep
the meson update in within this patch to keep it complete. Hope this works
for you.



I think it will do.
Can you please send those two patches in a same patchset, that gives
some context if we need to back trace it later?



+1

Adding 22.11 maintainer Xueming. The main thing is that it would not 
cause a regression to 64 bit. That is something that would need to be 
tested by Microsoft.

Re: [PATCH v2 0/2] check illegal packets

[Kevin Traynor]

On 18/09/2023 15:42, David Marchand wrote:

On Tue, Sep 27, 2022 at 9:24 AM Kevin Liu  wrote:


Check whether the data packet is illegal of ice and iavf driver.

v2:
Change the scheme, check the data_len and update commit log.

Kevin Liu (2):
   net/iavf: check illegal packets
   net/ice: check illegal packets

  drivers/net/iavf/iavf_rxtx.c |  9 +
  drivers/net/iavf/iavf_rxtx.h |  2 ++
  drivers/net/ice/ice_rxtx.c   | 11 +++
  drivers/net/ice/ice_rxtx.h   |  2 ++
  4 files changed, 24 insertions(+)


This series looks wrong to me.

- What happens if the application requests TSO to the nic?
- Checking data_len of a mbuf means only checking the size of the
first segment, so if any limitation applies to the packet size, it
should by checking pkt_len.

I will probably send reverts for the two patches.




there is a fix also that needs to be checked:
688cb2f2c61e ("net/ice: fix scalar Tx path segment")

Re: 22.11.3 patches review and test

[Kevin Traynor]

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



Regards
Zhichao

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

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

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

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

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

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

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

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

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John

;

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

Peng,

Yuan ; Chen, Zhaoyan



Subject: 22.11.3 patches review and test

Hi all,

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

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

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

notes.


A release candidate tarball can be found at:

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

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

Thanks.


We are conducting DPDK testing and have found two issues.

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

to 22.11.3.

   Fix patch commit id on DPDK main:
7e7b6762eac292e78c77ad37ec0973c0c944b845

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


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

@IAVF maintainers - please confirm my analysis is correct ?

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

December.


Hi Kevin,

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



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

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



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





Hi Kevin,

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


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

if (txq->rs_thresh < IAVF_VPMD_TX_MAX_BURST ||
txq->rs_thresh > IAV

Re: 22.11.3 patches review and test

[Kevin Traynor]

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

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

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

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

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

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

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John ;
Ju-Hyoung Lee ; Kevin Traynor
; Luca Boccassi ; Pei Zhang
; Xu, Qian Q ; Raslan
Darawsheh ; Thomas Monjalon
; Yanghang Liu ; Peng,
Yuan ; Chen, Zhaoyan



Subject: 22.11.3 patches review and test

Hi all,

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

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

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

notes.


A release candidate tarball can be found at:

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

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

Thanks.


We are conducting DPDK testing and have found two issues.

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

to 22.11.3.

  Fix patch commit id on DPDK main:
7e7b6762eac292e78c77ad37ec0973c0c944b845

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


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

@IAVF maintainers - please confirm my analysis is correct ?

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


Hi Kevin,

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



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

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



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



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

if (txq->rs_thresh < IAVF_VPMD_TX_MAX_BURST ||
txq->rs_thresh > IAVF_VPMD_TX_MAX_FREE_BUF)
return -1;

if (txq->offloads & IAVF_TX_NO_VECTOR_FLAGS)
return -1;
  ^^^ Adding the extra bits to IAVF_TX_NO_VECTOR_FLAGS gives
*more* reasons for why this statement might not be true, so returning -1
indicating that vector cannot be used for tx queue



typo here - just to clarify, the new flags give more reasons for this 
statement to be true, so returning -1.






static inline bool
check_tx_vec_allow(struct iavf_tx_queue *txq)
{
if (!(txq->offloads & IAVF_TX_NO_VECTOR_FLAGS) &&

  ^^^ Adding the

Re: 22.11.3 patches review and test

[Kevin Traynor]

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

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

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

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

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

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John ;
Ju-Hyoung Lee ; Kevin Traynor
; Luca Boccassi ; Pei Zhang
; Xu, Qian Q ; Raslan
Darawsheh ; Thomas Monjalon
; Yanghang Liu ; Peng,
Yuan ; Chen, Zhaoyan



Subject: 22.11.3 patches review and test

Hi all,

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

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

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

notes.


A release candidate tarball can be found at:

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

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

Thanks.


We are conducting DPDK testing and have found two issues.

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

to 22.11.3.

 Fix patch commit id on DPDK main:
7e7b6762eac292e78c77ad37ec0973c0c944b845

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


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

@IAVF maintainers - please confirm my analysis is correct ?

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


Hi Kevin,

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



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

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



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



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

if (txq->rs_thresh < IAVF_VPMD_TX_MAX_BURST ||
txq->rs_thresh > IAVF_VPMD_TX_MAX_FREE_BUF)
return -1;

if (txq->offloads & IAVF_TX_NO_VECTOR_FLAGS)
return -1;
^^^ Adding the extra bits to IAVF_TX_NO_VECTOR_FLAGS gives 
*more* reasons for why this statement might not be true, so returning -1 
indicating that vector cannot be used for tx queue





static inline bool
check_tx_vec_allow(struct iavf_tx_queue *txq)
{
if (!(txq->offloads & IAVF_TX_NO_VECTOR_FLAGS) &&

^^^ Adding the extra bits to IAVF_TX_NO_VECTOR_FLAGS gives 
*more* reason for this statement will be false and then false returned 
indicating that vector cannot be used.

Re: 22.11.3 patches review and test

[Kevin Traynor]

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

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

-Original Message-
From: Xueming Li 
Sent: Thursday, August 17, 2023 2:14 PM
To: sta...@dpdk.org
Cc: xuemi...@nvdia.com; dev@dpdk.org; Abhishek Marathe
; Ali Alnubani ;
Walker, Benjamin ; David Christensen
; Hemant Agrawal ;
Stokes, Ian ; Jerin Jacob ;
Mcnamara, John ; Ju-Hyoung Lee
; Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ; Thomas
Monjalon ; Yanghang Liu ;
Peng, Yuan ; Chen, Zhaoyan 
Subject: 22.11.3 patches review and test

Hi all,

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

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

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

A release candidate tarball can be found at:

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

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

Thanks.


We are conducting DPDK testing and have found two issues.

1. The startup speed of testpmd is significantly slower in the os of SUSE
This issue fix patch has been merged into main, But it has not backported 
to 22.11.3.
Fix patch commit id on DPDK main: 7e7b6762eac292e78c77ad37ec0973c0c944b845

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


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


@IAVF maintainers - please confirm my analysis is correct ?

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


thanks,
Kevin.


commit 9b7215f150d0bfc5cb00fce68ff08e5217c7f2b3 on v22.11.3-rc1.
This commit is for the new feature (avx512 checksum offload) in DPDK 23.03, 
which should not be backported to the LTS version since avx512 checksum offload 
is not supported in v22.11.3 LTS.



Thanks for flagging Xueming.

The issue is that it was listed as fixing 059f18ae2aec ("net/iavf: add
offload path for Tx AVX512") which goes back to 21.05.

This could have been avoided if the 'Fixes:' tag was correct, or if the
authors replied to the email about queued backports :/

Requesting iavf/next-net-intel maintainers to check Fixes: tags are
correct before merging.

DPDK 21.11.5 is already released with this patch. Any idea why it did
not show up in validation for 21.11.5 ? Is it an issue for 21.11.5 ? How
critical is it ?

I can revert it on the 21.11 branch, but it will need to wait until
21.11.6 in December before it will be reverted in a released version.

thanks,
Kevin.


Regards,
Xu, Hailin

Re: 22.11.3 patches review and test

[Kevin Traynor]

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

-Original Message-
From: Xueming Li 
Sent: Thursday, August 17, 2023 2:14 PM
To: sta...@dpdk.org
Cc: xuemi...@nvdia.com; dev@dpdk.org; Abhishek Marathe
; Ali Alnubani ;
Walker, Benjamin ; David Christensen
; Hemant Agrawal ;
Stokes, Ian ; Jerin Jacob ;
Mcnamara, John ; Ju-Hyoung Lee
; Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ; Thomas
Monjalon ; Yanghang Liu ;
Peng, Yuan ; Chen, Zhaoyan 
Subject: 22.11.3 patches review and test

Hi all,

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

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

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

A release candidate tarball can be found at:

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

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

Thanks.


We are conducting DPDK testing and have found two issues.

1. The startup speed of testpmd is significantly slower in the os of SUSE
   This issue fix patch has been merged into main, But it has not backported to 
22.11.3.
   Fix patch commit id on DPDK main: 7e7b6762eac292e78c77ad37ec0973c0c944b845

2. The SCTP tunnel packet of iavf cannot be forwarded in avx512 mode
   commit 9b7215f150d0bfc5cb00fce68ff08e5217c7f2b3 on v22.11.3-rc1.
   This commit is for the new feature (avx512 checksum offload) in DPDK 23.03, 
which should not be backported to the LTS version since avx512 checksum offload 
is not supported in v22.11.3 LTS.



Thanks for flagging Xueming.

The issue is that it was listed as fixing 059f18ae2aec ("net/iavf: add 
offload path for Tx AVX512") which goes back to 21.05.


This could have been avoided if the 'Fixes:' tag was correct, or if the 
authors replied to the email about queued backports :/


Requesting iavf/next-net-intel maintainers to check Fixes: tags are 
correct before merging.


DPDK 21.11.5 is already released with this patch. Any idea why it did 
not show up in validation for 21.11.5 ? Is it an issue for 21.11.5 ? How 
critical is it ?


I can revert it on the 21.11 branch, but it will need to wait until 
21.11.6 in December before it will be reverted in a released version.


thanks,
Kevin.


Regards,
Xu, Hailin

DPDK 21.11.5 released

[Kevin Traynor]

 big packets
  doc: update BIOS settings and supported HW for NTB

Kaijun Zeng (1):
  net/vmxnet3: fix return code in initializing

Kaiwen Deng (1):
  net/ice: fix DCF RSS initialization

Kaiyu Zhang (1):
  ethdev: fix potential leak in PCI probing helper

Kamalakannan R (1):
  pipeline: fix double free for table stats

Ke Xu (1):
  net/iavf: fix tunnel TSO path selection

Kevin Traynor (2):
  version: 21.11.5-rc1
  version: 21.11.5

Long Wu (1):
  net/bonding: fix destroy dedicated queues flow

Mattias Rönnblom (1):
  event/dsw: free rings on close

Maxime Coquelin (1):
  vhost: fix invalid call FD handling

Michael Baum (1):
  doc: fix format in flow API guide

Michal Schmidt (1):
  net/iavf: fix VLAN offload with AVX512

Min Zhou (1):
  net/ixgbe: add proper memory barriers in Rx

Mingjin Ye (3):
  net/ice: fix statistics
  net/ice: fix DCF control thread crash
  net/iavf: fix abnormal disable HW interrupt

Nithin Dabilpuram (2):
  common/cnxk: fix inline device VF identification
  net/cnxk: fix cookies check with security offload

Pavan Nikhilesh (2):
  doc: fix event timer adapter guide
  event/cnxk: fix nanoseconds to ticks conversion

Peng Zhang (1):
  net/nfp: fix address always related with PF ID 0

Philip Prindeville (1):
  vfio: fix include with musl runtime

Qi Zhang (1):
  net/ice: initialize parser for double VLAN

Qiming Yang (6):
  net/ice/base: remove unreachable code
  net/e1000: fix queue number initialization
  net/ice: fix VLAN mode parser
  net/ixgbe: fix Rx and Tx queue status
  net/igc: fix Rx and Tx queue status
  net/e1000: fix Rx and Tx queue status

Rahul Bhansali (1):
  common/cnxk: fix IPsec IPv6 tunnel address byte swap

Raslan Darawsheh (1):
  app/testpmd: fix GTP L2 length in checksum engine

Ronak Doshi (1):
  net/vmxnet3: fix drop of empty segments in Tx

Rongwei Liu (1):
  net/mlx5: fix duplicated tag index matching in SWS

Ruifeng Wang (4):
  test/malloc: fix missing free
  test/malloc: fix statistics checks
  net/mlx5: fix risk in NEON Rx descriptor read
  test/mbuf: fix crash in a forked process

Samina Arshad (1):
  examples/fips_validation: fix digest length in AES-GCM

Saoirse O'Donovan (2):
  test/crypto: fix return value for SNOW3G
  crypto/ipsec_mb: fix enqueue counter for SNOW3G

Satha Rao (1):
  net/cnxk: flush SQ before configuring MTU

Satheesh Paul (1):
  net/cnxk: fix flow queue index validation

Sean Zhang (1):
  net/mlx5: fix flow dump for modify field

Shijith Thotton (1):
  eventdev/timer: fix timeout event wait behavior

Shiyang He (4):
  net/iavf: release large VF when closing device
  net/ice: fix tunnel packet Tx descriptor
  net/i40e: fix tunnel packet Tx descriptor
  app/testpmd: fix checksum engine with GTP on 32-bit

Stephen Hemminger (1):
  net/netvsc: fix sizeof calculation

Suanming Mou (1):
  ethdev: fix indirect action conversion

Tejasree Kondoj (1):
  test/crypto: fix session creation check

Thierry Herbelot (1):
  doc: fix typo in cnxk platform guide

Thomas Monjalon (1):
  pci: fix comment referencing renamed function

Tianli Lai (1):
  net/dpaa2: fix checksum good flags

Viacheslav Ovsiienko (2):
  net/mlx5: fix device removal event handling
  ipc: fix file descriptor leakage with unhandled messages

Vikash Poddar (1):
  common/qat: detach crypto from compress build

Vladimir Medvedkin (3):
  fib: fix adding default route
  hash: fix reading unaligned bits in Toeplitz hash
  examples/ipsec-secgw: fix TAP default MAC address

Wenjing Qiao (3):
  net/ice: adjust timestamp mbuf register
  net/ice: fix timestamp enabling
  common/iavf: fix MAC type for 710 NIC

Wenjun Wu (3):
  net/i40e: fix Rx data buffer size
  net/ice: fix Rx data buffer size
  net/iavf: fix Rx data buffer size

Wenzhuo Lu (1):
  net/iavf: fix VLAN insertion in vector path

Xiao Liang (1):
  ipsec: fix NAT-T header length

Yiding Zhou (1):
  net/ice: fix 32-bit build

Yunjian Wang (2):
  ring: fix use after free
  net/txgbe: fix use-after-free on remove

Yuying Zhang (1):
  net/ice: fix RSS hash key generation

Zerun Fu (1):
  net/bonding: fix startup when NUMA is not supported

Zhichao Zeng (2):
  net/ice: fix outer UDP checksum offload
  net/iavf: fix stop ordering

Zhihong Wang (1):
  eal/linux: fix secondary process crash for mp hotplug requests

Re: 21.11.5 patches review and test

[Kevin Traynor]

On 24/08/2023 07:07, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, August 3, 2023 12:31 AM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ; Ali
Alnubani ; Walker, Benjamin
; David Christensen ;
Hemant Agrawal ; Stokes, Ian
; Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee ; Kevin
Traynor ; Luca Boccassi ; Pei Zhang
; Xu, Qian Q ; Raslan Darawsheh
; Thomas Monjalon ;
yangh...@redhat.com; Peng, Yuan ; Chen, Zhaoyan

Subject: 21.11.5 patches review and test

Hi all,

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

The planned date for the final release is 22nd August.

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

A release candidate tarball can be found at:

 https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.5-rc1

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

Thanks.

Kevin



Update the test status for Intel part. completed dpdk21.11.5-rc1 all 
validation. No new issue is found.

# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with latest GCC/Clang 
version and the popular OS revision such as
   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora38, RHEL8.4, RHEL9.2, FreeBSD13.1, 
SUSE15, CentOS7.9, etc.
   - All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc.
   - All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc.
   - All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package Management/Flow 
Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
   - All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios including PF/VF single 
core performance test, etc.
   - All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - 
QAT&SW/FIB library, etc.
   - All test done. No new dpdk issue is found.

# 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 8.0, etc.
   - All test done. No new dpdk issue is found.
* Cryptodev:
  *Function test: test scenarios including Cryptodev API testing/CompressDev 
ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
   - All test done. No new dpdk issue is found.
  *Performance test: test scenarios including Thoughput Performance/Cryptodev 
Latency, etc.
   - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin


Thank you for testing and report. Kevin.

Re: 21.11.5 patches review and test

[Kevin Traynor]

On 23/08/2023 10:55, Mcnamara, John wrote:




-Original Message-
From: Kevin Traynor 
Sent: Monday, August 21, 2023 1:38 PM
To: Mcnamara, John ; sta...@dpdk.org; Peng, Yuan
; Chen, Zhaoyan ; Xu, HailinX

Cc: dev@dpdk.org; Walker, Benjamin ; Stokes,
Ian ; Luca Boccassi ; Thomas
Monjalon 
Subject: Re: 21.11.5 patches review and test

On 21/08/2023 11:50, Mcnamara, John wrote:




-Original Message-
From: Kevin Traynor 

Any updates from Intel validation team ? The release is due tomorrow
(22nd) but I can postpone it if you need a few more days to complete
testing.


Hi,

We have had some attritions on the Intel validation team so some of the

co-ordination is behind schedule. Let me look into the current status.




ok, thanks John. No problem, I'll hold on the release and please let me
know when there is some news or an ETA.



Hi,

The testing is now ongoing and almost complete so we should have results in the 
next 1-2 days.

John



Great, thanks for the update John.

Re: 21.11.5 patches review and test

[Kevin Traynor]

On 21/08/2023 11:50, Mcnamara, John wrote:




-Original Message-
From: Kevin Traynor 

Any updates from Intel validation team ? The release is due tomorrow
(22nd) but I can postpone it if you need a few more days to complete
testing.


Hi,

We have had some attritions on the Intel validation team so some of the 
co-ordination is behind schedule. Let me look into the current status.



ok, thanks John. No problem, I'll hold on the release and please let me 
know when there is some news or an ETA.


thanks,
Kevin.


John

Re: 21.11.5 patches review and test

[Kevin Traynor]

On 02/08/2023 17:31, Kevin Traynor wrote:

Hi all,

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

The planned date for the final release is 22nd August.

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

A release candidate tarball can be found at:

 https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.5-rc1

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

Thanks.

Kevin



Hi,

Any updates from Intel validation team ? The release is due tomorrow 
(22nd) but I can postpone it if you need a few more days to complete 
testing.


thanks,
Kevin.

Re: 21.11.5 patches review and test

[Kevin Traynor]

On 17/08/2023 10:45, Ali Alnubani wrote:

-Original Message-
From: Kevin Traynor 
Sent: Wednesday, August 2, 2023 7:31 PM
To: sta...@dpdk.org
Cc: 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) ;
yangh...@redhat.com; yuan.p...@intel.com; zhaoyan.c...@intel.com
Subject: 21.11.5 patches review and test

Hi all,

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

The planned date for the final release is 22nd August.

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



Hello,

We ran the following functional tests with Nvidia hardware on 21.11.5-rc1:
- Basic functionality:
   Send and receive multiple types of traffic.
- testpmd xstats counter test.
- testpmd timestamp test.
- Changing/checking link status through testpmd.
- rte_flow tests.
- Some RSS tests.
- VLAN filtering, stripping and insertion tests.
- Checksum and TSO tests.
- ptype tests.
- link_status_interrupt example application tests.
- l3fwd-power example application tests.
- Multi-process example applications tests.
- Hardware LRO tests.
- Regex application tests.
- Buffer Split tests.
- Tx scheduling tests.

Functional tests ran on:
- NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-23.07-0.5.0.0 
/ Firmware: 22.38.1002
- NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-23.07-0.5.0.0 / 
Firmware: 28.38.1002
- DPU: BlueField-2 / DOCA SW version: 2.2.0 / Firmware: 24.38.1002


Build tests (all passed):
- Ubuntu 22.04.2 with MLNX_OFED_LINUX-23.07-0.5.0.0.
- Ubuntu 20.04.6 with MLNX_OFED_LINUX-23.04-1.1.3.0.
- Ubuntu 20.04.6 with rdma-core master (aba30bd).
- Ubuntu 20.04.6 with rdma-core v28.0.
- Ubuntu 18.04.6 with rdma-core master (aba30bd) (i386).
- Fedora 38 with rdma-core v44.0.
- Fedora 39 (Rawhide) with rdma-core v46.0.
- OpenSUSE Leap 15.5 with rdma-core v42.0.
- Windows Server 2019 with Clang 11.0.0.

We're investigating some internal test failures due to changes in environment, 
but we don't see new issues introduced by new changes in this rc yet, so we're 
ok to release.

Thanks,
Ali


Thanks for testing and report Ali. I will add to the release validation 
notes.


Kevin.

21.11.5 patches review and test

[Kevin Traynor]

Hi all,

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

The planned date for the final release is 22nd August.

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

A release candidate tarball can be found at:

https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.5-rc1

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

Thanks.

Kevin

---
Aakash Sasidharan (1):
  test/crypto: fix PDCP-SDAP test vectors

Akhil Goyal (1):
  doc: fix auth algos in cryptoperf app

Alexander Kozyrev (1):
  net/mlx5: forbid MPRQ restart

Ali Alnubani (1):
  doc: fix typos and wording in flow API guide

Artemii Morozov (1):
  common/sfc_efx/base: fix Rx queue without RSS hash prefix

Ashwin Sekhar T K (1):
  doc: fix typo in graph guide

Bing Zhao (2):
  net/mlx5: fix drop action memory leak
  net/mlx5: fix validation for conntrack indirect action

Boleslav Stankevich (2):
  net/virtio: propagate interrupt configuration error values
  net/virtio: fix initialization to return negative errno

Bruce Richardson (5):
  kernel/freebsd: fix function parameter list
  build: fix case of project language name
  telemetry: fix autotest on Alpine
  eal: avoid calling cleanup twice
  test/bonding: fix include of standard header

Chaoyong He (1):
  net/nfp: fix offloading flows

Chengwen Feng (4):
  net/hns3: fix Rx multiple firmware reset interrupts
  net/hns3: fix mbuf leakage when RxQ started during reset
  net/hns3: fix mbuf leakage when RxQ started after reset
  net/hns3: fix device start return value

Ciara Power (3):
  crypto/scheduler: fix last element for valid args
  crypto/ipsec_mb: optimize allocation in session
  app/crypto-perf: fix socket ID default value

Dariusz Sosnowski (1):
  net/mlx5: fix drop action attribute validation

David Christensen (1):
  net/tap: set locally administered bit for fixed MAC address

David Marchand (6):
  net/mlx5: enhance error log for tunnel offloading
  net/virtio-user: fix leak when initialisation fails
  examples/l2fwd-cat: fix external build
  test: add graph tests
  mbuf: fix Doxygen comment of distributor metadata
  ci: fix libabigail cache in GHA

Dengdui Huang (3):
  net/hns3: fix variable type mismatch
  net/hns3: fix inaccurate log
  net/hns3: fix redundant line break in log

Denis Pryazhennikov (3):
  ethdev: update documentation for API to set FEC
  ethdev: check that at least one FEC mode is specified
  ethdev: update documentation for API to get FEC

Devendra Singh Rawat (1):
  net/qede: fix RSS indirection table initialization

Didier Pallard (1):
  crypto/openssl: skip workaround at compilation time

Dongdong Liu (3):
  doc: fix kernel patch link in hns3 guide
  doc: fix syntax in hns3 guide
  doc: fix number of leading spaces in hns3 guide

Erez Ferber (1):
  common/mlx5: adjust fork call with new kernel API

Erik Gabriel Carrillo (1):
  eventdev/timer: fix buffer flush

Feifei Wang (1):
  ring: fix dequeue parameter name

Fengnan Chang (2):
  eal/linux: fix legacy mem init with many segments
  mem: fix memsegs exhausted message

Ferruh Yigit (2):
  kni: fix build with Linux 6.3
  kni: fix build with Linux 6.5

Gregory Etelson (1):
  net/mlx5: fix flow workspace destruction

Heng Jiang (1):
  net/mlx5: fix LRO TCP checksum

Hernan Vargas (2):
  baseband/fpga_5gnr_fec: fix possible division by zero
  baseband/fpga_5gnr_fec: fix starting unconfigured queue

Huisong Li (10):
  ethdev: fix MAC address occupies two entries
  net/hns3: fix never set MAC flow control
  net/hns3: fix RTC time on initialization
  net/hns3: fix RTC time after reset
  net/hns3: uninitialize PTP
  net/hns3: extract PTP to its own header file
  net/hns3: fix IMP reset trigger
  net/hns3: delete duplicate macro definition
  net/hns3: fix non-zero weight for disabled TC
  net/hns3: fix index to look up table in NEON Rx

Ivan Malov (2):
  net/sfc: stop misuse of Rx ingress m-port metadata on EF100
  net/sfc: invalidate dangling MAE flow action FW resource IDs

Jerin Jacob (4):
  examples/ip_pipeline: fix build with GCC 13
  examples/ntb: fix build with GCC 13
  net/hns3: fix build warning
  doc: remove warning with Doxygen 1.9.7

Jiawen Wu (6):
  net/txgbe/base: fix Tx with fiber hotplug
  net/txgbe: fix interrupt enable mask
  net/txgbe: fix to set autoneg for 1G speed
  net/txgbe: fix extended statistics
  net/ngbe: fix extended statistics
  net/ngbe: fix RSS offload capability

Jie Hai (5):
  net/hns3: fix FEC mode for 200G ports
  net/hns3: fix FEC mode check
  net/hns3: fix u

Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS

[Kevin Traynor]

On 25/07/2023 09:39, Ferruh Yigit wrote:

On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote:

To allow new cpu features to be added without ABI breakage,
RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release.

Signed-off-by: Sivaprasad Tummala 
---
  doc/guides/rel_notes/deprecation.rst | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 8e1cdd677a..92db59d9c2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -28,6 +28,9 @@ Deprecation Notices
the replacement API rte_thread_set_name and rte_thread_create_control being
marked as stable, and planned to be removed by the 23.11 release.
  
+* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This is

+  to allow new cpu features to be added without ABI breakage.
+
  * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does
not allow for writing optimized code for all the CPU architectures supported
in DPDK. DPDK has adopted the atomic operations from


+techboard,

Request for review/ack, patch is to remove ABI restriction to add new
CPU flags.



Acked-by: Kevin Traynor 

Re: [PATCH v3 2/2] vhost: force vIOMMU enablement with VDUSE

[Kevin Traynor]

On 13/07/2023 14:52, Maxime Coquelin wrote:

Unlike Vhost-user, VDUSE requires vIOMMU support.
This patch ignores whether RTE_VHOST_USER_IOMMU_SUPPORT
flag is passed at register time to avoid having application
to pass it for having working VDUSE device creation.

Fixes: 0adb8eccc6a6 ("vhost: add VDUSE device creation and destruction")

Signed-off-by: Maxime Coquelin
---
  lib/vhost/socket.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)


lgtm
Acked-by: Kevin Traynor 

Re: [PATCH v3 1/2] vhost: fix net offload compliance

[Kevin Traynor]

On 13/07/2023 14:52, Maxime Coquelin wrote:

Initial VDUSE support assumed the application always used
the net offload compliant mode, which is not the case for
OVS.

This patch propagates the value set by the application.

Fixes: 0adb8eccc6a6 ("vhost: add VDUSE device creation and destruction")

Signed-off-by: Maxime Coquelin 
---
  lib/vhost/socket.c | 2 +-
  lib/vhost/vduse.c  | 4 ++--
  lib/vhost/vduse.h  | 6 --
  3 files changed, 7 insertions(+), 5 deletions(-)



lgtm
Acked-by: Kevin Traynor 

Re: [PATCH v2 2/2] vhost: force vIOMMU enablement with VDUSE

[Kevin Traynor]

On 13/07/2023 12:29, Maxime Coquelin wrote:

Unlike Vhost-user, VDUSE requires vIOMMU support.
This patch ignores whether RTE_VHOST_USER_IOMMU_SUPPORT
flag is passed at register time to avoid having application
to pass it for having working VDUSE device creation.

Fixes: 0adb8eccc6a6 ("vhost: add VDUSE device creation and destruction")

Signed-off-by: Maxime Coquelin 
---
  lib/vhost/socket.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
index 57dfe3d2fe..79f2138f60 100644
--- a/lib/vhost/socket.c
+++ b/lib/vhost/socket.c
@@ -932,7 +932,10 @@ rte_vhost_driver_register(const char *path, uint64_t flags)
vsocket->async_copy = flags & RTE_VHOST_USER_ASYNC_COPY;
vsocket->net_compliant_ol_flags = flags & 
RTE_VHOST_USER_NET_COMPLIANT_OL_FLAGS;
vsocket->stats_enabled = flags & RTE_VHOST_USER_NET_STATS_ENABLE;
-   vsocket->iommu_support = flags & RTE_VHOST_USER_IOMMU_SUPPORT;
+   if (vsocket->is_vduse)
+   vsocket->iommu_support = true;
+   else
+   vsocket->iommu_support = flags & RTE_VHOST_USER_IOMMU_SUPPORT;
  
  	if (vsocket->async_copy &&

(flags & (RTE_VHOST_USER_IOMMU_SUPPORT |

 ^^^ do you need to update this check ?


@@ -986,7 +989,7 @@ rte_vhost_driver_register(const char *path, uint64_t flags)
vsocket->features &= ~seg_offload_features;
}
  
-	if (!(flags & RTE_VHOST_USER_IOMMU_SUPPORT)) {

+   if (!vsocket->iommu_support) {
vsocket->supported_features &= ~(1ULL << 
VIRTIO_F_IOMMU_PLATFORM);
vsocket->features &= ~(1ULL << VIRTIO_F_IOMMU_PLATFORM);
}

Re: [PATCH 1/2] test: add graph tests

[Kevin Traynor]

On 20/06/2023 12:52, David Marchand wrote:

On Tue, Jun 20, 2023 at 12:32 PM Kevin Traynor  wrote:


On 20/06/2023 07:56, David Marchand wrote:

On Tue, Jun 20, 2023 at 8:50 AM Jerin Jacob  wrote:


On Tue, Jun 20, 2023 at 2:17 AM David Marchand
 wrote:


We forgot to add graph unit tests to the CI testsuites.

Signed-off-by: David Marchand 


Could we add Fixes: ?
Either way,
Acked-by: Jerin Jacob 


Indeed.
I don't think the graph unit tests and code changed much, so it should
be ok to backport down to 20.11 and enable these ut in the CI.




Sounds ok to me to add "Fixes:" tag and backport. If they pass, great -
if they don't, the graph maintainers would need to spend time updating
the tests etc or we could just drop the patch.


Modulo some easy to fix conflict when backporting, the graph tests pass fine:
- 20.11:
2023-06-20T11:30:44.7171265Z 87/96 DPDK:fast-tests / graph_autotest
 OK   0.13 s
2023-06-20T11:30:44.7171724Z 88/96 DPDK:fast-tests / node_list_dump
 OK   0.13 s

- 21.11:
2023-06-20T11:32:37.2132951Z  90/101 DPDK:fast-tests / graph_autotest
   OK   0.17 s
2023-06-20T11:32:37.2133397Z  91/101 DPDK:fast-tests / node_list_dump
   OK   0.17 s

- 22.11:
2023-06-20T11:50:48.2519983Z  92/106 DPDK:fast-tests / graph_autotest
   OK   0.17 s
2023-06-20T11:50:48.2520344Z  93/106 DPDK:fast-tests / node_list_dump
   OK   0.17 s




Thanks David. In that case lgtm.

Re: [PATCH 1/2] test: add graph tests

[Kevin Traynor]

On 20/06/2023 07:56, David Marchand wrote:

On Tue, Jun 20, 2023 at 8:50 AM Jerin Jacob  wrote:


On Tue, Jun 20, 2023 at 2:17 AM David Marchand
 wrote:


We forgot to add graph unit tests to the CI testsuites.

Signed-off-by: David Marchand 


Could we add Fixes: ?
Either way,
Acked-by: Jerin Jacob 


Indeed.
I don't think the graph unit tests and code changed much, so it should
be ok to backport down to 20.11 and enable these ut in the CI.




Sounds ok to me to add "Fixes:" tag and backport. If they pass, great - 
if they don't, the graph maintainers would need to spend time updating 
the tests etc or we could just drop the patch.

Re: [PATCH v3] app/testpmd: expand noisy neighbour forward mode support

[Kevin Traynor]

On 26/05/2023 18:32, Mike Pattrick wrote:

On Fri, May 26, 2023 at 11:34 AM Kevin Traynor  wrote:


On 17/04/2023 19:55, Mike Pattrick wrote:

Previously the noisy neighbour vnf simulation would only operate in io
mode, forwarding packets as is. However, this limited the usefulness of
noisy neighbour simulation.

This feature has now been expanded to supporting mac, macswap, and
5tswap modes. To facilitate adding this support, some new header files
were added.



Hi Mike,

I think it makes sense to allow these functionalities to be combined. It
does seem like that noisy neighbour shouldn't have been added as a
standalone fowarding option in the first place, as it's not mutually
exclusive with the other fwding modes. Now it's forcing a user to set a
fwding mode within a fwding mode to combine the functionality :/

The approach is to allow the fwding modes to expose their forwarding
method so noisy can call them. Did you consider to expose the noisy
functionality and allow the other forwarding modes to call that when the
--noisy-* flags are set?


Personally I like this approach more, and that was the strategy I took
with the previous version. However, that change didn't seem popular at
the time.

http://patches.dpdk.org/project/dpdk/patch/20230126045516.176917-1-...@redhat.com/#157095



Ok, interesting, I hadn't realised that. It doesn't apply anymore since 
David has restructured the fowarding engines, but i applied to older 
code and took a look.


I had been thinking to an expose a function to do the noisy processing 
(if any) like a do_noise() and then to return the packets to the 
original fowarding engine for tx, similar to what is done the opposite 
way around in v3. I can understand Aman's concerns about tx of pkts 
moved from the fwding engines to noisy fwd engine.


I think we can summarize like this (will use macswp as example)
v3
- fwding engines expose their processing (e.g. do_macswp)
- user enables by setting --fwd=noisy and --noisy-fwd-mode=macswp
- noisy vnf does rx and tx
- noisy calls other fwding engine for other mode processing
- backwards compatible as existing noisy params have no effect when 
fwd!=noisy


v2
- noisy engine exposes a function for noise+tx
(e.g. noisy_eth_tx_burst())
- other fwd engines call this to add noise and tx
- user enables by setting --fwd=macswp and setting existing noisy params
- breaks backwards compatibility as previously noisy params would have 
no effect in macswp mode


It seems the ideal would be to have taken noisy as a feature, not a 
fwding engine but it's easy in hindsight. I'm not sure it's worth 
another big rework to try and add a do_noise() which may be a nice 
design but will break backwards compatability. So I'd probably vote for 
v3 design over v2.


What do others think ?


For example, a user sets fwding mode as normal 'fwd=macfwd' but then if
the user adds the --noisy-* params, the macfwd'ing mode calls some
functions exposed to add the noise, which seems a bit more intuitive.

Also, if someone adds a new fwding mode, they can just call the noisy
functions and don't have update noisy fwding mode to add the new mode.

I'm not sure if it's better, just throwing it out there as an
alternative idea.

On the downside, it would break backwards compatibility because
previously those --noisy-* params would have had no effect with say
macfwd mode, but now they will. So maybe that's enough to prohibit it.

In the past, I would have had all the params set and just changed
fwdmode to enable/disable noisy vnf. That would behaviour would now be
changed with this approach.

What do you think?

Few comments on the code below.

thanks,
Kevin.


Signed-off-by: Mike Pattrick 
---
v2: Reverted changes to random memory lookup
v3: Refactored entire patch
---
   app/test-pmd/5tswap.c | 118 +--
   app/test-pmd/5tswap.h | 130 ++
   app/test-pmd/macfwd.c |  33 +--
   app/test-pmd/macfwd.h |  46 +
   app/test-pmd/noisy_vnf.c  |  92 +++---
   app/test-pmd/parameters.c |  17 
   app/test-pmd/testpmd.c|   5 +
   app/test-pmd/testpmd.h|   8 ++
   doc/guides/testpmd_app_ug/run_app.rst |   9 ++
   9 files changed, 299 insertions(+), 159 deletions(-)
   create mode 100644 app/test-pmd/5tswap.h
   create mode 100644 app/test-pmd/macfwd.h

diff --git a/app/test-pmd/5tswap.c b/app/test-pmd/5tswap.c
index ff8c2dcde5..8e8de2557a 100644
--- a/app/test-pmd/5tswap.c
+++ b/app/test-pmd/5tswap.c
@@ -17,64 +17,8 @@
   #include 
   #include 

-#include "macswap_common.h"
   #include "testpmd.h"
-
-
-static inline void
-swap_mac(struct rte_ether_hdr *eth_hdr)
-{
- struct rte_ether_addr addr;
-
- /* Swap dest and src mac addresses. */
- rte_ether_addr_copy(ð_hdr->dst_

Re: [PATCH v3] app/testpmd: expand noisy neighbour forward mode support

[Kevin Traynor]

On 17/04/2023 19:55, Mike Pattrick wrote:

Previously the noisy neighbour vnf simulation would only operate in io
mode, forwarding packets as is. However, this limited the usefulness of
noisy neighbour simulation.

This feature has now been expanded to supporting mac, macswap, and
5tswap modes. To facilitate adding this support, some new header files
were added.



Hi Mike,

I think it makes sense to allow these functionalities to be combined. It 
does seem like that noisy neighbour shouldn't have been added as a 
standalone fowarding option in the first place, as it's not mutually 
exclusive with the other fwding modes. Now it's forcing a user to set a 
fwding mode within a fwding mode to combine the functionality :/


The approach is to allow the fwding modes to expose their forwarding 
method so noisy can call them. Did you consider to expose the noisy 
functionality and allow the other forwarding modes to call that when the 
--noisy-* flags are set?


For example, a user sets fwding mode as normal 'fwd=macfwd' but then if 
the user adds the --noisy-* params, the macfwd'ing mode calls some 
functions exposed to add the noise, which seems a bit more intuitive.


Also, if someone adds a new fwding mode, they can just call the noisy 
functions and don't have update noisy fwding mode to add the new mode.


I'm not sure if it's better, just throwing it out there as an 
alternative idea.


On the downside, it would break backwards compatibility because 
previously those --noisy-* params would have had no effect with say 
macfwd mode, but now they will. So maybe that's enough to prohibit it.


In the past, I would have had all the params set and just changed 
fwdmode to enable/disable noisy vnf. That would behaviour would now be 
changed with this approach.


What do you think?

Few comments on the code below.

thanks,
Kevin.


Signed-off-by: Mike Pattrick 
---
v2: Reverted changes to random memory lookup
v3: Refactored entire patch
---
  app/test-pmd/5tswap.c | 118 +--
  app/test-pmd/5tswap.h | 130 ++
  app/test-pmd/macfwd.c |  33 +--
  app/test-pmd/macfwd.h |  46 +
  app/test-pmd/noisy_vnf.c  |  92 +++---
  app/test-pmd/parameters.c |  17 
  app/test-pmd/testpmd.c|   5 +
  app/test-pmd/testpmd.h|   8 ++
  doc/guides/testpmd_app_ug/run_app.rst |   9 ++
  9 files changed, 299 insertions(+), 159 deletions(-)
  create mode 100644 app/test-pmd/5tswap.h
  create mode 100644 app/test-pmd/macfwd.h

diff --git a/app/test-pmd/5tswap.c b/app/test-pmd/5tswap.c
index ff8c2dcde5..8e8de2557a 100644
--- a/app/test-pmd/5tswap.c
+++ b/app/test-pmd/5tswap.c
@@ -17,64 +17,8 @@
  #include 
  #include 
  
-#include "macswap_common.h"

  #include "testpmd.h"
-
-
-static inline void
-swap_mac(struct rte_ether_hdr *eth_hdr)
-{
-   struct rte_ether_addr addr;
-
-   /* Swap dest and src mac addresses. */
-   rte_ether_addr_copy(ð_hdr->dst_addr, &addr);
-   rte_ether_addr_copy(ð_hdr->src_addr, ð_hdr->dst_addr);
-   rte_ether_addr_copy(&addr, ð_hdr->src_addr);
-}
-
-static inline void
-swap_ipv4(struct rte_ipv4_hdr *ipv4_hdr)
-{
-   rte_be32_t addr;
-
-   /* Swap dest and src ipv4 addresses. */
-   addr = ipv4_hdr->src_addr;
-   ipv4_hdr->src_addr = ipv4_hdr->dst_addr;
-   ipv4_hdr->dst_addr = addr;
-}
-
-static inline void
-swap_ipv6(struct rte_ipv6_hdr *ipv6_hdr)
-{
-   uint8_t addr[16];
-
-   /* Swap dest and src ipv6 addresses. */
-   memcpy(&addr, &ipv6_hdr->src_addr, 16);
-   memcpy(&ipv6_hdr->src_addr, &ipv6_hdr->dst_addr, 16);
-   memcpy(&ipv6_hdr->dst_addr, &addr, 16);
-}
-
-static inline void
-swap_tcp(struct rte_tcp_hdr *tcp_hdr)
-{
-   rte_be16_t port;
-
-   /* Swap dest and src tcp port. */
-   port = tcp_hdr->src_port;
-   tcp_hdr->src_port = tcp_hdr->dst_port;
-   tcp_hdr->dst_port = port;
-}
-
-static inline void
-swap_udp(struct rte_udp_hdr *udp_hdr)
-{
-   rte_be16_t port;
-
-   /* Swap dest and src udp port */
-   port = udp_hdr->src_port;
-   udp_hdr->src_port = udp_hdr->dst_port;
-   udp_hdr->dst_port = port;
-}
+#include "5tswap.h"
  
  /*

   * 5 tuple swap forwarding mode: Swap the source and the destination of layers
@@ -85,22 +29,7 @@ static bool
  pkt_burst_5tuple_swap(struct fwd_stream *fs)
  {
struct rte_mbuf  *pkts_burst[MAX_PKT_BURST];
-   struct rte_port  *txp;
-   struct rte_mbuf *mb;
-   uint16_t next_proto;
-   uint64_t ol_flags;
-   uint16_t proto;
uint16_t nb_rx;
-   int i;
-   union {
-   struct rte_ether_hdr *eth;
-   struct rte_vlan_hdr *vlan;
-   struct rte_ipv4_hdr *ipv4;
-   struct rte_ipv6_hdr *ipv6;
-   struct rte_tcp_hdr *tcp;
-   struct rte_udp_hdr *udp;
-   uint8_t *byte;
-   

DPDK 21.11.4 released

[Kevin Traynor]

ix Tx queue stats after queue stop and start

Kamalakshitha Aligeri (2):
  net/i40e: fix AVX512 fast-free path
  doc: fix LPM support in l3forward guide

Kevin Traynor (3):
  net/af_xdp: squash deprecated-declaration warnings
  version: 21.11.4-rc1
  version: 21.11.4

Krzysztof Karas (1):
  ethdev: fix build with LTO

Long Wu (1):
  net/nfp: fix getting RSS configuration

Maxime Coquelin (4):
  vhost: decrease log level for unimplemented requests
  vhost: fix possible FD leaks on truncation
  net/virtio-user: fix device starting failure handling
  vhost: fix possible FD leaks

Megha Ajmera (2):
  examples/qos_sched: fix debug mode
  sched: fix alignment of structs in subport

Michael Baum (6):
  compressdev: fix end of driver list
  app/compress-perf: fix some typos
  app/compress-perf: fix testing single operation
  compress/mlx5: fix decompress xform validation
  compress/mlx5: fix output Adler-32 checksum offset
  compress/mlx5: fix queue setup for partial transformations

Michal Schmidt (1):
  net/iavf: fix VLAN offload with AVX2

Mike Baucom (1):
  net/bnxt: fix Rx queue stats after queue stop and start

Mike Pattrick (1):
  net/iavf: add lock for VF commands

Mohammad Iqbal Ahmad (1):
  app/flow-perf: fix division or module by zero

Naga Harish K S V (1):
  eventdev/eth_tx: fix devices loop

Nithin Dabilpuram (1):
  common/cnxk: add memory clobber to steor and ldeor

Pavan Nikhilesh (2):
  event/cnxk: fix burst timer arm
  event/cnxk: fix timer operations in secondary process

Pavel Ivashchenko (1):
  test/mbuf: fix test with mbuf debug enabled

Peng Zhang (2):
  net/nfp: fix firmware name derived from PCI name
  net/nfp: fix MTU configuration order

Qiming Yang (1):
  net/i40e: reduce interrupt interval in multi-driver mode

Rahul Bhansali (1):
  event/cnxk: wait for CPT flow control on WQE path

Rakesh Kudurumalla (1):
  net/cnxk: fix LBK BPID usage

Saoirse O'Donovan (1):
  test/crypto: fix statistics error messages

Satheesh Paul (1):
  common/cnxk: fix dual VLAN parsing

Shiyang He (2):
  net/ixgbe: fix firmware version consistency
  app/testpmd: fix secondary process packet forwarding

Stephen Hemminger (2):
  cmdline: make rdline status not private
  cmdline: handle EOF as quit

Steve Yang (2):
  net/i40e: fix validation of flow transfer attribute
  net/ice: fix validation of flow transfer attribute

Thomas Monjalon (8):
  doc: fix dependency setup in l2fwd-cat example guide
  devtools: fix escaped space in grep pattern
  doc: fix description of L2TPV2 flow item
  build: fix dependencies lookup
  eal/windows: fix pedantic build
  doc: add gpudev to the Doxygen index
  net/mlx5: fix Windows build with MinGW GCC 12
  build: detect backtrace availability

Venkat Duvvuru (1):
  net/bnxt: fix RSS hash in mbuf

Vikash Poddar (1):
  test/crypto: fix typo in AES test

Visa Hankala (1):
  net/e1000: fix saving of stripped VLAN TCI

Volodymyr Fialko (5):
  test/crypto: add missing MAC-I to PDCP vectors
  reorder: invalidate buffer from ready queue in drain
  test/reorder: fix double free of drained buffers
  event/cnxk: fix SSO cleanup
  reorder: fix sequence number mbuf field register

Wei Huang (3):
  bus/ifpga: fix devargs handling
  net/ipn3ke: fix thread exit
  net/ipn3ke: fix representor name

Wenjing Qiao (1):
  net/i40e: fix MAC loopback on X722

Wenwu Ma (1):
  vhost: fix net header settings in datapath

Yangchao Zhou (1):
  kni: fix possible starvation when mbufs are exhausted

Yogesh Jangra (1):
  table: fix action selector group size log2 setting

Zhichao Zeng (2):
  net/iavf: fix building data desc
  net/iavf: fix device stop during reset

Zhuobin Huang (1):
  test: fix segment length in packet generator

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 11/05/2023 08:33, Jiang, YuX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Monday, May 8, 2023 11:24 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu, Qian Q
; Thomas Monjalon ; Peng,
Yuan ; Chen, Zhaoyan ;
dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 05/05/2023 02:42, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, May 4, 2023 6:11 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu,

Qian

Q ; Thomas Monjalon ;

Peng,

Yuan ; Chen, Zhaoyan

;

dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 04/05/2023 03:13, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Tuesday, May 2, 2023 5:35 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu,
Qian Q ; Thomas Monjalon
;

Peng,

Yuan ; Chen, Zhaoyan

;

dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 20/04/2023 11:32, Kevin Traynor wrote:

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe

;

Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John

;

Ju-Hyoung Lee ; Luca Boccassi
; Pei Zhang ; Xu, Qian

Q

; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng,

Yuan

; Chen, Zhaoyan



Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe
; Ali Alnubani
; Walker, Benjamin
; David Christensen
; Hemant Agrawal
; Stokes, Ian

;

Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee

;

Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu,

Qian Q

; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng,

Yuan

; Chen, Zhaoyan



Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1
validation test rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
   1.



pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:

performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
   2. some of the virtio tests are failing:-- Intel dev is under

investigating

# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with
latest GCC/Clang version and the popular OS revision such as
   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6,
RHEL8.4, FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN,

etc.

- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced

RSS/ACL/DCF/Flexible

Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios
including PF/VF single core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library
basic test - QAT&SW/FIB library, etc.
- On going.

# 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 8.0, etc.
- All test done. found bug1.
* Cryptodev:
   *Function test: test scenarios including Cryptodev API
testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
 - Execution rate is 90%. found bug2.
   *Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
 - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1
all

validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 05/05/2023 02:42, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, May 4, 2023 6:11 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu, Qian Q
; Thomas Monjalon ; Peng,
Yuan ; Chen, Zhaoyan ;
dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 04/05/2023 03:13, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Tuesday, May 2, 2023 5:35 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu, Qian
Q ; Thomas Monjalon ;

Peng,

Yuan ; Chen, Zhaoyan ;
dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 20/04/2023 11:32, Kevin Traynor wrote:

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe

;

Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John ;
Ju-Hyoung Lee ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe
; Ali Alnubani
; Walker, Benjamin
; David Christensen
; Hemant Agrawal
; Stokes, Ian ;
Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee

;

Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1
validation test rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
  1.

pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:

performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
  2. some of the virtio tests are failing:-- Intel dev is under

investigating

# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with
latest GCC/Clang version and the popular OS revision such as
  Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6,
RHEL8.4, FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced

RSS/ACL/DCF/Flexible

Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios including
PF/VF single core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library
basic test - QAT&SW/FIB library, etc.
- On going.

# 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 8.0, etc.
- All test done. found bug1.
* Cryptodev:
  *Function test: test scenarios including Cryptodev API
testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
- Execution rate is 90%. found bug2.
  *Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
- All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1
all

validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: --20.11.8-rc1 also has these two issues
  1.

pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
performance drop about 23.5% when send small packets

https://bugs.dpdk.org/show_bug.cgi?id=1212  --not fix yet, Only
the specified platform exists


Do you know which patch caaused the regression? I'm not fully clear
fr

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 04/05/2023 03:13, Xu, HailinX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Tuesday, May 2, 2023 5:35 PM
To: Xu, HailinX ; sta...@dpdk.org
Cc: Stokes, Ian ; Mcnamara, John
; Luca Boccassi ; Xu, Qian Q
; Thomas Monjalon ; Peng,
Yuan ; Chen, Zhaoyan ;
dev@dpdk.org
Subject: Re: 21.11.4 patches review and test

On 20/04/2023 11:32, Kevin Traynor wrote:

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe

;

Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal

;

Stokes, Ian ; Jerin Jacob
; Mcnamara, John ;
Ju-Hyoung Lee ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe
; Ali Alnubani
; Walker, Benjamin ;
David Christensen ; Hemant Agrawal
; Stokes, Ian ; Jerin
Jacob ; Mcnamara, John
; Ju-Hyoung Lee ;
Kevin Traynor ; Luca Boccassi
; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1
validation test rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
 1.

pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:

performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
 2. some of the virtio tests are failing:-- Intel dev is under

investigating

# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with
latest GCC/Clang version and the popular OS revision such as
 Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4,
FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios including
PF/VF single core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic
test - QAT&SW/FIB library, etc.
- On going.

# 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 8.0, etc.
- All test done. found bug1.
* Cryptodev:
 *Function test: test scenarios including Cryptodev API
testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
   - Execution rate is 90%. found bug2.
 *Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
   - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1 all

validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: --20.11.8-rc1 also has these two issues
 1.

pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
performance drop about 23.5% when send small packets

https://bugs.dpdk.org/show_bug.cgi?id=1212  --not fix yet, Only the
specified platform exists


Do you know which patch caaused the regression? I'm not fully clear
from the Bz for 20.11. The backported patch ID'd as root cause [0] in
20.11 is in the previous releases of 20.11 (and 21.11).

Trying to understand because then it would have shown in testing for
previous releases. Or is this a new test introduced for latest LTS
releases? and if so, what is the baseline performance bas

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 20/04/2023 11:32, Kevin Traynor wrote:

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Ali Alnubani ; Walker, Benjamin
; David Christensen ;
Hemant Agrawal ; Stokes, Ian
; Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee ; Luca
Boccassi ; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ; Thomas
Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal ;
Stokes, Ian ; Jerin Jacob ;
Mcnamara, John ; Ju-Hyoung Lee
; Kevin Traynor ; Luca
Boccassi ; Pei Zhang ; Xu, Qian
Q ; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1 validation test
rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
2. some of the virtio tests are failing:-- Intel dev is under 
investigating
# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with latest
GCC/Clang version and the popular OS revision such as
Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4,
FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios including PF/VF single
core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test -
QAT&SW/FIB library, etc.
- On going.

# 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 8.0, etc.
- All test done. found bug1.
* Cryptodev:
*Function test: test scenarios including Cryptodev API testing/CompressDev
ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
  - Execution rate is 90%. found bug2.
*Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
  - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1 all 
validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: --20.11.8-rc1 also has these two issues
1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac: 
performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212  --not fix yet, Only the 
specified platform exists


Do you know which patch caaused the regression? I'm not fully clear from
the Bz for 20.11. The backported patch ID'd as root cause [0] in 20.11
is in the previous releases of 20.11 (and 21.11).

Trying to understand because then it would have shown in testing for
previous releases. Or is this a new test introduced for latest LTS
releases? and if so, what is the baseline performance based on?

[0]
commit 1c9a7fba5c90e0422b517404499ed106f647bcff
Author: Mattias Rönnblom 
Date:   Mon Jul 11 14:11:32 2022 +0200

  net: accept unaligned data in checksum routines


2. some of the virtio tests are failing: -- Intel dev is under investigating


ok, thank you.



Hi, it was mentioned in a separate mail that the performance drop issue 
was not the s

Re: [PATCH v2] crypto/ipsec_mb: enqueue counter fix

[Kevin Traynor]

On 20/04/2023 11:31, Saoirse O'Donovan wrote:

This patch removes enqueue op counter update from the process_op_bit
function where the process is now done in dequeue stage. The original
stats increment was incorrect as they shouldn't have been updated at all
in this function.

Fixes: 4f1cfda59ad3 ("crypto/ipsec_mb: move snow3g PMD")
Cc: piotrx.bronow...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Saoirse O'Donovan 

---
v2: Added cc stable for 21.11 and 22.11 backport.

A similar fix has been sent to 20.11 LTS stable, in the interest of
time. In that fix, the enqueued stat is still in use, therefore only the
fix to the count increment was necessary.



Thanks for the explanation. As it has the correct tags, we will pick 
this up for 21.11 and 22.11 LTS releases in the normal workflow, which 
is after it has been released as part of a DPDK main branch release.


thanks,
Kevin.


Here is the mail archive link:
https://mails.dpdk.org/archives/stable/2023-April/043550.html
---
  drivers/crypto/ipsec_mb/pmd_snow3g.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_snow3g.c 
b/drivers/crypto/ipsec_mb/pmd_snow3g.c
index 8ed069f428..e64df1a462 100644
--- a/drivers/crypto/ipsec_mb/pmd_snow3g.c
+++ b/drivers/crypto/ipsec_mb/pmd_snow3g.c
@@ -372,9 +372,10 @@ process_ops(struct rte_crypto_op **ops, struct 
snow3g_session *session,
  /** Process a crypto op with length/offset in bits. */
  static int
  process_op_bit(struct rte_crypto_op *op, struct snow3g_session *session,
-   struct ipsec_mb_qp *qp, uint16_t *accumulated_enqueued_ops)
+   struct ipsec_mb_qp *qp)
  {
-   uint32_t enqueued_op, processed_op;
+   unsigned int processed_op;
+   int ret;
  
  	switch (session->op) {

case IPSEC_MB_OP_ENCRYPT_ONLY:
@@ -421,9 +422,10 @@ process_op_bit(struct rte_crypto_op *op, struct 
snow3g_session *session,
  
  	if (unlikely(processed_op != 1))

return 0;
-   enqueued_op = rte_ring_enqueue(qp->ingress_queue, op);
-   qp->stats.enqueued_count += enqueued_op;
-   *accumulated_enqueued_ops += enqueued_op;
+
+   ret = rte_ring_enqueue(qp->ingress_queue, op);
+   if (ret != 0)
+   return ret;
  
  	return 1;

  }
@@ -439,7 +441,6 @@ snow3g_pmd_dequeue_burst(void *queue_pair,
struct snow3g_session *prev_sess = NULL, *curr_sess = NULL;
uint32_t i;
uint8_t burst_size = 0;
-   uint16_t enqueued_ops = 0;
uint8_t processed_ops;
uint32_t nb_dequeued;
  
@@ -479,8 +480,7 @@ snow3g_pmd_dequeue_burst(void *queue_pair,

prev_sess = NULL;
}
  
-			processed_ops = process_op_bit(curr_c_op, curr_sess,

-   qp, &enqueued_ops);
+   processed_ops = process_op_bit(curr_c_op, curr_sess, 
qp);
if (processed_ops != 1)
break;
  

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 20/04/2023 03:40, Xu, HailinX wrote:

-Original Message-
From: Xu, HailinX 
Sent: Thursday, April 13, 2023 2:13 PM
To: Kevin Traynor ; sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Ali Alnubani ; Walker, Benjamin
; David Christensen ;
Hemant Agrawal ; Stokes, Ian
; Jerin Jacob ; Mcnamara, John
; Ju-Hyoung Lee ; Luca
Boccassi ; Pei Zhang ; Xu, Qian Q
; Raslan Darawsheh ; Thomas
Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: RE: 21.11.4 patches review and test


-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 7:38 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Ali Alnubani ; Walker, Benjamin
; David Christensen
; Hemant Agrawal ;
Stokes, Ian ; Jerin Jacob ;
Mcnamara, John ; Ju-Hyoung Lee
; Kevin Traynor ; Luca
Boccassi ; Pei Zhang ; Xu, Qian
Q ; Raslan Darawsheh ;

Thomas

Monjalon ; yangh...@redhat.com; Peng, Yuan
; Chen, Zhaoyan 
Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin


HI All,

Update the test status for Intel part. Till now dpdk21.11.4-rc1 validation test
rate is 85%. No critical issue is found.
2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs:   --20.11.8-rc1 also has these two issues
   1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac:
performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212-- no fix yet
   2. some of the virtio tests are failing:-- Intel dev is under 
investigating
# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with latest
GCC/Clang version and the popular OS revision such as
   Ubuntu20.04, Ubuntu22.04, Fedora35, Fedora37, RHEL8.6, RHEL8.4,
FreeBSD13.1, SUSE15, CentOS7.9, etc.
- All test done. No new dpdk issue is found.
* PF(i40e, ixgbe): test scenarios including
RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* VF(i40e, ixgbe): test scenarios including
VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- All test done. No new dpdk issue is found.
* PF/VF(ice): test scenarios including Switch features/Package
Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
Descriptor, etc.
- All test done. No new dpdk issue is found.
* Intel NIC single core/NIC performance: test scenarios including PF/VF single
core performance test, etc.
- All test done. No new dpdk issue is found.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test -
QAT&SW/FIB library, etc.
- On going.

# 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 8.0, etc.
- All test done. found bug1.
* Cryptodev:
   *Function test: test scenarios including Cryptodev API testing/CompressDev
ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
 - Execution rate is 90%. found bug2.
   *Performance test: test scenarios including Thoughput
Performance/Cryptodev Latency, etc.
 - All test done. No new dpdk issue is found.

Regards,
Xu, Hailin

Update the test status for Intel part. completed dpdk21.11.4-rc1 all 
validation. No critical issue is found.


Hi. Thanks for testing.


2 new bugs are found, 1 new issue is under confirming by Intel Dev.
New bugs: --20.11.8-rc1 also has these two issues
   1. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac: 
performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212  --not fix yet, Only the 
specified platform exists


Do you know which patch caaused the regression? I'm not fully clear from 
the Bz for 20.11. The backported patch ID'd as root cause [0] in 20.11 
is in the previous releases of 20.11 (and 21.11).


Trying to understand because then it would have shown in testing for 
previous releases. Or is this a new test introduced for latest LTS 
releases? and if so, what is the baseline performance based on?


[0]
commit 1c9a7fba5c90e0422b517404499ed106f647bcff
Author: Mattias Rönnblom 
Date:   Mon Jul 11 14:11:32 2022 +0200

net: accept unaligned data in checksum routines


   2. some of the virtio tests are failing: -- Intel dev is under investigating


ok, thank you.

Kevin.


# Basic Intel(R) NIC testing
* Build & CFLAG compile: cover the build test combination with latest GCC/Clang 
version and the po

Re: [dpdk-web] [RFC PATCH] process: new library approval in principle

[Kevin Traynor]

On 13/02/2023 09:26, jer...@marvell.com wrote:

From: Jerin Jacob 

Based on TB meeting[1] action item, defining
the process for new library approval in principle.

[1]
https://mails.dpdk.org/archives/dev/2023-January/260035.html

Signed-off-by: Jerin Jacob 
---
  content/process/_index.md | 33 +
  1 file changed, 33 insertions(+)
  create mode 100644 content/process/_index.md

diff --git a/content/process/_index.md b/content/process/_index.md
new file mode 100644
index 000..21c2642
--- /dev/null
+++ b/content/process/_index.md
@@ -0,0 +1,33 @@

+title = "Process"
+weight = "9"

+
+## Process for new library approval in principle
+
+### Rational
+
+Adding a new library to DPDK codebase with proper RFC and then full patch-sets 
is
+significant work and getting early approval-in-principle that a library help 
DPDK contributors
+avoid wasted effort if it is not suitable for various reasons.
+
+### Process
+
+1. When a contributor would like to add a new library to DPDK code base, the 
contributor must send
+the following items to DPDK mailing list for TB approval-in-principle.
+
+   - Purpose of the library.
+   - Scope of the library.
+   - Any licensing constraints.
+   - Justification for adding to DPDK.
+   - Any other implementations of the same functionality in other 
libs/products and how this version differs.


- Dependencies

(Need to know if it's introducing new dependencies to the project)


+   - Public API specification header file as RFC
+   - Optional and good to have.
+   - TB may additionally request this collateral if needed to get more 
clarity on scope and purpose.
+
+2. TB to schedule discussion on this in upcoming TB meeting along with author. 
Based on the TB
+schedule and/or author availability, TB may need maximum three TB meeting 
slots.
+
+3. Based on mailing list and TB meeting discussions, TB to vote for 
approval-in-principle and share
+the decision in the mailing list.
+


How about having three outcomes:
- Approval in principal
- Not approved
- Further information needed

Re: 20.11.8 patches review and test

[Kevin Traynor]

On 19/04/2023 15:23, Ali Alnubani wrote:

-Original Message-
From: Luca Boccassi 
Sent: Wednesday, April 19, 2023 5:15 PM
To: David Marchand 
Cc: Ali Alnubani ; sta...@dpdk.org; dev@dpdk.org;
Abhishek Marathe ;
benjamin.wal...@intel.com; David Christensen ;
Hemant Agrawal ; Ian Stokes
; Jerin Jacob ; John McNamara
; Ju-Hyoung Lee ;
Kevin Traynor ; Pei Zhang ;
qian.q...@intel.com; Raslan Darawsheh ; NBU-
Contact-Thomas Monjalon (EXTERNAL) ; Yanghang
Liu ; yuan.p...@intel.com;
zhaoyan.c...@intel.com
Subject: Re: 20.11.8 patches review and test

On Wed, 19 Apr 2023 at 14:25, David Marchand
 wrote:


On Wed, Apr 19, 2023 at 3:14 PM Ali Alnubani  wrote:


I don't think this function prototype is really different in the 20.11
stable branch (putting the __rte_internal tag aside).
Can you trigger this issue on the main branch?



The main branch doesn't reproduce on the same environment.


Ok, same for me, I reproduced for 20.11 but not for main.


I think I have the reason.
We filter headers to be processed by doxygen via a name filter:

FILE_PATTERNS   = rte_*.h \

But this rte_cryptodev_pmd.h driver header has been renamed as
cryptodev_pmd.h in 21.11.
So the issue you reported only affects 20.11.


I can reproduce in debian testing, after backporting the mentioned
commit from main it seems fine, can you confirm as well that it works
in fedora?

https://github.com/bluca/dpdk-
stable/commit/77f65b61f955fd817b3791049dda3032c459ac59


Now I see a different error:

[2/4] Generating doc/api/doxygen with a custom command
FAILED: doc/api/html
/tmp/dpdk/doc/api/generate_doxygen.sh doc/api/doxy-api.conf doc/api/html 
/tmp/dpdk/doc/api/doxy-html-custom.sh
/tmp/dpdk/lib/librte_vhost/rte_vhost_async.h:49: error: 
rte_vhost_async_channel_ops::transfer_data has @param documentation sections 
but no arguments (warning treated as error, aborting now)


See 
https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=adeaf361f0a5bb3992756fd4e727dd11ecca0943

Re: 21.11.4 patches review and test

[Kevin Traynor]

On 19/04/2023 14:24, Ali Alnubani wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, April 6, 2023 2:38 PM
To: sta...@dpdk.org
Cc: 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)
; yangh...@redhat.com; yuan.p...@intel.com;
zhaoyan.c...@intel.com
Subject: 21.11.4 patches review and test

Hi all,

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

The planned date for the final release is 25th April.

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.4-rc1

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

Thanks.

Kevin

---


We ran the following functional tests with Nvidia hardware on 21.11.4-rc1:
- Basic functionality:
   Send and receive multiple types of traffic.
- testpmd xstats counter test.
- testpmd timestamp test.
- Changing/checking link status through testpmd.
- rte_flow tests.
- Some RSS tests.
- VLAN filtering, stripping and insertion tests.
- Checksum and TSO tests.
- ptype tests.
- link_status_interrupt example application tests.
- l3fwd-power example application tests.
- Multi-process example applications tests.
- Hardware LRO tests.
- Regex application tests.
- Buffer Split tests.
- Tx scheduling tests.

Functional tests ran on:
- NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 / 
Firmware: 22.36.1010
- DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000

Additionally, we ran compilation tests with multiple configurations in the 
following OS/driver combinations:
- Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- Ubuntu 20.04.5 with rdma-core master (f0a079f).
- Ubuntu 20.04.5 with rdma-core v28.0.
- Ubuntu 18.04.6 with rdma-core v17.1.
- Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386).
- Fedora 37 with rdma-core v41.0.
- Fedora 39 (Rawhide) with rdma-core v44.0.
- CentOS 7 7.9.2009 with rdma-core master (f0a079f).
- CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0.
- CentOS 8 8.4.2105 with rdma-core master (f0a079f).
- OpenSUSE Leap 15.4 with rdma-core v38.1.
- Windows Server 2019 with Clang 11.0.0.

We don't see new issues caused by the changes in this release.



Great, thanks for testing and reporting Ali.
Kevin.


Please note that not all the functional tests mentioned above fall under "Basic 
functionality with testpmd" like reported in the release notes for previous releases:
https://git.dpdk.org/dpdk-stable/commit/?h=v21.11.3&id=31608e4db56893c896375288671b5ee38723a211
Some of them test other applications.

Thanks,
Ali

21.11.4 patches review and test

[Kevin Traynor]

halli (1):
  eal: use same atomic intrinsics for GCC and clang

Huisong Li (39):
  net/hns3: fix inaccurate RTC time to read
  telemetry: move include after guard
  ethdev: fix telemetry data truncation
  mempool: fix telemetry data truncation
  cryptodev: fix telemetry data truncation
  mem: fix telemetry data truncation
  net/hns3: fix log about indirection table size
  net/hns3: extract common function to query device
  net/hns3: refactor set RSS hash algorithm and key interface
  net/hns3: fix clearing RSS configuration
  net/hns3: use RSS filter list to check duplicated rule
  net/hns3: remove useless code when destroy valid RSS rule
  net/hns3: fix warning on flush or destroy rule
  net/hns3: fix config struct used for conversion
  net/hns3: fix duplicate RSS rule check
  net/hns3: add debug info for Rx/Tx dummy function
  net/hns3: remove debug condition for Tx prepare
  mem: fix heap ID in telemetry
  net/hns3: fix possible truncation of hash key when config
  net/hns3: fix possible truncation of redirection table
  net/hns3: use hardware config to report redirection table
  net/hns3: separate setting redirection table
  net/hns3: separate setting and clearing RSS rule
  net/hns3: separate Tx prepare from getting Tx function
  net/hns3: make getting Tx function static
  net/hns3: fix RSS key size compatibility
  net/hns3: fix burst mode query with dummy function
  net/hns3: extract common functions to set Rx/Tx
  net/hns3: use hardware config to report hash key
  net/hns3: use hardware config to report hash types
  net/hns3: separate setting hash algorithm
  net/hns3: separate setting hash key
  net/hns3: separate setting RSS types
  net/hns3: use new RSS rule to configure hardware
  net/hns3: save hash algo to RSS filter list node
  net/hns3: allow adding queue buffer size hash rule
  net/hns3: separate flow RSS config from RSS conf
  net/hns3: reimplement hash flow function
  net/hns3: add verification of RSS types

Ivan Malov (6):
  net/sfc: export pick transfer proxy callback to representors
  net/sfc: fix MAC address entry leak in transfer flow parsing
  net/sfc: enforce fate action in transfer flow rules
  common/sfc_efx/base: add MAE mark reset action
  net/sfc: fix resetting mark in tunnel offload switch rules
  net/sfc: invalidate switch port entry on representor unplug

Jiawei Wang (1):
  net/mlx5: fix flow sample with ConnectX-5

Jiawen Wu (5):
  net/txgbe: fix default signal quality value for KX/KX4
  net/txgbe: fix packet type to parse from offload flags
  net/ngbe: fix packet type to parse from offload flags
  net/txgbe: fix interrupt loss
  net/txgbe: fix Rx buffer size in config register

Jie Hai (1):
  test/mbuf: fix mbuf reset test

Joyce Kong (1):
  pdump: fix build with GCC 12

Kaiwen Deng (2):
  net/ixgbe: enable IPv6 mask in flow rules
  net/ixgbe: fix IPv6 mask in flow director

Kalesh AP (1):
  net/bnxt: fix Tx queue stats after queue stop and start

Kamalakshitha Aligeri (2):
  net/i40e: fix AVX512 fast-free path
  doc: fix LPM support in l3forward guide

Kevin Traynor (1):
  net/af_xdp: squash deprecated-declaration warnings

Krzysztof Karas (1):
  ethdev: fix build with LTO

Long Wu (1):
  net/nfp: fix getting RSS configuration

Maxime Coquelin (4):
  vhost: decrease log level for unimplemented requests
  vhost: fix possible FD leaks on truncation
  net/virtio-user: fix device starting failure handling
  vhost: fix possible FD leaks

Megha Ajmera (2):
  examples/qos_sched: fix debug mode
  sched: fix alignment of structs in subport

Michael Baum (6):
  compressdev: fix end of driver list
  app/compress-perf: fix some typos
  app/compress-perf: fix testing single operation
  compress/mlx5: fix decompress xform validation
  compress/mlx5: fix output Adler-32 checksum offset
  compress/mlx5: fix queue setup for partial transformations

Michal Schmidt (1):
  net/iavf: fix VLAN offload with AVX2

Mike Baucom (1):
  net/bnxt: fix Rx queue stats after queue stop and start

Mike Pattrick (1):
  net/iavf: add lock for VF commands

Mohammad Iqbal Ahmad (1):
  app/flow-perf: fix division or module by zero

Naga Harish K S V (1):
  eventdev/eth_tx: fix devices loop

Nithin Dabilpuram (1):
  common/cnxk: add memory clobber to steor and ldeor

Pavan Nikhilesh (2):
  event/cnxk: fix burst timer arm
  event/cnxk: fix timer operations in secondary process

Pavel Ivashchenko (1):
  test/mbuf: fix test with mbuf debug enabled

Peng Zhang (2):
  net/nfp: fix firmware name derived from PCI name
  net/nfp: fix MTU configuration order

Qiming Yang (1):
  net/i40e: reduce interrupt interval in multi-driver mode

Rahul Bhansali (1):
  event/cnxk: wait fo

Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Kevin Traynor]

On 21/12/2022 09:28, Kevin Traynor wrote:

On 21/12/2022 06:09, Andrew Rybchenko wrote:

Hi Kevin,

On 12/20/22 17:05, Kevin Traynor wrote:

On 24/06/2022 11:23, Ciara Loftus wrote:

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if
so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 


Hi Andrew/Qi (assuming Ciara is still out of office),

I am seeing a similar issue [1] on 21.11 branch with Fedora 37
(libbpf-0.8.0-2.fc37.x86_64 and libxdp-1.2.6-1.fc37.x86_64).

This patch alone won't apply as there are other dependencies. Looking at
the commits in main branch, it seems like I could take all these [2] to
resolve the issue. With these cherry-picked the build warnings on Fedora
37 are removed.

It's a bit late to take these for DPDK 21.11.3 as I intend to release
later today/tomorrow, so it can be resolved for DPDK 21.11.4.

Do the commits below look ok for backport? Main branch might be able to
demand user uses new libbpf/libxdp versions etc, but with stable we
never want to break the users existing setup when they upgrade from
2X.11.n to 2X.11.n+1.

Let me know what you think?


IMO these patches are to to be backported to stable branch.


Thanks Andrew.


However, af_xdp maintainers opinion is more important here.



Qi, what do you think?



As F37 will be the oldest supported Fedora release from mid-May and 
there is no available af_xdp maintainers to comment on backports, I'm 
going to just squash the warnings [0] for 21.11.4.


If a better fix is available for 21.11.5+ please send patches to stable ML.

thanks,
Kevin.

[0] 
http://inbox.dpdk.org/stable/20230404153501.123038-1-ktray...@redhat.com/




thanks,
Kevin.

[1] https://paste.centos.org/view/e4eec764
[2]
1eb1846b1a net/af_xdp: make compatible with libbpf 0.8.0
5ff3dbe6ce net/af_xdp: add log on XDP program removal failures
0ed0bc3834 net/af_xdp: avoid version-based check for program load
e024c7e838 net/af_xdp: avoid version-based check for shared UMEM
f76dc44ded net/af_xdp: make clear which libxdp version is required
50b855fc47 net/af_xdp: move XDP library presence flag setting

Minutes of Technical Board Meeting, 2023-March-22

[Kevin Traynor]

Minutes of Technical Board Meeting, 2023-March-22

Members Attending
-
-Aaron
-Bruce
-Hemant
-Jerin
-Kevin (Chair)
-Maxime
-Stephen
-Thomas

NOTE: The technical board meetings every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.

NOTE: Next meeting will be on Wednesday 2023-April-05 @3pm UTC, and will
be chaired by Konstantin.

1) Marketing update (Nathan)
-We need to provide content to maximise the marketing resources
-A good example is Morten's content on using DPDK
https://www.dpdk.org/wp-content/uploads/sites/35/2023/02/DPDK_UserStory_SmartShare_020223.pdf

2) Event planning (Nathan)
-Dublin in September is most likely venue
-Difficult to estimate in-person attendance based on previous years and
economic environment
-Nathan will send out a survey to try and gauge interest for in-person
attendance

3) Technical Writer (Nathan)
-The hiring interviews are currently in progress.

4) Policy for obsolete patches (Bruce)
-A lot of pages in patchwork, should older patches be moved to a new
obsolete state?
-Adding a new state would cause difficulties for patchwork upgrade
-Reject state could be used
-A script to do automatically and send an email with links etc would be best
-Ali may be able to investigate a way to automate this

5) Code formatting tools (Bruce)
-Any way to better automate formatting of code?
-clang-format was suggested and already being used by some
-Stephen has been looking at this, he will send a patch to kick off

6) Multiple MAC address support and API behavior were discussed (Ferruh)
-Pros and cons to each approach
-Ferruh will propose solution for vote on email by techboard

7) Bugzilla usage (breakout from previous topic)
-Is it being used enough? Are bugs getting the right level of attention etc?
-Konstantin to add this as a topic for next techboard meeting

Re: [PATCH v6] net/i40e: rework maximum frame size configuration

[Kevin Traynor]

On 24/03/2023 06:32, Jiang, YuX wrote:

-Original Message-
From: Kevin Traynor 
Sent: Thursday, March 23, 2023 10:51 PM
To: Zhang, Qi Z ; Su, Simei ; Xing,
Beilei ; Zhang, Yuying ;
david.march...@redhat.com; Jiang, YuX 
Cc: dev@dpdk.org; Yang, Qiming ; sta...@dpdk.org;
Luca Boccassi ; Mcnamara, John

Subject: Re: [PATCH v6] net/i40e: rework maximum frame size configuration

On 22/03/2023 16:50, Kevin Traynor wrote:

On 27/02/2023 00:35, Zhang, Qi Z wrote:




Hi Simei/Qi/Yu



Hi Yu,




-Original Message-
From: Su, Simei 
Sent: Monday, February 20, 2023 4:00 PM
To: Xing, Beilei ; Zhang, Yuying
; Zhang, Qi Z ;
david.march...@redhat.com
Cc: dev@dpdk.org; Yang, Qiming ; Su, Simei
; sta...@dpdk.org
Subject: [PATCH v6] net/i40e: rework maximum frame size
configuration

One issue is reported by David Marchand that error occurs in OVS due
to the fix patch in mentioned changes below. The detailed reproduce
step and result are in
https://patchwork.dpdk.org/project/dpdk/patch/
20211207085946.121032-1-dapengx...@intel.com/.

This patch removes unnecessary link status check and directly sets
mac config in dev_start. Also, it sets the parameter "wait to
complete" true to wait for more time to make sure adminq command

execute completed.





Fixes: a4ba77367923 ("net/i40e: enable maximum frame size at port
level")
Fixes: 2184f7cdeeaa ("net/i40e: fix max frame size config at port
level")
Fixes: 719469f13b11 ("net/i40e: fix jumbo frame Rx with X722")
Cc: sta...@dpdk.org


These patches caused an observable regression in multiple 20.11 and
21.11 LTS releases that was only caught a long time after releases.

Is there anything being added to LTS validation for regression testing
this issue, so we don't get caught again?



This is the issue I was talking about earlier during the release meeting. Not 
sure
if we were talking about the same patch.

I was asking if there are some regression tests added/can be added to LTS
validation that will be run during each LTS validation cycle so we don't have 
any
more regressions on it.


Hi Kevin,
Thanks for your comments.
Yes. We are adding additional case to cover more testing. For main branch, we 
have done the regression testing (including the additional case testing), they 
both work well.


That's good to hear. Will the additional regression tests also be added 
to the LTS validation tests when they are run?



We hope the two related patches can be backported to LTS branch, and the second 
patch just reworks for previous bug's fix.
Patch1: 
https://patchwork.dpdk.org/project/dpdk/patch/20221213091837.87953-1-david.march...@redhat.com/
 a8ca8ed net/i40e: revert link status check on device start


I have already reverted those 3 backports on 21.11 branch so this is not 
needed.



Pathc2: 
https://patchwork.dpdk.org/project/dpdk/patch/20230306121853.27547-1-simei...@intel.com/
82fcf20 net/i40e: fix maximum frame size configuration



That is the v7 of this v6 with revert and fix split, so same one being 
discussed above.



Best regards,
Yu Jiang


thanks,
Kevin.


After reverting the original patch and 2 fixes, I'm a bit reluctant to
take more fixes without some form of regression testing in place.

thanks,
Kevin.



Reported-by: David Marchand 
Signed-off-by: Simei Su 


Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [PATCH v6] net/i40e: rework maximum frame size configuration

[Kevin Traynor]

On 22/03/2023 16:50, Kevin Traynor wrote:

On 27/02/2023 00:35, Zhang, Qi Z wrote:




Hi Simei/Qi/Yu



Hi Yu,




-Original Message-
From: Su, Simei 
Sent: Monday, February 20, 2023 4:00 PM
To: Xing, Beilei ; Zhang, Yuying
; Zhang, Qi Z ;
david.march...@redhat.com
Cc: dev@dpdk.org; Yang, Qiming ; Su, Simei
; sta...@dpdk.org
Subject: [PATCH v6] net/i40e: rework maximum frame size configuration

One issue is reported by David Marchand that error occurs in OVS due to the
fix patch in mentioned changes below. The detailed reproduce step and
result are in https://patchwork.dpdk.org/project/dpdk/patch/
20211207085946.121032-1-dapengx...@intel.com/.

This patch removes unnecessary link status check and directly sets mac config
in dev_start. Also, it sets the parameter "wait to complete" true to wait for
more time to make sure adminq command execute completed.




Fixes: a4ba77367923 ("net/i40e: enable maximum frame size at port level")
Fixes: 2184f7cdeeaa ("net/i40e: fix max frame size config at port level")
Fixes: 719469f13b11 ("net/i40e: fix jumbo frame Rx with X722")
Cc: sta...@dpdk.org


These patches caused an observable regression in multiple 20.11 and
21.11 LTS releases that was only caught a long time after releases.

Is there anything being added to LTS validation for regression testing
this issue, so we don't get caught again?



This is the issue I was talking about earlier during the release 
meeting. Not sure if we were talking about the same patch.


I was asking if there are some regression tests added/can be added to 
LTS validation that will be run during each LTS validation cycle so we 
don't have any more regressions on it.


thanks,
Kevin.


After reverting the original patch and 2 fixes, I'm a bit reluctant to
take more fixes without some form of regression testing in place.

thanks,
Kevin.



Reported-by: David Marchand 
Signed-off-by: Simei Su 


Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Kevin Traynor]

+cc John

For better context, this part of the discussion starts here:
http://inbox.dpdk.org/dev/d718d0fe-09a2-8840-e8a4-dd41b732b...@redhat.com/

On 16/03/2023 13:31, Kevin Traynor wrote:

On 15/03/2023 11:47, Kevin Traynor wrote:

On 21/12/2022 09:28, Kevin Traynor wrote:

On 21/12/2022 06:09, Andrew Rybchenko wrote:

Hi Kevin,

On 12/20/22 17:05, Kevin Traynor wrote:

On 24/06/2022 11:23, Ciara Loftus wrote:

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if
so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 


Hi Andrew/Qi (assuming Ciara is still out of office),

I am seeing a similar issue [1] on 21.11 branch with Fedora 37
(libbpf-0.8.0-2.fc37.x86_64 and libxdp-1.2.6-1.fc37.x86_64).

This patch alone won't apply as there are other dependencies. Looking at
the commits in main branch, it seems like I could take all these [2] to
resolve the issue. With these cherry-picked the build warnings on Fedora
37 are removed.

It's a bit late to take these for DPDK 21.11.3 as I intend to release
later today/tomorrow, so it can be resolved for DPDK 21.11.4.

Do the commits below look ok for backport? Main branch might be able to
demand user uses new libbpf/libxdp versions etc, but with stable we
never want to break the users existing setup when they upgrade from
2X.11.n to 2X.11.n+1.


N.B. 



Let me know what you think?


IMO these patches are to to be backported to stable branch.


Thanks Andrew.


However, af_xdp maintainers opinion is more important here.



Qi, what do you think?



Hi Qi/Ciara, this issue is still present approaching 21.11.4.

What is your opinion on backporting these patches? Please especially
note the paragraph above wrt users not being required to upgrade libbpf.



+Shibin, following discussion in DPDK release meeting.


thanks,
Kevin.



thanks,
Kevin.

[1] https://paste.centos.org/view/e4eec764
[2]
1eb1846b1a net/af_xdp: make compatible with libbpf 0.8.0
5ff3dbe6ce net/af_xdp: add log on XDP program removal failures
0ed0bc3834 net/af_xdp: avoid version-based check for program load
e024c7e838 net/af_xdp: avoid version-based check for shared UMEM
f76dc44ded net/af_xdp: make clear which libxdp version is required
50b855fc47 net/af_xdp: move XDP library presence flag setting

Re: [PATCH v6] net/i40e: rework maximum frame size configuration

[Kevin Traynor]

On 27/02/2023 00:35, Zhang, Qi Z wrote:




Hi Simei/Qi/Yu




-Original Message-
From: Su, Simei 
Sent: Monday, February 20, 2023 4:00 PM
To: Xing, Beilei ; Zhang, Yuying
; Zhang, Qi Z ;
david.march...@redhat.com
Cc: dev@dpdk.org; Yang, Qiming ; Su, Simei
; sta...@dpdk.org
Subject: [PATCH v6] net/i40e: rework maximum frame size configuration

One issue is reported by David Marchand that error occurs in OVS due to the
fix patch in mentioned changes below. The detailed reproduce step and
result are in https://patchwork.dpdk.org/project/dpdk/patch/
20211207085946.121032-1-dapengx...@intel.com/.

This patch removes unnecessary link status check and directly sets mac config
in dev_start. Also, it sets the parameter "wait to complete" true to wait for
more time to make sure adminq command execute completed.




Fixes: a4ba77367923 ("net/i40e: enable maximum frame size at port level")
Fixes: 2184f7cdeeaa ("net/i40e: fix max frame size config at port level")
Fixes: 719469f13b11 ("net/i40e: fix jumbo frame Rx with X722")
Cc: sta...@dpdk.org


These patches caused an observable regression in multiple 20.11 and 
21.11 LTS releases that was only caught a long time after releases.


Is there anything being added to LTS validation for regression testing 
this issue, so we don't get caught again?


After reverting the original patch and 2 fixes, I'm a bit reluctant to 
take more fixes without some form of regression testing in place.


thanks,
Kevin.



Reported-by: David Marchand 
Signed-off-by: Simei Su 


Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Kevin Traynor]

On 15/03/2023 11:47, Kevin Traynor wrote:

On 21/12/2022 09:28, Kevin Traynor wrote:

On 21/12/2022 06:09, Andrew Rybchenko wrote:

Hi Kevin,

On 12/20/22 17:05, Kevin Traynor wrote:

On 24/06/2022 11:23, Ciara Loftus wrote:

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if
so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 


Hi Andrew/Qi (assuming Ciara is still out of office),

I am seeing a similar issue [1] on 21.11 branch with Fedora 37
(libbpf-0.8.0-2.fc37.x86_64 and libxdp-1.2.6-1.fc37.x86_64).

This patch alone won't apply as there are other dependencies. Looking at
the commits in main branch, it seems like I could take all these [2] to
resolve the issue. With these cherry-picked the build warnings on Fedora
37 are removed.

It's a bit late to take these for DPDK 21.11.3 as I intend to release
later today/tomorrow, so it can be resolved for DPDK 21.11.4.

Do the commits below look ok for backport? Main branch might be able to
demand user uses new libbpf/libxdp versions etc, but with stable we
never want to break the users existing setup when they upgrade from
2X.11.n to 2X.11.n+1.


N.B. 



Let me know what you think?


IMO these patches are to to be backported to stable branch.


Thanks Andrew.


However, af_xdp maintainers opinion is more important here.



Qi, what do you think?



Hi Qi/Ciara, this issue is still present approaching 21.11.4.

What is your opinion on backporting these patches? Please especially
note the paragraph above wrt users not being required to upgrade libbpf.



+Shibin, following discussion in DPDK release meeting.


thanks,
Kevin.



thanks,
Kevin.

[1] https://paste.centos.org/view/e4eec764
[2]
1eb1846b1a net/af_xdp: make compatible with libbpf 0.8.0
5ff3dbe6ce net/af_xdp: add log on XDP program removal failures
0ed0bc3834 net/af_xdp: avoid version-based check for program load
e024c7e838 net/af_xdp: avoid version-based check for shared UMEM
f76dc44ded net/af_xdp: make clear which libxdp version is required
50b855fc47 net/af_xdp: move XDP library presence flag setting

Fwd: [Bug 1185] enic: no longer accepting 2048 descriptor size in 20.11.6

[Kevin Traynor]

Hi John/Hyong Youb,

Not sure if you are monitoring dpdk bugzilla, but wanted to draw your 
attention to https://bugs.dpdk.org/show_bug.cgi?id=1185


Maybe you have some clues about it and if we need to backport the 
mentioned commit?


thanks,
Kevin.

 Forwarded Message 
Subject: [Bug 1185] enic: no longer accepting 2048 descriptor size in 
20.11.6

Date: Wed, 15 Mar 2023 17:33:52 +
From: bugzi...@dpdk.org
To: dev@dpdk.org

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

Bug ID: 1185
   Summary: enic: no longer accepting 2048 descriptor size in
20.11.6
   Product: DPDK
   Version: 20.11
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: ktray...@redhat.com
  Target Milestone: ---

Hi enic maintainers,

With openvswitch 2.15 using dpdk 20.11.6, enic driver is reporting that it
cannot accept setup with default OVS number of tx descriptors (2048).

2022-08-19T16:29:38.555Z|00204|dpdk|ERR|Invalid value for nb_tx_desc(=2048),
should be: <= 256, >= 64, and a product of 32

OVS has used 2048 as default for many years and the code in 20.11.6 does not
look like it changed much from previous releases either.

The commit below [0] on dpdk main branch (but not on 20.11 branch), 
changes how

max descriptor values are calculated.

So any idea why the 2048 can no longer be used with 20.11.6 ? some commit I
missed? different firmware?

or is it an incorrect calculation and the commit [0] is needed on stable
branches to correct this?

Thanks.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2119876

[0]
commit 22572e84fbda2c195707ffbb0dd6af4433d7a219
Author: John Daley 
Date:   Fri Jan 28 09:58:13 2022 -0800

net/enic: support max descriptors allowed by adapter

Newer VIC adapters have the max number of supported RX and TX
descriptors in their configuration. Use these values as the
maximums.

Signed-off-by: John Daley 
Reviewed-by: Hyong Youb Kim 

--
You are receiving this mail because:
You are the assignee for the bug.

Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Kevin Traynor]

On 21/12/2022 09:28, Kevin Traynor wrote:

On 21/12/2022 06:09, Andrew Rybchenko wrote:

Hi Kevin,

On 12/20/22 17:05, Kevin Traynor wrote:

On 24/06/2022 11:23, Ciara Loftus wrote:

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if
so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 


Hi Andrew/Qi (assuming Ciara is still out of office),

I am seeing a similar issue [1] on 21.11 branch with Fedora 37
(libbpf-0.8.0-2.fc37.x86_64 and libxdp-1.2.6-1.fc37.x86_64).

This patch alone won't apply as there are other dependencies. Looking at
the commits in main branch, it seems like I could take all these [2] to
resolve the issue. With these cherry-picked the build warnings on Fedora
37 are removed.

It's a bit late to take these for DPDK 21.11.3 as I intend to release
later today/tomorrow, so it can be resolved for DPDK 21.11.4.

Do the commits below look ok for backport? Main branch might be able to
demand user uses new libbpf/libxdp versions etc, but with stable we
never want to break the users existing setup when they upgrade from
2X.11.n to 2X.11.n+1.


N.B. 



Let me know what you think?


IMO these patches are to to be backported to stable branch.


Thanks Andrew.


However, af_xdp maintainers opinion is more important here.



Qi, what do you think?



Hi Qi/Ciara, this issue is still present approaching 21.11.4.

What is your opinion on backporting these patches? Please especially 
note the paragraph above wrt users not being required to upgrade libbpf.


thanks,
Kevin.



thanks,
Kevin.

[1] https://paste.centos.org/view/e4eec764
[2]
1eb1846b1a net/af_xdp: make compatible with libbpf 0.8.0
5ff3dbe6ce net/af_xdp: add log on XDP program removal failures
0ed0bc3834 net/af_xdp: avoid version-based check for program load
e024c7e838 net/af_xdp: avoid version-based check for shared UMEM
f76dc44ded net/af_xdp: make clear which libxdp version is required
50b855fc47 net/af_xdp: move XDP library presence flag setting

Re: [PATCH v2] net/ice: fix ice dcf control thread crash

[Kevin Traynor]

On 13/02/2023 07:16, Ke Zhang wrote:

The control thread accesses the hardware resources after the
resources were released, resulting in a segment error.

This commit fixes the bug by exiting thread before resource released.



Please add the "Fixes: xyz" tag for the commit that introduced this bug 
so the fix can be backported to the appropriate stable branches.



Signed-off-by: Ke Zhang 
---
v2: add pthread_exit() for windows
---
  drivers/net/ice/ice_dcf.c | 4 
  lib/eal/windows/include/pthread.h | 5 +
  2 files changed, 9 insertions(+)

diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 1c3d22ae0f..e58908caf5 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -543,6 +543,8 @@ ice_dcf_handle_vsi_update_event(struct ice_dcf_hw *hw)
ice_dcf_disable_irq0(hw);
  
  	for (;;) {

+   if (hw->vc_event_msg_cb == NULL)
+   pthread_exit(NULL);
if (ice_dcf_get_vf_resource(hw) == 0 &&
ice_dcf_get_vf_vsi_map(hw) >= 0) {
err = 0;
@@ -760,6 +762,8 @@ ice_dcf_uninit_hw(struct rte_eth_dev *eth_dev, struct 
ice_dcf_hw *hw)
rte_intr_callback_unregister(intr_handle,
 ice_dcf_dev_interrupt_handler, hw);
  
+	hw->vc_event_msg_cb = NULL;

+
ice_dcf_mode_disable(hw);
iavf_shutdown_adminq(&hw->avf);
  
diff --git a/lib/eal/windows/include/pthread.h b/lib/eal/windows/include/pthread.h

index 27fd2cca52..f0068ebd73 100644
--- a/lib/eal/windows/include/pthread.h
+++ b/lib/eal/windows/include/pthread.h
@@ -149,6 +149,11 @@ pthread_detach(__rte_unused pthread_t thread)
return 0;
  }
  
+static inline void

+pthread_exit(__rte_unused void *__retval)
+{
+}
+
  static inline int
  pthread_join(__rte_unused pthread_t thread,
__rte_unused void **value_ptr)

Re: [PATCH] net/i40e: reduce the ITR interval of multi-driver mode

[Kevin Traynor]

On 26/12/2022 05:50, Zhang, Qi Z wrote:




-Original Message-
From: Qiming Yang 
Sent: Friday, December 16, 2022 11:12 AM
To: dev@dpdk.org; Xing, Beilei 
Cc: Yang, Qiming 
Subject: [PATCH] net/i40e: reduce the ITR interval of multi-driver mode

This patch change the interrupt interval from 8160us to 32us to improve the
performance of multi-driver mode.

Signed-off-by: Qiming Yang 


Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

The patch also looks good for backporting, so added Cc stable tag.



Hi. This looks like it is not fixing anything and it is changing a 
behaviour, so I won't take for 21.11.4.


thanks,
Kevin.


Thanks
Qi



---
  drivers/net/i40e/i40e_ethdev.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index fe943a45ff..7c4cc44a27 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -1497,7 +1497,7 @@ i40e_calc_itr_interval(bool is_pf, bool is_multi_drv)
uint16_t interval = 0;

if (is_multi_drv) {
-   interval = I40E_QUEUE_ITR_INTERVAL_MAX;
+   interval = I40E_QUEUE_ITR_INTERVAL_DEFAULT;
} else {
if (is_pf)
interval = I40E_QUEUE_ITR_INTERVAL_DEFAULT;
--
2.25.1

Re: [PATCH] net/nfp: support 48-bit DMA address for firmware with NFDk

[Kevin Traynor]

On 15/02/2023 18:28, Ferruh Yigit wrote:

On 2/15/2023 5:47 PM, Niklas Söderlund wrote:

Hi Ferruh,

Thanks for your continues effort in dealing with NFP patches.

On 2023-02-15 13:42:01 +, Ferruh Yigit wrote:

On 2/8/2023 9:15 AM, Chaoyong He wrote:

From: Peng Zhang 

48-bit DMA address is supported in the firmware with NFDk, so enable
this feature in PMD now. But the firmware with NFD3 still just
support 40-bit DMA address.

RX free list descriptor, used by both NFD3 and NFDk, is also modified
to support 48-bit DMA address. That's OK because the top bits is always
set to 0 when assigned with 40-bit DMA address.

Fixes: c73dced48c8c ("net/nfp: add NFDk Tx")
Cc: jin@corigine.com
Cc: sta...@dpdk.org



Why a backport is requested? As far as I understand this is not fixing
anything but extending device capability. Is this a fix?


I agree this is a bit of a grey zone. We reasoned this was a fix as we
should have done this from the start in the commit that added support
for NFDk. Are you OK moving forward with this as a fix or would you
prefer we resubmit without the request to backport?



I am not sure, is this change have any potential to change behavior for
existing users?
Like if one of your user is using 22.11.1 release, and if this patch
backported to next LTS version, 22.11.2, will user notice any difference?


@Luca, @Kevin, what is your comment as LTS maintainers?



A bit difficult to know. If NFDk is not practicably usable without it, 
then it could be considered a fix. If it's just extending to add 
nice-to-have functionality then probably it is not a fix.


It would need to ensure that it is tested on 22.11 branch and there are 
no regressions. It is only relevant to DPDK 22.11 LTS so Cc Xueming who 
will ultimately decide.


A guide below on some things to consider for this type of backport is here:
http://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-be-backported




Signed-off-by: Peng Zhang 
Reviewed-by: Chaoyong He 
Reviewed-by: Niklas Söderlund