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 E301DA00B8; Mon, 28 Oct 2019 09:36:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A50611BEFA; Mon, 28 Oct 2019 09:36:52 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id BD55849DF for ; Mon, 28 Oct 2019 09:36:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6EF8621236; Mon, 28 Oct 2019 04:36:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 28 Oct 2019 04:36:47 -0400 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=1rP8Hre6Pd53a2fLdVmG97ak8DZnbm4r6re8+/gn9v4=; b=D9IdakuW45Z9 rhErSOqsb71UrgEpoGn+W3tKTYz1bHGjIxt8fB0Vbhu4K/op8RPYbuev1pWa19sH ZvxPFDLir+bFGsRwHNr72YI6ekUJPKB+p8KqPpgmYhadGmGdNawNkDYVC4pkBeQq kLz0OoGFgBKT4Ip9/n4R0lbVPIrf2/k= 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=1rP8Hre6Pd53a2fLdVmG97ak8DZnbm4r6re8+/gn9 v4=; b=m9MyxIrbmwigud2LJ/1eF9yPTM+Yqh708EpzxgStZKPHKwPOH5+wggDVY FHjYIv9I3KkvFqYtkVF3e8R0L8Q3phRLu88zit6OmL6MTp9Gjhq9UUVlnNzyeG9I nXH8OvuvtpHNUhD21UuAK/Tggiz1F+S8YObOVI+Ht8s5v2RMQWd2udu56kn5VSn6 4PPGlO5CgoJ/bREehan9oaWG0UWehuQsBbzwSIoedXZy1bVluty+QlWngvpWwKHA Ts6FHKPZyQZ/nILSvZ9Ocr+6m3F2+ykNHGFcZ/1t7i+NBog1Ma9jlcw87GGfAKdr HS4ff1WLu12Q+gcOJd7+qZinLOSXA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleekgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpegrrhhmrdgtohhmpdhvrghrshdrmhhkpdhhuhgrrhhmrdgtohhmnecukfhp peejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhoh hmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 9C77480059; Mon, 28 Oct 2019 04:36:45 -0400 (EDT) From: Thomas Monjalon To: Honnappa Nagarahalli Cc: Jerin Jacob , Ola Liljedahl , "Gavin Hu (Arm Technology China)" , "dev@dpdk.org" , "pbhagavatula@marvell.com" , nd , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "bruce.richardson@intel.com" Date: Mon, 28 Oct 2019 09:36:43 +0100 Message-ID: <42494108.RkbLAJnAIz@xps> In-Reply-To: References: <1564615940-13183-1-git-send-email-gavin.hu@arm.com> <2227745.9fKeDGhzLh@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP 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" 28/10/2019 04:24, Honnappa Nagarahalli: > > 23/10/2019 07:03, Jerin Jacob: > > > On Wed, Oct 23, 2019 at 2:37 AM Honnappa Nagarahalli > > > wrote: > > > > > > > On Thu, 2019-08-01 at 07:48 +0800, Gavin Hu wrote: > > > > > > > > Arm N1 SDP is an infrastructure segment development platform > > > > > > > > based on armv8.2-a Neoverse N1 CPU. For more information, refer > > to: > > > > > > > > https://community.arm.com/developer/tools-software/oss-platf > > > > > > > > orms/w > > > > > > > > / > > > > > > > > docs/440/neoverse-n1-sdp > > > > > > > > > > > > > > > > Signed-off-by: Gavin Hu > > > > > > > > Reviewed-by: Honnappa Nagarahalli > > > > > > > > > > > > > > > > Reviewed-by: Steve Capper > > > > > > > > --- > > > > > > > > +CONFIG_RTE_MACHINE="neoversen1" > > > > > > > This should probably be "n1sdp" as this is the name of the > > > > > > > platform that matches the below configuration. > > > > > > A clear definition of RTE_MACHINE is required. Jerin? > > > > > > > > > > I think, In the existing scheme of things, RTE_MACHINE defines, > > > > > where to take the MACHINE_CFLAGS mk/machine/xxxx/rte.vars.mk > > > > Ok, thank you > > > > > > > > > > > > > > Considering the fact that there will be a lot of reusable IPs(for > > > > > CPU) from ARM for armv8, I think, it would make sense to > > > > > introduce RTE_MICRO_ARCH to avoid a lot of code duplications and > > confusion. > > > > > > > > > > RTE_ARCH example: "x86" or "arm64" > > > > > RTE_MICRO_ARCH example: "a72" or "thunderx3" - defines > > > > > mcpu and armv8 verion arch etc > > > > > RTE_MACHINE example: "bluefield" or "thunderx3" > > > > > - defines, number of cores, NUMA or not? etc > > > > Looking at mk/machine/ directory, looks like RTE_MACHINE seems to be > > defining micro-architecture for Intel. For ex: hsw, nhm, wsm. I see the same > > for Arm as well. > > > > Are you suggesting that we use RTE_MICRO_ARCH to pick mk/micro- > > arch/xxxx/rte.vars.mk? and RTE_MACHINE would pick > > mk/machine/xxxx/rte.vars.mk, but contain NUMA, #of cores etc? > > > > > > Yes for Make build. I think, it is deprecated soon, so we need a > > > similar solution for meson. > > > > Yes I would prefer we clean the mess in Meson, instead of talking about the > > makefile system. > > And honestly, N1 is not needed in the legacy makefile system. > Unfortunately, most of the guys I talk to are still on makefile. You need to help them to switch. Adding new targets in meson-only can be a good motivation :) > When is makefile system getting removed? It must be clearly decided and announced. The previous techboard discussions were about making makefile hardly usable during 2020, i.e. very soon. > > So focusing on config/arm/meson.build, > > I think RTE_MACHINE is defined only for API compatibility with makefile. > > However, I doubt this value is used by any application. > > I think we can try to remove RTE_MACHINE from meson builds in DPDK 19.11, > > or use RTE_MACHINE as micro-arch (my preference). > 'MACHINE' means different things to different people, which is the root cause of this discussion. > 'MICRO-ARCH' has a very clear meaning. Do you see any problem going with MICRO-ARCH instead? Some applications may use RTE_MACHINE for this purpose. It is part of the API since the befinning of DPDK. I don't see a real motivation to break this API now.