From: Bruce Richardson <email@example.com>
To: Aaron Conole <firstname.lastname@example.org>
Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>,
Gavin Hu <Gavin.Hu@arm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Subject: Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64
Date: Wed, 8 Jan 2020 17:37:35 +0000 [thread overview]
Message-ID: <20200108173735.GC239@bricha3-MOBL.ger.corp.intel.com> (raw)
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 <email@example.com>
> >> Sent: Monday, January 6, 2020 21:34
> >> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> >> Cc: firstname.lastname@example.org; email@example.com;
> >> firstname.lastname@example.org; email@example.com; firstname.lastname@example.org;
> >> email@example.com; Gavin Hu <Gavin.Hu@arm.com>; Honnappa
> >> Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd <firstname.lastname@example.org>
> >> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
> >> Ruifeng Wang <email@example.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 <firstname.lastname@example.org>
> >> > Reviewed-by: Gavin Hu <email@example.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
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.
next prev parent reply other threads:[~2020-01-08 17:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 5:39 [dpdk-dev] [PATCH 0/2] add travis ci support for aarch64 Ruifeng Wang
2019-12-18 5:39 ` [dpdk-dev] [PATCH 1/2] ci: " Ruifeng Wang
2019-12-18 5:39 ` [dpdk-dev] [PATCH 2/2] devtools: add path to additional shared object files Ruifeng Wang
2019-12-18 8:23 ` David Marchand
2019-12-18 13:43 ` Laatz, Kevin
2019-12-18 15:32 ` David Marchand
2019-12-18 16:00 ` Richardson, Bruce
2019-12-19 3:14 ` Ruifeng Wang
2019-12-20 9:37 ` [dpdk-dev] [PATCH v2 0/2] add travis ci support for aarch64 Ruifeng Wang
2019-12-20 9:37 ` [dpdk-dev] [PATCH v2 1/2] ci: " Ruifeng Wang
2020-01-06 20:17 ` dwilder
2020-01-07 6:42 ` Ruifeng Wang
2019-12-20 9:37 ` [dpdk-dev] [PATCH v2 2/2] devtools: add path to additional shared object files Ruifeng Wang
2019-12-20 13:57 ` [dpdk-dev] [PATCH v2 0/2] add travis ci support for aarch64 David Marchand
2019-12-23 7:08 ` [dpdk-dev] [PATCH v3 " Ruifeng Wang
2019-12-23 7:08 ` [dpdk-dev] [PATCH v3 1/2] devtools: add path to additional shared object files Ruifeng Wang
2019-12-23 7:08 ` [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64 Ruifeng Wang
2020-01-06 13:34 ` Aaron Conole
2020-01-07 6:24 ` Ruifeng Wang
2020-01-07 14:40 ` Honnappa Nagarahalli
2020-01-08 16:06 ` Aaron Conole
2020-01-08 16:05 ` Aaron Conole
2020-01-08 17:37 ` Bruce Richardson [this message]
2020-01-09 7:00 ` Ruifeng Wang
2020-01-09 15:50 ` Honnappa Nagarahalli
2020-01-09 17:45 ` Aaron Conole
2020-01-10 9:53 ` [dpdk-dev] [PATCH v4 0/2] " Ruifeng Wang
2020-01-10 9:53 ` [dpdk-dev] [PATCH v4 1/2] devtools: add path to additional shared object files Ruifeng Wang
2020-01-10 15:03 ` Aaron Conole
2020-01-10 9:53 ` [dpdk-dev] [PATCH v4 2/2] ci: add travis ci support for aarch64 Ruifeng Wang
2020-01-10 15:13 ` Aaron Conole
2020-01-13 6:09 ` Ruifeng Wang
2020-01-13 6:26 ` [dpdk-dev] [PATCH v5 0/2] add travis ci support for native aarch64 Ruifeng Wang
2020-01-13 6:26 ` [dpdk-dev] [PATCH v5 1/2] devtools: add path to additional shared object files Ruifeng Wang
2020-01-13 6:26 ` [dpdk-dev] [PATCH v5 2/2] ci: add travis ci support for native aarch64 Ruifeng Wang
2020-01-14 14:03 ` [dpdk-dev] [PATCH v5 0/2] " David Marchand
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.