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

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

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