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 1DA08A04C8; Sat, 19 Sep 2020 21:06:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D89921C1B4; Sat, 19 Sep 2020 21:06:42 +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 AD7321C112 for ; Sat, 19 Sep 2020 21:06:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1600542400; x=1632078400; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Ar9b1HuyQb4DJnqgOqb3uwcCtOeCl0VTbrUrfBb074s=; b=k/RSxg1jyScdZyiPs6uwWPT14OIi2mfei0/nDdbjCXvaQBi/WsRLJW5x Cdke9vwnJ27Vm3ZXgI7KPGWgbBIErmQp46Fx90OLw87nm0+oJoeHjG6fV 9dc5BbgGg1mk9l0Xxf6w4LvfAy06cXA3lCq1M63o9/bJqVB7/ab6dManH E=; X-IronPort-AV: E=Sophos;i="5.77,279,1596499200"; d="scan'208";a="69345294" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-baacba05.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 19 Sep 2020 19:06:38 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-baacba05.us-west-2.amazon.com (Postfix) with ESMTPS id 9F8B6A1886; Sat, 19 Sep 2020 19:06:37 +0000 (UTC) Received: from EX13D02UWB001.ant.amazon.com (10.43.161.240) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 19 Sep 2020 19:06:37 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D02UWB001.ant.amazon.com (10.43.161.240) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 19 Sep 2020 19:06:36 +0000 Received: from dev-dsk-alisaidi-i31e-9f3421fe.us-east-1.amazon.com (10.200.138.153) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Sat, 19 Sep 2020 19:06:35 +0000 Received: by dev-dsk-alisaidi-i31e-9f3421fe.us-east-1.amazon.com (Postfix, from userid 5131138) id 2263C228EB; Sat, 19 Sep 2020 19:06:36 +0000 (UTC) From: Ali Saidi To: CC: , , , , , , , , , , Date: Sat, 19 Sep 2020 19:06:36 +0000 Message-ID: <20200919190636.21686-1-alisaidi+dpdk@amazon.com> X-Mailer: git-send-email 2.24.3.AMZN In-Reply-To: <20200918174203.12155-1-vcchunga@amazon.com> References: <20200918174203.12155-1-vcchunga@amazon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Subject: Re: [dpdk-dev] [PATCH 1/2] config: add Graviton2(arm64) meson configuration 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 9/17/20 9:02 PM, Jerin Jacob wrote: > > On Thu, Sep 17, 2020 at 10:41 PM Honnappa Nagarahalli > wrote: >> >> >> >>>>> >>>>> On 9/11/20 8:23 PM, Honnappa Nagarahalli wrote: >>>>>> >>>>>> +Jerin, Hemant, Dharmik >>>>>> >>>>>> >>>>>> Hi Vimal, >>>>>> Few comments inline. >>>>>> >>>>>>> >>>>>>> Add meson build configuration for Graviton2 platform with 64-bit >>>>>>> ARM Neoverse N1 cores. This patch makes the following changes to >>>>>>> generic Neoverse N1 config: >>>>>>> >>>>>>> 1. increase lcore limit to 64 >>>>>>> 2. increase memory support to 1TB >>>>>> There will be multiple SoCs with N1 cores. All of them will have >>>>>> the same >>>>> implementor ID and part number. But, they will have different values >>>>> for these configurable parameters. >>>>>> IMO, from usage perspective, we have 2 cases: >>>>>> 1) Ability to build a portable binary that can run on multiple Arm >>>>>> SoCs (for ex: BlueField, thunderx1, thunderx2, N1SDP, Graviton2 >>>>>> etc) >>>>>> 2) Ability to build a binary which would run only on a SoC it was >>>>>> compiled >>>>> for and provide the most optimized binary for that SoC. But, this >>>>> may not be portable. >>>>>> >>>>>> For 1) we have default march. >>>>>> >>>>>> For 2) we do not have the capability today in meson build (at >>>>>> least, this is >>>>> my understanding, please correct me if I am wrong). In this case, >>>>> the user knows the target platform for compilation. IMO, we should >>>>> add the capability to take the target platform as an input from the >>>>> user (similar to the make build system) and Graviton2 can be one such >>> target platform. >>>>> >>>>> My intention was to have parameters that work for both N1SDP and >>>>> Graviton2 rather than 2). Does the change to RTE_MAX_LCORE and >>>>> RTE_MAX_MEM_MB make them incompatible with N1SDP? >>>> They are not optimal for N1SDP. In the future these parameters might have >>> to be changed. For ex: if there a N1 based SoC with more than 64 CPU cores. >>> >>> >>> Sorry for the late reply. >>> >>> Looking at the Bluefield, Graviton2, and upcoming SoCs based on ARM IP, It is >>> very clear that MIDR value can not be changed by the silicon vendors. >>> So our existing build scheme of using the MIDR value-based probe does not >>> work anymore with ARM IP. >>> So IMO, We need to change our build scheme. i.e >>> >>> 1) For native build just use -march=native >> I think we do not need the native build. With the native build, it is not possible to identify the SoC and use the correct configuration parameters. For native binaries the answer should be either use -march=native or map the MIDR to the compiler options. The MIDR defines the core and thus the core features and which architecture features the compiler supports. It seems like the only sticking point here is RTE_MAX_MEM_MB and RTE_MAX_LCORE. Is the slight increase in memory size by having a reasonable max for the various SoCs given a single core MIDR (80 seems to be the high number for N1 currently), reason to add complexity and require the user to explicitly pass the system they're compiling for? Thanks, Ali