Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64

[Bruce Richardson <bruce.richardson@intel.com>]

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