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 F2BFFA0524; Fri, 6 Nov 2020 10:14:26 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9E7C25953; Fri, 6 Nov 2020 10:14:25 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 171E55946 for ; Fri, 6 Nov 2020 10:14:22 +0100 (CET) IronPort-SDR: 56ry8YBRPax7c7KtYpQEYukYory3Yn8jnsNaL2P4fWO34zonec9FzM44CE5cnGjFUeuAfUChMu T8takczJG20w== X-IronPort-AV: E=McAfee;i="6000,8403,9796"; a="168741564" X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="168741564" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2020 01:14:22 -0800 IronPort-SDR: g+yrxHqkr1ob9XFNSFCNvyw9FAQ3zF/CIGjjj8TWU81K2OSgPIfRVrMOEKfekKX1m53C2+rPsP rt49k7vVyQNQ== X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="539771539" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.10.88]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 06 Nov 2020 01:14:17 -0800 Date: Fri, 6 Nov 2020 09:14:12 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Juraj =?utf-8?Q?Linke=C5=A1?= , Ruifeng.Wang@arm.com, Honnappa.Nagarahalli@arm.com, Phil.Yang@arm.com, vcchunga@amazon.com, Dharmik.Thakkar@arm.com, jerinjacobk@gmail.com, hemant.agrawal@nxp.com, ajit.khaparde@broadcom.com, ferruh.yigit@intel.com, aconole@redhat.com, dev@dpdk.org Message-ID: <20201106091412.GA279@bricha3-MOBL.ger.corp.intel.com> References: <1604584762-25321-1-git-send-email-juraj.linkes@pantheon.tech> <1604649795-27476-1-git-send-email-juraj.linkes@pantheon.tech> <98CBD80474FA8B44BF855DF32C47DC35C613F9@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C613F9@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [PATCH v8 00/14] Arm build options rework 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 Fri, Nov 06, 2020 at 09:23:01AM +0100, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Juraj Linkeš Sent: > > Friday, November 6, 2020 9:03 AM > > > > The current way of specifying Arm configuration options is insufficient > > since we can't identify the SoC we're building for from the MIDR > > information. For example, we can't distinguish between N1SDP, Graviton2 > > or Ampere Altra. > > > > Add a way to specify the cpu count and numa node count for cross > > builds. > > > > We also want to be able to disable which drivers (and possibly > > libraries) are built without user input. This is useful when building: > > 1. on an SoC that is slow and we want to build only what is necessary > > without the user having to check which libraries they have installed 2. > > a cross build on a fast aarch64 machine but with target SoC which > > differs in capabilities or libraries. This is achieved by specifying > > the drivers in cross files. > > > > Among libraries, only libnuma can be now disabled. > > > > Also add an optional way to discover cpu count a numa node count. Fix > > -Dmax_lcores and -Dmax_numa_nodes for arm builds. > > > > The current implementation adds/supports the following: * x86 -> > > aarch64 cross build with added config options/disabled drivers/libs * > > aarch64 -> aarch64 builds for a different SoCs must be done using > > cross-files * max numa nodes and max lcore may be specified on the > > command line to overwrite the values for any (native or cross) build > > > > We are cross building our application firmware x86 -> x86. Our firmware > repository includes the cross compiler source code, target libc source > code, and so on. This ensures that the entire firmware is exactly the > same, independently of which host it was built on. > > Back in the days, before we started using DPDK, we validated our cross > building environment by building the complete firmware for our appliance > (including bootloader, Linux kernel, libraries, applications, root file > system, etc.) PPC -> x86. It worked. > > The DPDK cross building system should work in any X -> Y environment, > including X -> X cross building. > It should indeed work for x86 -> x86, but I'm not sure anyone has ever tested it yet. There are no cross-files for x86 included in the DPDK config folder, but it should work fine if you create one for your own setup. Some references, since this should all be handled by meson itself transparently: https://mesonbuild.com/Cross-compilation.html https://mesonbuild.com/Machine-files.html Only problem that I think would arise for x86-x86 would be if we had made some assumptions on the "config/x86/meson.build" file about it being a native build, but hopefully there are few or none of those. If you do get to try out this cross-compile, please let us know how it goes for you. Thanks, /Bruce