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

[Aaron Conole <aconole@redhat.com>]

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>