From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id C0AB31B47B for ; Wed, 9 Jan 2019 14:31:00 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AF4ED2361B; Wed, 9 Jan 2019 08:30:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 09 Jan 2019 08:30:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=6LPO7DYq5JEaZDHL7/G33itIBvx6yS9dcrSRDfSXYuE=; b=MRsvpD7fq4Mk lV7KGE77Nx7AkcNK6DidpsyqWRM3ke8Ad7+wfm7qRqxcywHwxmNGH9XXZ959YErW j28uFyEWu16ni4kHE79dQbXZJum4T5EtPc8PCYgt2v8bObThPSKF463nywtrKbP1 JFT79kUGoDMGxukGyho9Eik/unwUxko= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6LPO7DYq5JEaZDHL7/G33itIBvx6yS9dcrSRDfSXY uE=; b=Ioo+hcx3b9lu2n6CSaW9INWSlSBRi5mS+ark7psRwHTbVsPZ6Fy9Np0F1 9ycRhgbQ1M2DYySLhCdZMVAlE7FUGYXeIMltdUShv60IpKaBvBuMXJ4NUozV7n1A geTDZKoGoftbI6JzT8AMD/7cKMcG8rgtuOFWkynykskzEFAJthkFfkfqS++4EsmH bIj8tcZCdCJsdJJ4H2h5WUNCRD+0PCzXXpIHGEfgx4tfFZrRq7ZlQqPr3Hf+UFJQ YCGzfRih1tn7G87DsO9dhVCr6o/bbH4LaJ/3CpL4ysw1voOcqJ8Lx0itm43BGilo j7m97c9OOOMfVQE9eceVOnXrcxlOw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfedugdehvdculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AAA54E435E; Wed, 9 Jan 2019 08:30:55 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Kollanukkaran , "yskoh@mellanox.com" Cc: "shahafs@mellanox.com" , "honnappa.nagarahalli@arm.com" , "Gavin.Hu@arm.com" , "tspeier@qti.qualcomm.com" , "bluca@debian.org" , "dev@dpdk.org" Date: Wed, 09 Jan 2019 14:30:53 +0100 Message-ID: <3649611.6SvQ7ZztEu@xps> In-Reply-To: References: <20190109093915.40882-1-yskoh@mellanox.com> <1764937.rquPbBeTJo@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] [PATCH] config: change default cache line size for ARMv8 with meson 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: , X-List-Received-Date: Wed, 09 Jan 2019 13:31:01 -0000 09/01/2019 13:47, Jerin Jacob Kollanukkaran: > On Wed, 2019-01-09 at 12:28 +0100, Thomas Monjalon wrote: > > 09/01/2019 11:49, Jerin Jacob Kollanukkaran: > > > On Wed, 2019-01-09 at 10:22 +0000, Yongseok Koh wrote: > > > > On Jan 9, 2019, at 2:09 AM, Jerin Jacob Kollanukkaran wrote: > > > > > I think, I way forward is to add > > > > > config/arm/arm64_a72_linuxapp_gcc > > > > > for meson. This config can be used for all SoC with A72 armv8 > > > > > implementation and may have sym link to specfific SoC to avoid > > > > > confusion to end users. > > > > > > > > Is config/arm/arm64_a72_linuxapp_gcc valid? Others have > > > > > > Yes. For cross compiling for A72. > > > > Any cross-compilation with meson requires a config file. > > The default Arm cross-compilation is done with > > config/arm/arm64_armv8_linuxapp_gcc > > which set implementor_id = 'generic' > > > > For native compilation, implementor_id is detected from > > /sys/devices/system/cpu/cpu0/regs/identification/midr_el1 > > > > So each Arm machine needs 2 things: > > - a cross-compilation file > > - settings based on implementor_id in config/arm/meson.build > > Yes. config/arm/arm64_armv8_linuxapp_gcc sets the implementor_id = > 'generic' which assumed to generic across all the armv8 platform. > If tomorrow there is new core from ARM which A100 with armv8.2 specific > we can not tune the generic params armv8.2 as it will break other > CPU. > > > > > Having not seperate IMPLEMENTOR ID is a chip design issue. > > > > No I don't think it's a design issue. > > If the Arm core has no modification, it does not need to be > > specially identified. > > Thats right. It does not need to be specially identified, > then should have default config is enough. > > > > > > > I think it can work around by creating > > > config/arm/arm64__linuxapp_gcc > > > and build on x86 or arm64 through > > > > > > meson build --cross-file > > > config/arm/arm64__linuxapp_gcc > > > > No, it is a real A72, so it should work with default settings. > > > > The only issue we have is that the default cache line size for > > Aarch64 > > is set to 128 in config/arm/meson.build, and this is wrong. > > The default cache line is 64 bits. > > The cache line size as per ARM spec it is IMPLEMENTATION DEFINED. In A72 spec, it is said "Returns 0b010 to indicate that the cache line size is 64 bytes." But I guess we cannot say it is always true for all models. So let's assume there is no default. > So no default there. So the default is something work on all platforms. > Actually Cavium has machine with 64B and 128B CL and same image should > work on both for generic build. > > > This is already overriden for Cavium machines which have 128-bit > > cache lines. > > It may be needed to do the same change for other machines (Qualcomm?) > > having Arm core modified to 128-bit cache lines. > > Assume you meant 128B here. Yes, sorry I mixed bits and bytes :) > Building the image Naively(on 128B CL > machine) and cross compile (on x86) is not an issue. > > > > > The other concern is about running a generic Arm build. > > Yes. That's the ONLY concern. > > > Given 64-bit should be the default, generic builds will have this > > value. > > Is it a big issue for running generic 64-bit build on Cavium > > machines? > > Cavium has both 64B and 128B CL machines. So putting generic form, > > You can run 128B configured image on 64B machine, It will waste some > memory not beyond that. Other way around will result in HW misbehavior. > ie Running 64B CL image on 128B target. Indeed it is the main concern. Running DPDK tuned for 128 bytes on a core having 64 bytes cache line will result in lower performances. It is less an issue than HW misbehavior. If we agree to keep 128 bytes as generic cache line size for Arm, we need a way to get 64 bytes size for unmodified cores. In other words, the generic build settings must be different of the default settings. Please make a difference between default 'armv8' and 'generic' as implementor_id in config/arm/meson.build. I propose arm64_armv8_linuxapp_gcc being the default config (for armv8) and creating arm64_generic_linuxapp_gcc for the generic build (for distros). OK?