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 86D58A04BB; Fri, 25 Sep 2020 00:08:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7DC121DF90; Fri, 25 Sep 2020 00:08:38 +0200 (CEST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by dpdk.org (Postfix) with ESMTP id 878911DEFA for ; Fri, 25 Sep 2020 00:08:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1600985317; x=1632521317; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bIU49sQRkJ3yuLY2s+TahEnSn4XQ/T8X9GVK3+Mr3mU=; b=rFh4UpcO2jiC2Iw+ofoDfo5kB0kqevmiDnz9jovUiy00W1pvAKeYda42 A5t6eFB9Y1njJwtkd4+bSfIVHu37+dHch2dDXEsOTNSmXmw+qB8TA7E4X WvSd2nsLDBXTvEhtnXjZnx6cvoBEZMWZ2kGcLdl+3xWkUkhDlH1k7UWoF k=; X-IronPort-AV: E=Sophos;i="5.77,299,1596499200"; d="scan'208";a="70902784" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 24 Sep 2020 22:08:30 +0000 Received: from EX13MTAUWC002.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (Postfix) with ESMTPS id 1A169A1E59; Thu, 24 Sep 2020 22:08:25 +0000 (UTC) Received: from EX13D02UWC002.ant.amazon.com (10.43.162.6) by EX13MTAUWC002.ant.amazon.com (10.43.162.240) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 22:08:25 +0000 Received: from EX13MTAUWA001.ant.amazon.com (10.43.160.58) by EX13D02UWC002.ant.amazon.com (10.43.162.6) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 22:08:25 +0000 Received: from dev-dsk-alisaidi-i31e-9f3421fe.us-east-1.amazon.com (10.200.138.153) by mail-relay.amazon.com (10.43.160.118) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 24 Sep 2020 22:08:24 +0000 Received: by dev-dsk-alisaidi-i31e-9f3421fe.us-east-1.amazon.com (Postfix, from userid 5131138) id BF15C22904; Thu, 24 Sep 2020 22:08:24 +0000 (UTC) From: Ali Saidi To: CC: , , , , , , , , , Date: Thu, 24 Sep 2020 22:08:24 +0000 Message-ID: <20200924220824.20222-1-alisaidi+dpdk@amazon.com> X-Mailer: git-send-email 2.24.3.AMZN In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Subject: Re: [dpdk-dev] [RFC PATCH 1/2] build: rework Arm build options 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" > > > > > > > > The current system can identify only the implementer and part number > > > > of the arm device we're targeting, which is enough to identify the target > > CPU. > > > > However, even the full MIDR information is not enough to identify > > > > the SoC we're targeting. > > > > > > > > Expand the "machine" meson variable to allow specifying the target arm > > SoC. > > > > The SoC identification implies the CPU, so drop the current MIDR > > > > based CPU identification in favor of user input, which is the only > > > > way to identify the target SoC. This implies that native builds are > > > > not possible. Instead do a default (non-optimized, but executable on > > > > any > > > > aarch64 device) build. I don't think this is really what we want. The MIDR identifies the architecture features that are supported and we should continue to use that for native builds. The difference between SoCs really comes down to the RAM and core count, which are also detectable or could be specified seperately and defaulted to the detected values. > > > > Maybe we can have multiple labels mean the same thing - default, generic, > > armv8 or even generic-armv8 (that's the most descriptive name IMO) could > > all mean the generic arm build executable on all aarch64 SoCs. That many > > names is probably confusing, but sticking to two (default and one more) > > seems feasible. > > > > What does everyone else think? > 'armv8' makes lot more sense to me and it conveys what the build does. We can keep 'default' to be backward compatible, we can skip others. native build below should just be that. Detect the MIDR, use that for the feature flags and use the existing number of CPUs (or a user-specified number). I like generic-armv8 personally beacuse specifies a generic build that won't be optimized.