[v3,2/2] ci: add travis ci support for aarch64
Checks
Commit Message
Add Travis compilation jobs for aarch64. gcc/clang compilations for
static/shared libraries are added.
Some limitations for current aarch64 Travis support:
1. Container is used. Huge page is not available due to security reason.
2. Missing kernel header package in Xenial distribution.
Solutions to address the limitations:
1. Not to add unit test for now. And run tests with no-huge in future.
2. Use Bionic distribution for all aarch64 jobs.
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
---
.ci/linux-setup.sh | 11 +++++++----
.travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 5 deletions(-)
Comments
Ruifeng Wang <ruifeng.wang@arm.com> writes:
> Add Travis compilation jobs for aarch64. gcc/clang compilations for
> static/shared libraries are added.
>
> Some limitations for current aarch64 Travis support:
> 1. Container is used. Huge page is not available due to security reason.
> 2. Missing kernel header package in Xenial distribution.
>
> Solutions to address the limitations:
> 1. Not to add unit test for now. And run tests with no-huge in future.
> 2. Use Bionic distribution for all aarch64 jobs.
>
> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> ---
Can't we achieve the same thing by setting
arch:
- amd64
- arm64
in the build matrix? Or will that also force the intel builds to use
the container infrastructure (in which case the no-huge support needs to
be fixed)?
One thing I wonder, isn't is possible to use qemu-user to do the amd64
unit tests? Then do we really need some changes to do the native build?
Does it buy us anything *today* given the cost of the hugepage
restriction? Will that ever be resolved (I didn't see so from the
docs on travis)?
> .ci/linux-setup.sh | 11 +++++++----
> .travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
> index dfb9d4a20..a92978037 100755
> --- a/.ci/linux-setup.sh
> +++ b/.ci/linux-setup.sh
> @@ -3,7 +3,10 @@
> # need to install as 'root' since some of the unit tests won't run without it
> sudo python3 -m pip install --upgrade meson
>
> -# setup hugepages
> -cat /proc/meminfo
> -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> -cat /proc/meminfo
> +# hugepage settings are skipped on aarch64 due to environment limitation
> +if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> + # setup hugepages
> + cat /proc/meminfo
> + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> + cat /proc/meminfo
> +fi
> diff --git a/.travis.yml b/.travis.yml
> index 8f90d06f2..980c7605d 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -115,6 +115,46 @@ matrix:
> apt:
> packages:
> - *extra_packages
> -
> + - env: DEF_LIB="static"
> + arch: arm64
> + compiler: gcc
> + dist: bionic
> + addons:
> + apt:
> + packages:
> + - *required_packages
> + - env: DEF_LIB="shared"
> + arch: arm64
> + compiler: gcc
> + dist: bionic
> + addons:
> + apt:
> + packages:
> + - *required_packages
> + - env: DEF_LIB="static"
> + arch: arm64
> + dist: bionic
> + compiler: clang
> + addons:
> + apt:
> + packages:
> + - *required_packages
> + - env: DEF_LIB="shared"
> + arch: arm64
> + dist: bionic
> + compiler: clang
> + addons:
> + apt:
> + packages:
> + - *required_packages
> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> + arch: arm64
> + compiler: gcc
> + dist: bionic
> + addons:
> + apt:
> + packages:
> + - *required_packages
> + - *doc_packages
>
> script: ./.ci/${TRAVIS_OS_NAME}-build.sh
> -----Original Message-----
> From: Aaron Conole <aconole@redhat.com>
> Sent: Monday, January 6, 2020 21:34
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net;
> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org;
> david.marchand@redhat.com; Gavin Hu <Gavin.Hu@arm.com>; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
>
> Ruifeng Wang <ruifeng.wang@arm.com> writes:
>
> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> > static/shared libraries are added.
> >
> > Some limitations for current aarch64 Travis support:
> > 1. Container is used. Huge page is not available due to security reason.
> > 2. Missing kernel header package in Xenial distribution.
> >
> > Solutions to address the limitations:
> > 1. Not to add unit test for now. And run tests with no-huge in future.
> > 2. Use Bionic distribution for all aarch64 jobs.
> >
> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > ---
>
> Can't we achieve the same thing by setting
>
> arch:
> - amd64
> - arm64
>
> in the build matrix? Or will that also force the intel builds to use the container
> infrastructure (in which case the no-huge support needs to be fixed)?
No, container infrastructure will not be imposed to intel builds.
AFAIN, Travis infrastructure for a specific CPU arch is provided as is, and there is no config option to control.
The problem with just adding 'arch' in build matrix is that RUN_TESTS on arm64 is not supported
by now (Travis limitation). 'env' with RUN_TESTS will fail.
>
> One thing I wonder, isn't is possible to use qemu-user to do the amd64 unit
> tests? Then do we really need some changes to do the native build?
Do you mean to use qemu-user to do unit tests for non-x86 arch?
Changes will be needed as well to enable qemu-user to do unit test.
Since Travis support multi CPU arch, I think native build and test is simpler and more natural.
> Does it buy us anything *today* given the cost of the hugepage restriction?
> Will that ever be resolved (I didn't see so from the docs on travis)?
The hugepage issue has been reported to Travis. I think it will be resolved. But no set dates yet.
>
> > .ci/linux-setup.sh | 11 +++++++----
> > .travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
> > 2 files changed, 48 insertions(+), 5 deletions(-)
> >
> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
> > dfb9d4a20..a92978037 100755
> > --- a/.ci/linux-setup.sh
> > +++ b/.ci/linux-setup.sh
> > @@ -3,7 +3,10 @@
> > # need to install as 'root' since some of the unit tests won't run
> > without it sudo python3 -m pip install --upgrade meson
> >
> > -# setup hugepages
> > -cat /proc/meminfo
> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > -cat /proc/meminfo
> > +# hugepage settings are skipped on aarch64 due to environment
> > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> > + # setup hugepages
> > + cat /proc/meminfo
> > + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > + cat /proc/meminfo
> > +fi
> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
> > 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -115,6 +115,46 @@ matrix:
> > apt:
> > packages:
> > - *extra_packages
> > -
> > + - env: DEF_LIB="static"
> > + arch: arm64
> > + compiler: gcc
> > + dist: bionic
> > + addons:
> > + apt:
> > + packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > + arch: arm64
> > + compiler: gcc
> > + dist: bionic
> > + addons:
> > + apt:
> > + packages:
> > + - *required_packages
> > + - env: DEF_LIB="static"
> > + arch: arm64
> > + dist: bionic
> > + compiler: clang
> > + addons:
> > + apt:
> > + packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared"
> > + arch: arm64
> > + dist: bionic
> > + compiler: clang
> > + addons:
> > + apt:
> > + packages:
> > + - *required_packages
> > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> > + arch: arm64
> > + compiler: gcc
> > + dist: bionic
> > + addons:
> > + apt:
> > + packages:
> > + - *required_packages
> > + - *doc_packages
> >
> > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
<snip>
> >
> > > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> > > static/shared libraries are added.
> > >
> > > Some limitations for current aarch64 Travis support:
> > > 1. Container is used. Huge page is not available due to security reason.
> > > 2. Missing kernel header package in Xenial distribution.
> > >
> > > Solutions to address the limitations:
> > > 1. Not to add unit test for now. And run tests with no-huge in future.
> > > 2. Use Bionic distribution for all aarch64 jobs.
> > >
> > > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > ---
> >
> > Can't we achieve the same thing by setting
> >
> > arch:
> > - amd64
> > - arm64
> >
> > in the build matrix? Or will that also force the intel builds to use
> > the container infrastructure (in which case the no-huge support needs to be
> fixed)?
>
> No, container infrastructure will not be imposed to intel builds.
> AFAIN, Travis infrastructure for a specific CPU arch is provided as is, and
> there is no config option to control.
> The problem with just adding 'arch' in build matrix is that RUN_TESTS on
> arm64 is not supported by now (Travis limitation). 'env' with RUN_TESTS will
> fail.
> >
> > One thing I wonder, isn't is possible to use qemu-user to do the amd64
> > unit tests? Then do we really need some changes to do the native build?
>
> Do you mean to use qemu-user to do unit tests for non-x86 arch?
> Changes will be needed as well to enable qemu-user to do unit test.
> Since Travis support multi CPU arch, I think native build and test is simpler
> and more natural.
Yes, prefer to run the tests natively as the infrastructure is available and will improve further from here.
>
> > Does it buy us anything *today* given the cost of the hugepage restriction?
> > Will that ever be resolved (I didn't see so from the docs on travis)?
>
> The hugepage issue has been reported to Travis. I think it will be resolved.
> But no set dates yet.
> >
> > > .ci/linux-setup.sh | 11 +++++++----
> > > .travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 48 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
> > > dfb9d4a20..a92978037 100755
> > > --- a/.ci/linux-setup.sh
> > > +++ b/.ci/linux-setup.sh
> > > @@ -3,7 +3,10 @@
> > > # need to install as 'root' since some of the unit tests won't run
> > > without it sudo python3 -m pip install --upgrade meson
> > >
> > > -# setup hugepages
> > > -cat /proc/meminfo
> > > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > > -cat /proc/meminfo
> > > +# hugepage settings are skipped on aarch64 due to environment
> > > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> > > + # setup hugepages
> > > + cat /proc/meminfo
> > > + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> > > + cat /proc/meminfo
> > > +fi
> > > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
> > > 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -115,6 +115,46 @@ matrix:
> > > apt:
> > > packages:
> > > - *extra_packages
> > > -
> > > + - env: DEF_LIB="static"
> > > + arch: arm64
> > > + compiler: gcc
> > > + dist: bionic
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - *required_packages
> > > + - env: DEF_LIB="shared"
> > > + arch: arm64
> > > + compiler: gcc
> > > + dist: bionic
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - *required_packages
> > > + - env: DEF_LIB="static"
> > > + arch: arm64
> > > + dist: bionic
> > > + compiler: clang
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - *required_packages
> > > + - env: DEF_LIB="shared"
> > > + arch: arm64
> > > + dist: bionic
> > > + compiler: clang
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - *required_packages
> > > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
> > > + arch: arm64
> > > + compiler: gcc
> > > + dist: bionic
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - *required_packages
> > > + - *doc_packages
> > >
> > > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
>
Ruifeng Wang <Ruifeng.Wang@arm.com> writes:
>> -----Original Message-----
>> From: Aaron Conole <aconole@redhat.com>
>> Sent: Monday, January 6, 2020 21:34
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
>> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net;
>> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org;
>> david.marchand@redhat.com; Gavin Hu <Gavin.Hu@arm.com>; Honnappa
>> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
>>
>> Ruifeng Wang <ruifeng.wang@arm.com> writes:
>>
>> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
>> > static/shared libraries are added.
>> >
>> > Some limitations for current aarch64 Travis support:
>> > 1. Container is used. Huge page is not available due to security reason.
>> > 2. Missing kernel header package in Xenial distribution.
>> >
>> > Solutions to address the limitations:
>> > 1. Not to add unit test for now. And run tests with no-huge in future.
>> > 2. Use Bionic distribution for all aarch64 jobs.
>> >
>> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
>> > ---
>>
>> Can't we achieve the same thing by setting
>>
>> arch:
>> - amd64
>> - arm64
>>
>> in the build matrix? Or will that also force the intel builds to use the container
>> infrastructure (in which case the no-huge support needs to be fixed)?
>
> No, container infrastructure will not be imposed to intel builds.
> AFAIN, Travis infrastructure for a specific CPU arch is provided as
> is, and there is no config option to control.
> The problem with just adding 'arch' in build matrix is that RUN_TESTS on arm64 is not supported
> by now (Travis limitation). 'env' with RUN_TESTS will fail.
Okay I see.
>>
>> One thing I wonder, isn't is possible to use qemu-user to do the amd64 unit
>> tests? Then do we really need some changes to do the native build?
>
> Do you mean to use qemu-user to do unit tests for non-x86 arch?
Yes. This has the advantage of giving users a way to also do the
multi-arch checks on their own systems (so a developer with just an x86
could at least do some testing on arm or ppc).
> Changes will be needed as well to enable qemu-user to do unit test.
> Since Travis support multi CPU arch, I think native build and test is simpler and more natural.
I agree, some script changes might be needed, but maybe not as many as
you fear (can't we use binfmt_misc infrastructure to do this with
qemu-user and then the actual 'execute' would work).
>> Does it buy us anything *today* given the cost of the hugepage restriction?
>> Will that ever be resolved (I didn't see so from the docs on travis)?
>
> The hugepage issue has been reported to Travis. I think it will be
> resolved. But no set dates yet.
Is there a plan for them to address? I guess probably not. So we
either need the ability for tests to run in the no-huge environment (and
detect that no hugepages are available to run the tests that way), or we
need the travis environment supporting hugepages. Is there something I
missed?
>>
>> > .ci/linux-setup.sh | 11 +++++++----
>> > .travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
>> > 2 files changed, 48 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
>> > dfb9d4a20..a92978037 100755
>> > --- a/.ci/linux-setup.sh
>> > +++ b/.ci/linux-setup.sh
>> > @@ -3,7 +3,10 @@
>> > # need to install as 'root' since some of the unit tests won't run
>> > without it sudo python3 -m pip install --upgrade meson
>> >
>> > -# setup hugepages
>> > -cat /proc/meminfo
>> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > -cat /proc/meminfo
>> > +# hugepage settings are skipped on aarch64 due to environment
>> > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
>> > + # setup hugepages
>> > + cat /proc/meminfo
>> > + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > + cat /proc/meminfo
>> > +fi
>> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
>> > 100644
>> > --- a/.travis.yml
>> > +++ b/.travis.yml
>> > @@ -115,6 +115,46 @@ matrix:
>> > apt:
>> > packages:
>> > - *extra_packages
>> > -
>> > + - env: DEF_LIB="static"
>> > + arch: arm64
>> > + compiler: gcc
>> > + dist: bionic
>> > + addons:
>> > + apt:
>> > + packages:
>> > + - *required_packages
>> > + - env: DEF_LIB="shared"
>> > + arch: arm64
>> > + compiler: gcc
>> > + dist: bionic
>> > + addons:
>> > + apt:
>> > + packages:
>> > + - *required_packages
>> > + - env: DEF_LIB="static"
>> > + arch: arm64
>> > + dist: bionic
>> > + compiler: clang
>> > + addons:
>> > + apt:
>> > + packages:
>> > + - *required_packages
>> > + - env: DEF_LIB="shared"
>> > + arch: arm64
>> > + dist: bionic
>> > + compiler: clang
>> > + addons:
>> > + apt:
>> > + packages:
>> > + - *required_packages
>> > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
>> > + arch: arm64
>> > + compiler: gcc
>> > + dist: bionic
>> > + addons:
>> > + apt:
>> > + packages:
>> > + - *required_packages
>> > + - *doc_packages
>> >
>> > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:
> <snip>
>
>> >
>> > > Add Travis compilation jobs for aarch64. gcc/clang compilations for
>> > > static/shared libraries are added.
>> > >
>> > > Some limitations for current aarch64 Travis support:
>> > > 1. Container is used. Huge page is not available due to security reason.
>> > > 2. Missing kernel header package in Xenial distribution.
>> > >
>> > > Solutions to address the limitations:
>> > > 1. Not to add unit test for now. And run tests with no-huge in future.
>> > > 2. Use Bionic distribution for all aarch64 jobs.
>> > >
>> > > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
>> > > ---
>> >
>> > Can't we achieve the same thing by setting
>> >
>> > arch:
>> > - amd64
>> > - arm64
>> >
>> > in the build matrix? Or will that also force the intel builds to use
>> > the container infrastructure (in which case the no-huge support needs to be
>> fixed)?
>>
>> No, container infrastructure will not be imposed to intel builds.
>> AFAIN, Travis infrastructure for a specific CPU arch is provided as is, and
>> there is no config option to control.
>> The problem with just adding 'arch' in build matrix is that RUN_TESTS on
>> arm64 is not supported by now (Travis limitation). 'env' with RUN_TESTS will
>> fail.
>> >
>> > One thing I wonder, isn't is possible to use qemu-user to do the amd64
>> > unit tests? Then do we really need some changes to do the native build?
>>
>> Do you mean to use qemu-user to do unit tests for non-x86 arch?
>> Changes will be needed as well to enable qemu-user to do unit test.
>> Since Travis support multi CPU arch, I think native build and test is simpler
>> and more natural.
> Yes, prefer to run the tests natively as the infrastructure is
> available and will improve further from here.
Agreed. But we can't run the aarch64 tests for now, no matter which way
we slice it.
>>
>> > Does it buy us anything *today* given the cost of the hugepage restriction?
>> > Will that ever be resolved (I didn't see so from the docs on travis)?
>>
>> The hugepage issue has been reported to Travis. I think it will be resolved.
>> But no set dates yet.
>> >
>> > > .ci/linux-setup.sh | 11 +++++++----
>> > > .travis.yml | 42 +++++++++++++++++++++++++++++++++++++++++-
>> > > 2 files changed, 48 insertions(+), 5 deletions(-)
>> > >
>> > > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
>> > > dfb9d4a20..a92978037 100755
>> > > --- a/.ci/linux-setup.sh
>> > > +++ b/.ci/linux-setup.sh
>> > > @@ -3,7 +3,10 @@
>> > > # need to install as 'root' since some of the unit tests won't run
>> > > without it sudo python3 -m pip install --upgrade meson
>> > >
>> > > -# setup hugepages
>> > > -cat /proc/meminfo
>> > > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > > -cat /proc/meminfo
>> > > +# hugepage settings are skipped on aarch64 due to environment
>> > > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
>> > > + # setup hugepages
>> > > + cat /proc/meminfo
>> > > + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > > + cat /proc/meminfo
>> > > +fi
>> > > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
>> > > 100644
>> > > --- a/.travis.yml
>> > > +++ b/.travis.yml
>> > > @@ -115,6 +115,46 @@ matrix:
>> > > apt:
>> > > packages:
>> > > - *extra_packages
>> > > -
>> > > + - env: DEF_LIB="static"
>> > > + arch: arm64
>> > > + compiler: gcc
>> > > + dist: bionic
>> > > + addons:
>> > > + apt:
>> > > + packages:
>> > > + - *required_packages
>> > > + - env: DEF_LIB="shared"
>> > > + arch: arm64
>> > > + compiler: gcc
>> > > + dist: bionic
>> > > + addons:
>> > > + apt:
>> > > + packages:
>> > > + - *required_packages
>> > > + - env: DEF_LIB="static"
>> > > + arch: arm64
>> > > + dist: bionic
>> > > + compiler: clang
>> > > + addons:
>> > > + apt:
>> > > + packages:
>> > > + - *required_packages
>> > > + - env: DEF_LIB="shared"
>> > > + arch: arm64
>> > > + dist: bionic
>> > > + compiler: clang
>> > > + addons:
>> > > + apt:
>> > > + packages:
>> > > + - *required_packages
>> > > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
>> > > + arch: arm64
>> > > + compiler: gcc
>> > > + dist: bionic
>> > > + addons:
>> > > + apt:
>> > > + packages:
>> > > + - *required_packages
>> > > + - *doc_packages
>> > >
>> > > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
>>
On Wed, Jan 08, 2020 at 11:05:21AM -0500, Aaron Conole wrote:
> Ruifeng Wang <Ruifeng.Wang@arm.com> writes:
>
> >> -----Original Message-----
> >> From: Aaron Conole <aconole@redhat.com>
> >> Sent: Monday, January 6, 2020 21:34
> >> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> >> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net;
> >> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org;
> >> david.marchand@redhat.com; Gavin Hu <Gavin.Hu@arm.com>; Honnappa
> >> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> >> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
> >>
> >> Ruifeng Wang <ruifeng.wang@arm.com> writes:
> >>
> >> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> >> > static/shared libraries are added.
> >> >
> >> > Some limitations for current aarch64 Travis support:
> >> > 1. Container is used. Huge page is not available due to security reason.
> >> > 2. Missing kernel header package in Xenial distribution.
> >> >
> >> > Solutions to address the limitations:
> >> > 1. Not to add unit test for now. And run tests with no-huge in future.
> >> > 2. Use Bionic distribution for all aarch64 jobs.
> >> >
> >> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> >> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> >> > ---
> >>
> >> Can't we achieve the same thing by setting
> >>
> >> arch:
> >> - amd64
> >> - arm64
> >>
> >> in the build matrix? Or will that also force the intel builds to use the container
> >> infrastructure (in which case the no-huge support needs to be fixed)?
> >
> > No, container infrastructure will not be imposed to intel builds.
> > AFAIN, Travis infrastructure for a specific CPU arch is provided as
> > is, and there is no config option to control.
> > The problem with just adding 'arch' in build matrix is that RUN_TESTS on arm64 is not supported
> > by now (Travis limitation). 'env' with RUN_TESTS will fail.
>
> Okay I see.
>
> >>
> >> One thing I wonder, isn't is possible to use qemu-user to do the amd64 unit
> >> tests? Then do we really need some changes to do the native build?
> >
> > Do you mean to use qemu-user to do unit tests for non-x86 arch?
>
> Yes. This has the advantage of giving users a way to also do the
> multi-arch checks on their own systems (so a developer with just an x86
> could at least do some testing on arm or ppc).
>
> > Changes will be needed as well to enable qemu-user to do unit test.
> > Since Travis support multi CPU arch, I think native build and test is simpler and more natural.
>
> I agree, some script changes might be needed, but maybe not as many as
> you fear (can't we use binfmt_misc infrastructure to do this with
> qemu-user and then the actual 'execute' would work).
>
> >> Does it buy us anything *today* given the cost of the hugepage restriction?
> >> Will that ever be resolved (I didn't see so from the docs on travis)?
> >
> > The hugepage issue has been reported to Travis. I think it will be
> > resolved. But no set dates yet.
>
> Is there a plan for them to address? I guess probably not. So we
> either need the ability for tests to run in the no-huge environment (and
> detect that no hugepages are available to run the tests that way), or we
> need the travis environment supporting hugepages. Is there something I
> missed?
>
I think a reasonable number of tests should already run in a no-huge
environment. Ideally we could have autotest detect the fact it's running
with no-huge and skip all unsupported tests, but I think that would be
quite a bit of work to undertake, given the number of tests there are.
/Bruce
> -----Original Message-----
> From: Aaron Conole <aconole@redhat.com>
> Sent: Thursday, January 9, 2020 00:05
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net;
> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org;
> david.marchand@redhat.com; Gavin Hu <Gavin.Hu@arm.com>; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
>
> Ruifeng Wang <Ruifeng.Wang@arm.com> writes:
>
> >> -----Original Message-----
> >> From: Aaron Conole <aconole@redhat.com>
> >> Sent: Monday, January 6, 2020 21:34
> >> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> >> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net;
> >> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org;
> >> david.marchand@redhat.com; Gavin Hu <Gavin.Hu@arm.com>;
> Honnappa
> >> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> >> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
> >>
> >> Ruifeng Wang <ruifeng.wang@arm.com> writes:
> >>
> >> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
> >> > static/shared libraries are added.
> >> >
> >> > Some limitations for current aarch64 Travis support:
> >> > 1. Container is used. Huge page is not available due to security reason.
> >> > 2. Missing kernel header package in Xenial distribution.
> >> >
> >> > Solutions to address the limitations:
> >> > 1. Not to add unit test for now. And run tests with no-huge in future.
> >> > 2. Use Bionic distribution for all aarch64 jobs.
> >> >
> >> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> >> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> >> > ---
> >>
> >> Can't we achieve the same thing by setting
> >>
> >> arch:
> >> - amd64
> >> - arm64
> >>
> >> in the build matrix? Or will that also force the intel builds to use
> >> the container infrastructure (in which case the no-huge support needs to
> be fixed)?
> >
> > No, container infrastructure will not be imposed to intel builds.
> > AFAIN, Travis infrastructure for a specific CPU arch is provided as
> > is, and there is no config option to control.
> > The problem with just adding 'arch' in build matrix is that RUN_TESTS
> > on arm64 is not supported by now (Travis limitation). 'env' with RUN_TESTS
> will fail.
>
> Okay I see.
>
> >>
> >> One thing I wonder, isn't is possible to use qemu-user to do the
> >> amd64 unit tests? Then do we really need some changes to do the native
> build?
> >
> > Do you mean to use qemu-user to do unit tests for non-x86 arch?
>
> Yes. This has the advantage of giving users a way to also do the multi-arch
> checks on their own systems (so a developer with just an x86 could at least
> do some testing on arm or ppc).
>
Yes, users can do multi-arch checks *locally* by using qemu.
This patch aims to enable *public* CI for aarch64. It has no sense to rely on specific arch while infrastructure
supports multi arch.
> > Changes will be needed as well to enable qemu-user to do unit test.
> > Since Travis support multi CPU arch, I think native build and test is simpler
> and more natural.
>
> I agree, some script changes might be needed, but maybe not as many as
> you fear (can't we use binfmt_misc infrastructure to do this with qemu-user
> and then the actual 'execute' would work).
>
It is more like a tool for local validation, and should be another story.
> >> Does it buy us anything *today* given the cost of the hugepage
> restriction?
> >> Will that ever be resolved (I didn't see so from the docs on travis)?
> >
> > The hugepage issue has been reported to Travis. I think it will be
> > resolved. But no set dates yet.
>
> Is there a plan for them to address? I guess probably not. So we either need
> the ability for tests to run in the no-huge environment (and detect that no
> hugepages are available to run the tests that way), or we need the travis
> environment supporting hugepages. Is there something I missed?
>
Yes, over half of quick tests can run in no-huge environment.
> >>
> >> > .ci/linux-setup.sh | 11 +++++++----
> >> > .travis.yml | 42
> +++++++++++++++++++++++++++++++++++++++++-
> >> > 2 files changed, 48 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
> >> > dfb9d4a20..a92978037 100755
> >> > --- a/.ci/linux-setup.sh
> >> > +++ b/.ci/linux-setup.sh
> >> > @@ -3,7 +3,10 @@
> >> > # need to install as 'root' since some of the unit tests won't run
> >> > without it sudo python3 -m pip install --upgrade meson
> >> >
> >> > -# setup hugepages
> >> > -cat /proc/meminfo
> >> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> >> > -cat /proc/meminfo
> >> > +# hugepage settings are skipped on aarch64 due to environment
> >> > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
> >> > + # setup hugepages
> >> > + cat /proc/meminfo
> >> > + sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> >> > + cat /proc/meminfo
> >> > +fi
> >> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
> >> > 100644
> >> > --- a/.travis.yml
> >> > +++ b/.travis.yml
> >> > @@ -115,6 +115,46 @@ matrix:
> >> > apt:
> >> > packages:
> >> > - *extra_packages
> >> > -
> >> > + - env: DEF_LIB="static"
> >> > + arch: arm64
> >> > + compiler: gcc
> >> > + dist: bionic
> >> > + addons:
> >> > + apt:
> >> > + packages:
> >> > + - *required_packages
> >> > + - env: DEF_LIB="shared"
> >> > + arch: arm64
> >> > + compiler: gcc
> >> > + dist: bionic
> >> > + addons:
> >> > + apt:
> >> > + packages:
> >> > + - *required_packages
> >> > + - env: DEF_LIB="static"
> >> > + arch: arm64
> >> > + dist: bionic
> >> > + compiler: clang
> >> > + addons:
> >> > + apt:
> >> > + packages:
> >> > + - *required_packages
> >> > + - env: DEF_LIB="shared"
> >> > + arch: arm64
> >> > + dist: bionic
> >> > + compiler: clang
> >> > + addons:
> >> > + apt:
> >> > + packages:
> >> > + - *required_packages
> >> > + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
> BUILD_DOCS=1
> >> > + arch: arm64
> >> > + compiler: gcc
> >> > + dist: bionic
> >> > + addons:
> >> > + apt:
> >> > + packages:
> >> > + - *required_packages
> >> > + - *doc_packages
> >> >
> >> > script: ./.ci/${TRAVIS_OS_NAME}-build.sh
<snip>
> > >>
> > >> > Add Travis compilation jobs for aarch64. gcc/clang compilations
> > >> > for static/shared libraries are added.
> > >> >
> > >> > Some limitations for current aarch64 Travis support:
> > >> > 1. Container is used. Huge page is not available due to security reason.
> > >> > 2. Missing kernel header package in Xenial distribution.
> > >> >
> > >> > Solutions to address the limitations:
> > >> > 1. Not to add unit test for now. And run tests with no-huge in future.
> > >> > 2. Use Bionic distribution for all aarch64 jobs.
> > >> >
> > >> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > >> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > >> > ---
> > >>
> > >> Can't we achieve the same thing by setting
> > >>
> > >> arch:
> > >> - amd64
> > >> - arm64
> > >>
> > >> in the build matrix? Or will that also force the intel builds to
> > >> use the container infrastructure (in which case the no-huge support
> > >> needs to
> > be fixed)?
> > >
> > > No, container infrastructure will not be imposed to intel builds.
> > > AFAIN, Travis infrastructure for a specific CPU arch is provided as
> > > is, and there is no config option to control.
> > > The problem with just adding 'arch' in build matrix is that
> > > RUN_TESTS on arm64 is not supported by now (Travis limitation).
> > > 'env' with RUN_TESTS
> > will fail.
> >
> > Okay I see.
> >
> > >>
> > >> One thing I wonder, isn't is possible to use qemu-user to do the
> > >> amd64 unit tests? Then do we really need some changes to do the
> > >> native
> > build?
> > >
> > > Do you mean to use qemu-user to do unit tests for non-x86 arch?
> >
> > Yes. This has the advantage of giving users a way to also do the
> > multi-arch checks on their own systems (so a developer with just an
> > x86 could at least do some testing on arm or ppc).
> >
> Yes, users can do multi-arch checks *locally* by using qemu.
> This patch aims to enable *public* CI for aarch64. It has no sense to rely on
> specific arch while infrastructure supports multi arch.
>
> > > Changes will be needed as well to enable qemu-user to do unit test.
> > > Since Travis support multi CPU arch, I think native build and test
> > > is simpler
> > and more natural.
> >
> > I agree, some script changes might be needed, but maybe not as many as
> > you fear (can't we use binfmt_misc infrastructure to do this with
> > qemu-user and then the actual 'execute' would work).
> >
> It is more like a tool for local validation, and should be another story.
>
> > >> Does it buy us anything *today* given the cost of the hugepage
> > restriction?
> > >> Will that ever be resolved (I didn't see so from the docs on travis)?
> > >
> > > The hugepage issue has been reported to Travis. I think it will be
> > > resolved. But no set dates yet.
> >
> > Is there a plan for them to address? I guess probably not. So we
> > either need the ability for tests to run in the no-huge environment
> > (and detect that no hugepages are available to run the tests that
> > way), or we need the travis environment supporting hugepages. Is there
> something I missed?
> >
> Yes, over half of quick tests can run in no-huge environment.
Plan is to enable the testing for whatever works today and work on fixing the remaining test cases. Is this ok?
<snip>
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:
> <snip>
>
>> > >>
>> > >> > Add Travis compilation jobs for aarch64. gcc/clang compilations
>> > >> > for static/shared libraries are added.
>> > >> >
>> > >> > Some limitations for current aarch64 Travis support:
>> > >> > 1. Container is used. Huge page is not available due to security reason.
>> > >> > 2. Missing kernel header package in Xenial distribution.
>> > >> >
>> > >> > Solutions to address the limitations:
>> > >> > 1. Not to add unit test for now. And run tests with no-huge in future.
>> > >> > 2. Use Bionic distribution for all aarch64 jobs.
>> > >> >
>> > >> > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>> > >> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
>> > >> > ---
>> > >>
>> > >> Can't we achieve the same thing by setting
>> > >>
>> > >> arch:
>> > >> - amd64
>> > >> - arm64
>> > >>
>> > >> in the build matrix? Or will that also force the intel builds to
>> > >> use the container infrastructure (in which case the no-huge support
>> > >> needs to
>> > be fixed)?
>> > >
>> > > No, container infrastructure will not be imposed to intel builds.
>> > > AFAIN, Travis infrastructure for a specific CPU arch is provided as
>> > > is, and there is no config option to control.
>> > > The problem with just adding 'arch' in build matrix is that
>> > > RUN_TESTS on arm64 is not supported by now (Travis limitation).
>> > > 'env' with RUN_TESTS
>> > will fail.
>> >
>> > Okay I see.
>> >
>> > >>
>> > >> One thing I wonder, isn't is possible to use qemu-user to do the
>> > >> amd64 unit tests? Then do we really need some changes to do the
>> > >> native
>> > build?
>> > >
>> > > Do you mean to use qemu-user to do unit tests for non-x86 arch?
>> >
>> > Yes. This has the advantage of giving users a way to also do the
>> > multi-arch checks on their own systems (so a developer with just an
>> > x86 could at least do some testing on arm or ppc).
>> >
>> Yes, users can do multi-arch checks *locally* by using qemu.
>> This patch aims to enable *public* CI for aarch64. It has no sense to rely on
>> specific arch while infrastructure supports multi arch.
>>
>> > > Changes will be needed as well to enable qemu-user to do unit test.
>> > > Since Travis support multi CPU arch, I think native build and test
>> > > is simpler
>> > and more natural.
>> >
>> > I agree, some script changes might be needed, but maybe not as many as
>> > you fear (can't we use binfmt_misc infrastructure to do this with
>> > qemu-user and then the actual 'execute' would work).
>> >
>> It is more like a tool for local validation, and should be another story.
>>
>> > >> Does it buy us anything *today* given the cost of the hugepage
>> > restriction?
>> > >> Will that ever be resolved (I didn't see so from the docs on travis)?
>> > >
>> > > The hugepage issue has been reported to Travis. I think it will be
>> > > resolved. But no set dates yet.
>> >
>> > Is there a plan for them to address? I guess probably not. So we
>> > either need the ability for tests to run in the no-huge environment
>> > (and detect that no hugepages are available to run the tests that
>> > way), or we need the travis environment supporting hugepages. Is there
>> something I missed?
>> >
>> Yes, over half of quick tests can run in no-huge environment.
> Plan is to enable the testing for whatever works today and work on
> fixing the remaining test cases. Is this ok?
Sounds good then.
> <snip>
@@ -3,7 +3,10 @@
# need to install as 'root' since some of the unit tests won't run without it
sudo python3 -m pip install --upgrade meson
-# setup hugepages
-cat /proc/meminfo
-sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
-cat /proc/meminfo
+# hugepage settings are skipped on aarch64 due to environment limitation
+if [ "$TRAVIS_ARCH" != "aarch64" ]; then
+ # setup hugepages
+ cat /proc/meminfo
+ sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
+ cat /proc/meminfo
+fi
@@ -115,6 +115,46 @@ matrix:
apt:
packages:
- *extra_packages
-
+ - env: DEF_LIB="static"
+ arch: arm64
+ compiler: gcc
+ dist: bionic
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - env: DEF_LIB="shared"
+ arch: arm64
+ compiler: gcc
+ dist: bionic
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - env: DEF_LIB="static"
+ arch: arm64
+ dist: bionic
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - env: DEF_LIB="shared"
+ arch: arm64
+ dist: bionic
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
+ arch: arm64
+ compiler: gcc
+ dist: bionic
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - *doc_packages
script: ./.ci/${TRAVIS_OS_NAME}-build.sh