From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 645FFA0524; Fri, 14 May 2021 13:45:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2A07D40042; Fri, 14 May 2021 13:45:39 +0200 (CEST) Received: from mailgw02.pantheon.sk (mailgw01.pantheon.sk [46.229.239.26]) by mails.dpdk.org (Postfix) with ESMTP id 9E4D040041 for ; Fri, 14 May 2021 13:45:37 +0200 (CEST) Received: from mailgw02.pantheon.sk (localhost.localdomain [127.0.0.1]) by mailgw02.pantheon.sk (Proxmox) with ESMTP id 47AEA18390A; Fri, 14 May 2021 13:45:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=dkim; bh=sWzlU5d0Lgc/wzFdHTNh lYDK2EHX9FKQeTtafVeZzl0=; b=RUBYpx0nKLfTOT8MjVfVUkQRX15ELtSfNr34 DxavQjxYxqm1Q1xlvBlP3dmg1vAsemKU/hM+qgvB6JceijkaaP/RhrZ3/9juV1/0 NWURHwSTPwCRlRuCFnFDMJPuZjg6aXT+QlsrKCPv4UD5j/ucS0ogyBbSc3JpifSf HYEVyZCQJbMDd69cFoX7ROPNNV1tkSiPsCEcpiehW6WYU+TWA0K5YNXIxsmPh+NS pxGhaBSWicKJz41OuVLhHPL5B5j12v8ktIRXi+NLQOe2KCtICJnNvpH1uNTGdWb/ 4NhL23D9SYHYrLTfg8wKIRYh2Qh3+6yvZBeVvEAGQ+Mk/0L3BA== From: =?iso-8859-2?Q?Juraj_Linke=B9?= To: Bruce Richardson , Pavan Nikhilesh Bhagavatula CC: Honnappa Nagarahalli , "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , "Jan Viktorin" , Ruifeng Wang , "dev@dpdk.org" , nd Thread-Topic: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions Thread-Index: AQHXRcTCFROA70whWE6qWqLNflce9qrdFFeAgAAFcACAAMBqgIAAiSaAgAAcogCAAA6lgIAA45aAgAAD4ICAA2Rv8A== Date: Fri, 14 May 2021 11:45:34 +0000 Message-ID: <59d2a824a24a457790362c6d8b25ff9b@pantheon.tech> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.101.4.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" > -----Original Message----- > From: Bruce Richardson > Sent: Wednesday, May 12, 2021 11:31 AM > To: Pavan Nikhilesh Bhagavatula > Cc: Honnappa Nagarahalli ; > thomas@monjalon.net; Jerin Jacob Kollanukkaran ; Jura= j > Linke=B9 ; Jan Viktorin ; > Ruifeng Wang ; dev@dpdk.org; nd > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to expr= ess > arch extensions >=20 > On Wed, May 12, 2021 at 09:17:31AM +0000, Pavan Nikhilesh Bhagavatula > wrote: > > > > > > > > > > >> > > >> >> >> > > >> >> >> > > > >> >> >> > The patch still holds true for CRC though as it is listed > > >> >> >> > separately below > > >> >> >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a- > > >> >> > > >>2D&d=3DDwIFAg&c=3DnKjWec2b6R0mOyPaz7xtfQ&r=3DE3SgYMjtKCMVsB- > > >> >> >fmvgGV3o- > > >> >> > > >> > > >>>g_fjLhk5Pupi9ijohpc&m=3Di3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc > > >> >W > > >> >> > > >> > > >>>d9nAmM&s=3DfA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c& > > >e > > >> >=3D > > >> >> >> > profile/exploration-tools/feature-names-for-a-profile > > >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document. > > >> >> > > > >> >> >> > > > >> >> >> > Also, looks like sve2 support in n2 core might be optional > > >> >> >> > as per > > >> >> >above doc? > > >> >> >> I need to check on this. Some of the info here might not be > > >public > > >> >yet. > > >> >> >I found [1]. SVE2 is mandatory feature. > > >> >> > > > >> >> > > >> >> I see thanks for the info I will remove extension from cnxk. > > >> >> > > >> >> Do you think the extension infra is still useful for other cases?= i.e. > > >> >older cores > > >> >> or cases where vendor wants to enable some extensions by > > >default? > > >> >> > > >> >> I found a document[1] which describes about extensions not > > >enabled > > >> >by > > >> >> default but supported by a given march. > > >> >> In case of n2 I think memory tagging is one such feature > > >> >I think the reference is providing a different information than > > >> >what you are trying to achieve here. > > >> > > > >> >It looks like you are trying to address a use case where in the > > >> >same CPU IP has different features enabled/disabled on different So= Cs. > > >> >This is a valid use case from crypto perspective (due to export > > >control > > >> >reasons) where-in 2 different SoCs might have crypto > > >enabled/disabled. > > >> >I am not sure if other features can be enabled/disabled. But, > > >> >Crypto feature is a good enough reason to address such a use case. > > >> > > >> Yes, that's my intension apologies if the commit log doesn't > > >> clarify it > > >properly. > > >> > > >> > > > >> >IMO, we should capture the SoC specific details in SoC specific > > >> >files, in this case in 'arm64_cn10k_linux_gcc'. I believe there > > >> >were some challenges in doing this. > > >> > > >> Since, all the flags are populated through soc_* variable and > > >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the > > >extensions > > >> should be reported through > > >> soc_* variables. > > >IMO, there will be more SoCs in the future. I prefer to not grow > > >meson.build. > > > > Problem is native build wouldn't read arm64_*_linux_gcc, it will be > > really hard to parse it and read extensions if they are placed there. > > > Since our minimum meson version for DPDK is >0.49, would native-build fil= es[1] > for meson offer a solution here? >=20 We need a place to define SoC specific configuration that would be accessib= le to both native and cross builds. A separate file for each SoC would be g= reat and I've thought about native files in the past where we'd have: 1. an SoC specific file such as soc_armada_config 2. a cross file for each compiler, such as arm64_linux_gcc This we'd we could use the first file in native builds (and we wouldn't nee= d the platform parameter) and we'd use both files in cross builds. I have a hazy memory of trying something similar in 0.47.1 (splitting the c= ross file into SoC config and the rest), but it didn't work, both of the fi= les needed all of the mandatory sections and I suspect this is still true j= udging from the docs (even for the latest Meson). > /Bruce >=20 > [1] https://mesonbuild.com/Native-environments.html