From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id BB0EBA04F3; Wed, 8 Jan 2020 18:37:48 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1BF251DAB1; Wed, 8 Jan 2020 18:37:48 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 5D12D1DA72 for ; Wed, 8 Jan 2020 18:37:45 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 09:37:40 -0800 X-IronPort-AV: E=Sophos;i="5.69,410,1571727600"; d="scan'208";a="216020253" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.26]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jan 2020 09:37:38 -0800 Date: Wed, 8 Jan 2020 17:37:35 +0000 From: Bruce Richardson To: Aaron Conole Cc: Ruifeng Wang , "maicolgabriel@hotmail.com" , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , "dev@dpdk.org" , "david.marchand@redhat.com" , Gavin Hu , Honnappa Nagarahalli , nd Message-ID: <20200108173735.GC239@bricha3-MOBL.ger.corp.intel.com> References: <20191218053902.193417-1-ruifeng.wang@arm.com> <20191223070833.144628-1-ruifeng.wang@arm.com> <20191223070833.144628-3-ruifeng.wang@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Subject: Re: [dpdk-dev] [PATCH v3 2/2] ci: add travis ci support for aarch64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jan 08, 2020 at 11:05:21AM -0500, Aaron Conole wrote: > Ruifeng Wang writes: > > >> -----Original Message----- > >> From: Aaron Conole > >> Sent: Monday, January 6, 2020 21:34 > >> To: Ruifeng Wang > >> Cc: maicolgabriel@hotmail.com; thomas@monjalon.net; > >> ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org; > >> david.marchand@redhat.com; Gavin Hu ; Honnappa > >> Nagarahalli ; nd > >> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64 > >> > >> Ruifeng Wang 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 > >> > Reviewed-by: Gavin Hu > >> > --- > >> > >> 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