From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: Ruifeng Wang <Ruifeng.Wang@arm.com>, Aaron Conole <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
Gavin Hu <Gavin.Hu@arm.com>, nd <firstname.lastname@example.org>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Subject: Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64
Date: Thu, 9 Jan 2020 15:50:39 +0000 [thread overview]
Message-ID: <VE1PR08MB5149A6186BC4096D33A5174F98390@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
> > >>
> > >> > 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 <email@example.com>
> > >> > Reviewed-by: Gavin Hu <firstname.lastname@example.org>
> > >> > ---
> > >>
> > >> 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?
next prev parent reply other threads:[~2020-01-09 15:50 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
2020-01-09 7:00 ` Ruifeng Wang
2020-01-09 15:50 ` Honnappa Nagarahalli [this message]
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.