DPDK Release Status Meeting 2023-11-23

DPDK Release Status Meeting 2023-11-23

[Mcnamara, John]

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

Release status meeting minutes 2023-11-23
=========================================

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

Participants:
* AMD
* ARM
* Debian/Microsoft
* Intel
* Marvell
* Nvidia
* Red Hat

Release Dates
-------------

The following are the current working dates for 23.11:

* V1:      12 August   2023
* RC1:     11 October  2023
* RC2:      6 November 2023
* RC3:     13 November 2023
* RC4:     23 November 2023
* Release: 24 November 2023


The following are the current working dates for 24.03:

- Proposal deadline (RFC/v1 patches): 22 December 2023
- API freeze (-rc1): 5 February 2024
- PMD features freeze (-rc2): 23 February 2024
- Builtin applications features freeze (-rc3): 4 March 2024
- Release: 14 March 2024



Subtrees
--------

* next-net
  * No direct changes past RC4

* next-net-intel
  * No direct changes past RC4

* next-net-mlx
  * No direct changes past RC4

* next-net-mvl
  * No direct changes past RC4

* next-eventdev
  * No direct changes past RC4

* next-baseband
  * No direct changes past RC4

* next-virtio
  * No direct changes past RC4

* next-crypto
  * No direct changes past RC4

* main
  * RC4 released
  * Release targeted for 24 November 2023, depending on some build/CI issues:
    * Build/link issue on Debian
      https://salsa.debian.org/debian/dpdk/-/jobs/4949787
    * cpfl compilation issue
      https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_Next/i586
    * LCOREs autotest timing out on ARM:
      https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64


Proposed Schedule for 2023
--------------------------

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


LTS
---

* 22.11.3 - In progress
* 21.11.6 - In progress
* 20.11.10 - In progress
* 19.11.15 - Will only be updated with CVE and critical fixes.


* Distros
  * Debian 12 contains DPDK v22.11
  * Ubuntu 22.04-LTS contains DPDK v21.11
  * Ubuntu 23.04 contains DPDK v22.11

Defects
-------

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



DPDK Release Status Meetings
----------------------------

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

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

You don't need an invite to join the meeting but if you want a calendar reminder just
send an email to "John McNamara john.mcnamara@intel.com" for the invite.


[-- Attachment #2: Type: text/html, Size: 14353 bytes --]

Re: DPDK Release Status Meeting 2023-11-23

[Ruifeng Wang]

On 2023/11/24 4:53 PM, Mcnamara, John wrote:
> Release status meeting minutes 2023-11-23
> 
<snip>
> issues:
> 
>      * Build/link issue on Debian
> 
>        https://salsa.debian.org/debian/dpdk/-/jobs/4949787
> 
>      * cpfl compilation issue
> 
>        
> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_Next/i586
> 
>      * LCOREs autotest timing out on ARM:
> 
>        
> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64

The failure relates to test environment. 50s is not enough for lcores 
test to finish.

Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case 
would take a longer time to finish iterations.
In one of my run, the case took about 100s.

> 
> Proposed Schedule for 2023
> 
> --------------------------
> 
> See http://core.dpdk.org/roadmap/#dates
> 
> LTS
> 
> ---
> 
> * 22.11.3 - In progress
> 
> * 21.11.6 - In progress
> 
> * 20.11.10 - In progress
> 
> * 19.11.15 - Will only be updated with CVE and critical fixes.
> 
> * Distros
> 
>    * Debian 12 contains DPDK v22.11
> 
>    * Ubuntu 22.04-LTS contains DPDK v21.11
> 
>    * Ubuntu 23.04 contains DPDK v22.11
> 
> Defects
> 
> -------
> 
> * Bugzilla links, 'Bugs',  added for hosted projects
> 
>    * https://www.dpdk.org/hosted-projects/
> 
> DPDK Release Status Meetings
> 
> ----------------------------
> 
> The DPDK Release Status Meeting is intended for DPDK Committers to 
> discuss the
> 
> status of the master tree and sub-trees, and for project managers to track
> 
> progress or milestone dates.
> 
> The meeting occurs on every Thursday at 9:30 UTC over Jitsi on 
> https://meet.jit.si/DPDK
> 
> You don't need an invite to join the meeting but if you want a calendar 
> reminder just
> 
> send an email to "John McNamara john.mcnamara@intel.com" for the invite.
> 

Re: DPDK Release Status Meeting 2023-11-23

[Luca Boccassi]

On Sun, 26 Nov 2023 at 01:55, Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
>
>
>
> On 2023/11/24 4:53 PM, Mcnamara, John wrote:
> > Release status meeting minutes 2023-11-23
> >
> <snip>
> > issues:
> >
> >      * Build/link issue on Debian
> >
> >        https://salsa.debian.org/debian/dpdk/-/jobs/4949787
> >
> >      * cpfl compilation issue
> >
> >
> > https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_Next/i586
> >
> >      * LCOREs autotest timing out on ARM:
> >
> >
> > https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64
>
> The failure relates to test environment. 50s is not enough for lcores
> test to finish.
>
> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
> would take a longer time to finish iterations.
> In one of my run, the case took about 100s.

Right, but this test is part of the "fast suite", and more than a
minute is not exactly fast. So one of the following should ideally
happen:

1) Test is moved out of the fast suite
2) Test has its individual timeout sized appropriately so that it
never fails regardless of the environment
3) Test is capped so that it doesn't grow with the number of cores
without limits

Re: DPDK Release Status Meeting 2023-11-23

[Ruifeng Wang]

On 2023/11/26 8:44 PM, Luca Boccassi wrote:
> On Sun, 26 Nov 2023 at 01:55, Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
>>
>>
>>
>> On 2023/11/24 4:53 PM, Mcnamara, John wrote:
>>> Release status meeting minutes 2023-11-23
>>>
>> <snip>
>>> issues:
>>>
>>>       * Build/link issue on Debian
>>>
>>>         https://salsa.debian.org/debian/dpdk/-/jobs/4949787
>>>
>>>       * cpfl compilation issue
>>>
>>>
>>> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_Next/i586
>>>
>>>       * LCOREs autotest timing out on ARM:
>>>
>>>
>>> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64
>>
>> The failure relates to test environment. 50s is not enough for lcores
>> test to finish.
>>
>> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
>> would take a longer time to finish iterations.
>> In one of my run, the case took about 100s.
> 
> Right, but this test is part of the "fast suite", and more than a
> minute is not exactly fast. So one of the following should ideally
> happen:

Agree.

> 
> 1) Test is moved out of the fast suite
> 2) Test has its individual timeout sized appropriately so that it
> never fails regardless of the environment
> 3) Test is capped so that it doesn't grow with the number of cores
> without limits

I'm for option 3. The case should be kept in fast suite. Time taken 
should be capped.

Thanks,
Ruifeng

Re: DPDK Release Status Meeting 2023-11-23

[Thomas Monjalon]

27/11/2023 03:51, Ruifeng Wang:
> On 2023/11/26 8:44 PM, Luca Boccassi wrote:
> > On Sun, 26 Nov 2023 at 01:55, Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
> >> On 2023/11/24 4:53 PM, Mcnamara, John wrote:
> >>> Release status meeting minutes 2023-11-23
> >>>       * LCOREs autotest timing out on ARM:
> >>>
> >>>
> >>> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64
> >>
> >> The failure relates to test environment. 50s is not enough for lcores
> >> test to finish.
> >>
> >> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
> >> would take a longer time to finish iterations.
> >> In one of my run, the case took about 100s.
> > 
> > Right, but this test is part of the "fast suite", and more than a
> > minute is not exactly fast. So one of the following should ideally
> > happen:
> 
> Agree.
> 
> > 1) Test is moved out of the fast suite
> > 2) Test has its individual timeout sized appropriately so that it
> > never fails regardless of the environment
> > 3) Test is capped so that it doesn't grow with the number of cores
> > without limits
> 
> I'm for option 3. The case should be kept in fast suite. Time taken 
> should be capped.

More than 1 second is a bit slow.
Please make the test really faster.

Re: DPDK Release Status Meeting 2023-11-23

[Stephen Hemminger]

On Mon, 27 Nov 2023 11:13:16 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> ish.
> > >>
> > >> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
> > >> would take a longer time to finish iterations.
> > >> In one of my run, the case took about 100s.  
> > > 
> > > Right, but this test is part of the "fast suite", and more than a
> > > minute is not exactly fast. So one of the following should ideally
> > > happen:  
> > 
> > Agree.
> >   
> > > 1) Test is moved out of the fast suite
> > > 2) Test has its individual timeout sized appropriately so that it
> > > never fails regardless of the environment
> > > 3) Test is capped so that it doesn't grow with the number of cores
> > > without limits  
> > 
> > I'm for option 3. The case should be kept in fast suite. Time taken 
> > should be capped.  
> 
> More than 1 second is a bit slow.
> Please make the test really faster.

What is the test trying to exercise? Can it be done in another way?

Re: DPDK Release Status Meeting 2023-11-23

[Ruifeng Wang]

On 2023/11/28 1:16 AM, Stephen Hemminger wrote:
> On Mon, 27 Nov 2023 11:13:16 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
>> ish.
>>>>>
>>>>> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
>>>>> would take a longer time to finish iterations.
>>>>> In one of my run, the case took about 100s.
>>>>
>>>> Right, but this test is part of the "fast suite", and more than a
>>>> minute is not exactly fast. So one of the following should ideally
>>>> happen:
>>>
>>> Agree.
>>>    
>>>> 1) Test is moved out of the fast suite
>>>> 2) Test has its individual timeout sized appropriately so that it
>>>> never fails regardless of the environment
>>>> 3) Test is capped so that it doesn't grow with the number of cores
>>>> without limits
>>>
>>> I'm for option 3. The case should be kept in fast suite. Time taken
>>> should be capped.
>>
>> More than 1 second is a bit slow.
>> Please make the test really faster.
> 
> What is the test trying to exercise? Can it be done in another way?

The time consuming part is non-EAL test. It creates non-EAL threads 
until filling up RTE_MAX_LCORE.

This part can be a separate case outside of fast suite.