Re: [PATCH 0/5] Increase minimum meson version

Re: [PATCH 0/5] Increase minimum meson version

[David Marchand]

Hello CI guys,

On Fri, Sep 20, 2024 at 2:57 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> This patchset proposed increasing the minimum meson version to 0.57
> and makes changes to update our build files appropriately for that
> change: replacing deprecated functions, removing unnecessary version
> checks and taking advantage of some new capabilities.
>
> Why 0.57? No one particular reason; it's mainly a conservative version
> bump that doesn't have many impacts, but still gives us the minimum
> updates we need to replace the deprecated get_cross_properties fn
> and have a few extra features guaranteed available.
>
> Bruce Richardson (5):
>   build: increase minimum meson version to 0.57
>   build: remove version check on compiler links function
>   build: remove unnecessary version checks
>   build: use version file support from meson
>   build: replace deprecated meson function
>
>  .ci/linux-setup.sh                        | 2 +-
>  config/arm/meson.build                    | 4 ++--
>  config/meson.build                        | 8 ++++----
>  config/riscv/meson.build                  | 4 ++--
>  doc/api/meson.build                       | 2 +-
>  doc/guides/linux_gsg/sys_reqs.rst         | 2 +-
>  doc/guides/prog_guide/build-sdk-meson.rst | 2 +-
>  drivers/common/qat/meson.build            | 2 +-
>  drivers/crypto/ipsec_mb/meson.build       | 2 +-
>  drivers/event/cnxk/meson.build            | 2 +-
>  drivers/meson.build                       | 7 ++-----
>  drivers/net/cnxk/meson.build              | 2 +-
>  lib/meson.build                           | 6 ------
>  meson.build                               | 7 ++-----
>  14 files changed, 20 insertions(+), 32 deletions(-)

This series can't be merged until the (UNH and LoongArch) CI are ready
for such a change.

TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
in the current release.

@UNH @Min Zhou
How long would it take for all CI to be ready for this change?

Important note: if relevant to your CI, testing against LTS branches
must still be done with the 0.53.2 version, so no change relying on
post 0.53.2 meson feature gets backported.


-- 
David Marchand

Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version

[Patrick Robb]

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

On Tue, Oct 8, 2024 at 4:28 AM David Marchand <david.marchand@redhat.com>
wrote:

>
> This series can't be merged until the (UNH and LoongArch) CI are ready
> for such a change.
>
> TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
> in the current release.
>
> @UNH @Min Zhou
> How long would it take for all CI to be ready for this change?
>
>
Thanks for the heads up. So, as far as I can tell, this will require an
update to the dpdk/.ci/linux-setup.sh script (which I have just submitted)
as I think various labs rely on it including the github robot, loongson,
Intel (Maybe, I don't know). UNH does not use it much as we opt to meet the
meson dependency separately in the dpdk-ci project's container template
engine.

It will also require updates to the container template engine, which I can
get Cody started on tomorrow.


> Important note: if relevant to your CI, testing against LTS branches
> must still be done with the 0.53.2 version, so no change relying on
> post 0.53.2 meson feature gets backported.
>

Okay, full disclosure I don't think this is something we handled the last
time the meson version got bumped in 2022. So, back then we just bumped the
meson version for all environments to .53, then did LTS testing for 19.11,
20.11, 21.11 from environments running meson .53. But, I understand how
this is an issue and something we should avoid this go around.

However, it is not ideal to set the meson version "at runtime" for CI
testing based on the repo under test (mainline and next-* want .57, old LTS
versions want .53). It would be possible to modify our jenkinsfiles
(automation scripts) to check the DPDK version, and run pip commands
resetting the meson version accordingly, at the start of each testing
job... but I have a couple concerns here with regards to
stability/maintenance.

Another option, which Adam is suggesting, is to create a dedicated
environment which is version locked to .53 (it can just be an ubuntu
container image), label it as a meson .53 environment, and add that to the
total list of dpdk build environments which are run when we do testing for
either 22.11, or 23.11. Then, we could run the rest of the testing from the
same container images we use for mainline (that have .57 baked in), and
this would not be a problem because we would have that 1 environment doing
a dpdk build, which is guaranteed to be on .53. Bruce/David let me know if
you can think of any issues with this.

This is also very similar to a Community Lab request from a few months ago
(which we have an open internal Jira ticket for), which is to add a VM
environment which is locked to the minimum supported kernel version for
DPDK. But, that's another story...

Anyways, in terms of the timeline... the Jenkins script updates are
probably the most difficult in that they will require a PR review, dry run
tests etc. but it's still fairly trivial. Cody can probably update the
meson dependencies on the template engine and submit that to the dpdk-ci
project by end of week. So, I would say CI should be ready by next Tuesday,
provided the patches which will be incoming to dev and ci mailing lists can
be merged. Is this timeline okay?

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

Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version

[Bruce Richardson]

On Tue, Oct 08, 2024 at 03:49:12PM -0400, Patrick Robb wrote:
>    On Tue, Oct 8, 2024 at 4:28 AM David Marchand
>    <[1]david.marchand@redhat.com> wrote:
> 
>      This series can't be merged until the (UNH and LoongArch) CI are
>      ready
>      for such a change.
>      TL;DR: the meson minimum version is being changed from 0.53.2 to
>      0.57
>      in the current release.
>      @UNH @Min Zhou
>      How long would it take for all CI to be ready for this change?
> 
>    Thanks for the heads up. So, as far as I can tell, this will require an
>    update to the dpdk/.ci/linux-setup.sh script (which I have just
>    submitted) as I think various labs rely on it including the github
>    robot, loongson, Intel (Maybe, I don't know).

The update to that linux-setup file is included already in the first patch
of the series. No additional updates needed for jobs that rely on it.

> UNH does not use it much
>    as we opt to meet the meson dependency separately in the dpdk-ci
>    project's container template engine.

That's a bit of a pity, since we can't update the meson version
automatically as part of the meson update as we do with CIs using the
linux-setup script. Is there some other file that can be in the DPDK main
repo that can contain this details to regular DPDK patches can update the
CI too as part of a meson update?

>    It will also require updates to the container template engine, which I
>    can get Cody started on tomorrow.
> 
>      Important note: if relevant to your CI, testing against LTS branches
>      must still be done with the 0.53.2 version, so no change relying on
>      post 0.53.2 meson feature gets backported.
> 
>    Okay, full disclosure I don't think this is something we handled the
>    last time the meson version got bumped in 2022. So, back then we just
>    bumped the meson version for all environments to .53, then did LTS
>    testing for 19.11, 20.11, 21.11 from environments running meson .53.
>    But, I understand how this is an issue and something we should avoid
>    this go around.
>    However, it is not ideal to set the meson version "at runtime" for CI
>    testing based on the repo under test (mainline and next-* want .57, old
>    LTS versions want .53). It would be possible to modify our jenkinsfiles
>    (automation scripts) to check the DPDK version, and run pip commands
>    resetting the meson version accordingly, at the start of each testing
>    job... but I have a couple concerns here with regards to
>    stability/maintenance.

I would recommend against using the DPDK version as a guide. However, the
meson version is included in the project options in the meson.build file of
the code. Could you use "grep meson_version meson.build" in a script to
extra the required version info? If it's helpful, we can possibly provide
some sort of compatibility guarantee of the format of this line.


Regards,
/Bruce

Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version

[Patrick Robb]

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

On Tue, Oct 8, 2024 at 4:04 PM Bruce Richardson <bruce.richardson@intel.com>
wrote:

>
> > UNH does not use it much
> >    as we opt to meet the meson dependency separately in the dpdk-ci
> >    project's container template engine.
>
> That's a bit of a pity, since we can't update the meson version
> automatically as part of the meson update as we do with CIs using the
> linux-setup script. Is there some other file that can be in the DPDK main
> repo that can contain this details to regular DPDK patches can update the
> CI too as part of a meson update?
>
>
I think the only way to do that would be to submit a patch alongside for
the dpdk ci container template engine:
https://git.dpdk.org/tools/dpdk-ci/tree/containers/README.md. But this
would not work very well as dpdk-ci is a separate repo from dpdk, so you
can't really package the meson update and the ci update in one patchseries.

So, I guess based on your comments it seems like the best solution is to
remove the meson step from the container template engine (Dockerfiles) and
run the linux-setup.sh script right before each testrun, which solves the
problem you raise about updating dpdk and CI side by side, and solves the
main vs LTS issue. And of course it comes with the benefit of making CI
processes more common across labs. I had run through this idea with Adam
yesterday and we agreed that it would work but decided it was our second
favorite option... but I think with the points you are raising it is clear
this is the correct route to take.


> >    It will also require updates to the container template engine, which I
> >    can get Cody started on tomorrow.
> >
> >      Important note: if relevant to your CI, testing against LTS branches
> >      must still be done with the 0.53.2 version, so no change relying on
> >      post 0.53.2 meson feature gets backported.
> >
> >    Okay, full disclosure I don't think this is something we handled the
> >    last time the meson version got bumped in 2022. So, back then we just
> >    bumped the meson version for all environments to .53, then did LTS
> >    testing for 19.11, 20.11, 21.11 from environments running meson .53.
> >    But, I understand how this is an issue and something we should avoid
> >    this go around.
> >    However, it is not ideal to set the meson version "at runtime" for CI
> >    testing based on the repo under test (mainline and next-* want .57,
> old
> >    LTS versions want .53). It would be possible to modify our
> jenkinsfiles
> >    (automation scripts) to check the DPDK version, and run pip commands
> >    resetting the meson version accordingly, at the start of each testing
> >    job... but I have a couple concerns here with regards to
> >    stability/maintenance.
>
> I would recommend against using the DPDK version as a guide. However, the
> meson version is included in the project options in the meson.build file of
> the code. Could you use "grep meson_version meson.build" in a script to
> extra the required version info? If it's helpful, we can possibly provide
> some sort of compatibility guarantee of the format of this line.
>

Thanks this seems like another good option (I did not realize we could get
this from meson.build) and something we can fall back on if usage of the
linux-setup.sh is problematic in any way.

So, we have a different strategy but the timeline should be the same as
this is all fairly trivial. Let me know if yall have any concerns.

Cheers.

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

Re: [PATCH 0/5] Increase minimum meson version

[zhoumin]

Hi David,

On Tues, Oct 8, 2024 at 8:28AM, David Marchand wrote:
> Hello CI guys,
>
> On Fri, Sep 20, 2024 at 2:57 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
>> This patchset proposed increasing the minimum meson version to 0.57
>> and makes changes to update our build files appropriately for that
>> change: replacing deprecated functions, removing unnecessary version
>> checks and taking advantage of some new capabilities.
>>
>> Why 0.57? No one particular reason; it's mainly a conservative version
>> bump that doesn't have many impacts, but still gives us the minimum
>> updates we need to replace the deprecated get_cross_properties fn
>> and have a few extra features guaranteed available.
>>
>> Bruce Richardson (5):
>>    build: increase minimum meson version to 0.57
>>    build: remove version check on compiler links function
>>    build: remove unnecessary version checks
>>    build: use version file support from meson
>>    build: replace deprecated meson function
>>
>>   .ci/linux-setup.sh                        | 2 +-
>>   config/arm/meson.build                    | 4 ++--
>>   config/meson.build                        | 8 ++++----
>>   config/riscv/meson.build                  | 4 ++--
>>   doc/api/meson.build                       | 2 +-
>>   doc/guides/linux_gsg/sys_reqs.rst         | 2 +-
>>   doc/guides/prog_guide/build-sdk-meson.rst | 2 +-
>>   drivers/common/qat/meson.build            | 2 +-
>>   drivers/crypto/ipsec_mb/meson.build       | 2 +-
>>   drivers/event/cnxk/meson.build            | 2 +-
>>   drivers/meson.build                       | 7 ++-----
>>   drivers/net/cnxk/meson.build              | 2 +-
>>   lib/meson.build                           | 6 ------
>>   meson.build                               | 7 ++-----
>>   14 files changed, 20 insertions(+), 32 deletions(-)
> This series can't be merged until the (UNH and LoongArch) CI are ready
> for such a change.
>
> TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
> in the current release.
>
> @UNH @Min Zhou
> How long would it take for all CI to be ready for this change?
It's OK for Loongson lab. The meson version for DPDK CI in Loongson lab 
is 0.63.0.
> Important note: if relevant to your CI, testing against LTS branches
> must still be done with the 0.53.2 version, so no change relying on
> post 0.53.2 meson feature gets backported.
>
>

Re: [PATCH 0/5] Increase minimum meson version

[Patrick Robb]

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

Hi Min Zhou,

I think it makes sense for you to set your meson version to the minimum
version supported for DPDK (so, .57 now I suppose) instead of .63. The
principle that David described above regarding LTS is also true for main.
So, for the main and next-* branch testing that Loongson lab does, we want
our CI testing to verify that no change relying on post .57 meson features
get merged into main.

On Tue, Oct 8, 2024 at 9:07 PM zhoumin <zhoumin@loongson.cn> wrote:

> Hi David,
>
> On Tues, Oct 8, 2024 at 8:28AM, David Marchand wrote:
> > Hello CI guys,
> >
> > On Fri, Sep 20, 2024 at 2:57 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> >> This patchset proposed increasing the minimum meson version to 0.57
> >> and makes changes to update our build files appropriately for that
> >> change: replacing deprecated functions, removing unnecessary version
> >> checks and taking advantage of some new capabilities.
> >>
> >> Why 0.57? No one particular reason; it's mainly a conservative version
> >> bump that doesn't have many impacts, but still gives us the minimum
> >> updates we need to replace the deprecated get_cross_properties fn
> >> and have a few extra features guaranteed available.
> >>
> >> Bruce Richardson (5):
> >>    build: increase minimum meson version to 0.57
> >>    build: remove version check on compiler links function
> >>    build: remove unnecessary version checks
> >>    build: use version file support from meson
> >>    build: replace deprecated meson function
> >>
> >>   .ci/linux-setup.sh                        | 2 +-
> >>   config/arm/meson.build                    | 4 ++--
> >>   config/meson.build                        | 8 ++++----
> >>   config/riscv/meson.build                  | 4 ++--
> >>   doc/api/meson.build                       | 2 +-
> >>   doc/guides/linux_gsg/sys_reqs.rst         | 2 +-
> >>   doc/guides/prog_guide/build-sdk-meson.rst | 2 +-
> >>   drivers/common/qat/meson.build            | 2 +-
> >>   drivers/crypto/ipsec_mb/meson.build       | 2 +-
> >>   drivers/event/cnxk/meson.build            | 2 +-
> >>   drivers/meson.build                       | 7 ++-----
> >>   drivers/net/cnxk/meson.build              | 2 +-
> >>   lib/meson.build                           | 6 ------
> >>   meson.build                               | 7 ++-----
> >>   14 files changed, 20 insertions(+), 32 deletions(-)
> > This series can't be merged until the (UNH and LoongArch) CI are ready
> > for such a change.
> >
> > TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
> > in the current release.
> >
> > @UNH @Min Zhou
> > How long would it take for all CI to be ready for this change?
> It's OK for Loongson lab. The meson version for DPDK CI in Loongson lab
> is 0.63.0.
> > Important note: if relevant to your CI, testing against LTS branches
> > must still be done with the 0.53.2 version, so no change relying on
> > post 0.53.2 meson feature gets backported.
> >
> >
>
>

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