DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "thomas@monjalon.net" <thomas@monjalon.net>
Cc: Jerin Jacob <jerinjacobk@gmail.com>,
	Ola Liljedahl <Ola.Liljedahl@arm.com>,
	"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"pbhagavatula@marvell.com" <pbhagavatula@marvell.com>,
	nd <nd@arm.com>, "jerinj@marvell.com" <jerinj@marvell.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP configuration
Date: Tue, 29 Oct 2019 05:47:25 +0000	[thread overview]
Message-ID: <VE1PR08MB51491D661ECE16A8851F387F98610@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <42494108.RkbLAJnAIz@xps>

<snip>

> 
> 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
> > > > <Honnappa.Nagarahalli@arm.com> 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-p
> > > > > > > > > latf
> > > > > > > > > orms/w
> > > > > > > > > /
> > > > > > > > > docs/440/neoverse-n1-sdp
> > > > > > > > >
> > > > > > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > ---
> > > > > > > > > +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"
I see that there are already RTE_ARCH_X86, RTE_ARCH_ARM, RTE_ARCH_ARM64, RTE_ARCH_PPC_64 etc. I believe they should be sufficient.

> > > > > > RTE_MICRO_ARCH               example: "a72" or "thunderx3" - defines
> > > > > > mcpu and armv8 verion arch etc
Are you suggesting this just for Arm platforms?
My understanding is your intention was to clean up the config/arm/meson.build file.

> > > > > > 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.
The suggestions are not clear to me. The original suggestion was to introduce RTE_MICRO_ARCH and contain all the micro-architecture related compiler flags in that.
Now, the suggestion is to use RTE_MACHINE to contain micro-architecture related compiler flags. Will it contain NUMA, number of cores as well (as suggested earlier)? If yes, I do not see it changing anything.

I am not a meson expert. However, I looked at various meson.build files. I have few questions/concerns.
1) Are these suggestions are for all the platforms? IMO, these need to be the same across all the architectures.
2) I am looking at config/meson.build. Here RTE_MACHINE is defined to indicate Architecture for Arm (armv7-a, aarchxx) and micro-architecture for x86 (corei7?). Is the understanding correct? IMO, this should this have a common meaning across all the platforms?
3) If the changes are for all the platforms, is the risk high for 19.11 release?
4) The N1 config patch as such conforms to the current conventions. What is being asked here is an enhancement, is the understanding correct?

> 

  reply	other threads:[~2019-10-29  5:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 23:32 [dpdk-dev] [PATCH 1/2] test/rcu: fix the compiling error for armv8.2 Gavin Hu
2019-07-31 23:32 ` [dpdk-dev] [PATCH 2/2] config: add N1SDP configuration Gavin Hu
2019-07-31 23:48 ` [dpdk-dev] [PATCH v2 0/3] add arm neoverse N1 SDP configuration Gavin Hu
2019-07-31 23:48 ` [dpdk-dev] [PATCH v2 1/3] test/rcu: fix the compiling error for armv8.2 Gavin Hu
2019-07-31 23:48 ` [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP configuration Gavin Hu
2019-10-17 22:18   ` Ola Liljedahl
2019-10-18  5:12     ` Honnappa Nagarahalli
2019-10-18  7:23       ` Jerin Jacob
2019-10-22 21:07         ` Honnappa Nagarahalli
2019-10-23  5:03           ` Jerin Jacob
2019-10-27 21:22             ` Thomas Monjalon
2019-10-28  3:24               ` Honnappa Nagarahalli
2019-10-28  8:36                 ` Thomas Monjalon
2019-10-29  5:47                   ` Honnappa Nagarahalli [this message]
2019-11-11  5:06                     ` Gavin Hu (Arm Technology China)
2019-07-31 23:48 ` [dpdk-dev] [PATCH v2 3/3] config: add cortex-a76 configuration Gavin Hu
2019-11-11  5:41 ` [dpdk-dev] [PATCH v3 0/3] add arm N1SDP and A76 configurations Gavin Hu
2019-11-20 22:41   ` Thomas Monjalon
2019-11-11  5:41 ` [dpdk-dev] [PATCH v3 1/3] test/rcu: fix the compiling error for armv8.2 Gavin Hu
2019-11-20 22:18   ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-11-21 11:23     ` Gavin Hu (Arm Technology China)
2019-11-25  3:36   ` [dpdk-dev] [PATCH v4] test/rcu: fix build for small number of cores Gavin Hu
2019-11-25 22:40     ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-11-11  5:41 ` [dpdk-dev] [PATCH v3 2/3] config: add arm neoverse N1 SDP configuration Gavin Hu
2019-11-12  4:23   ` Jerin Jacob
2019-11-14  7:55     ` Gavin Hu (Arm Technology China)
2019-11-14  8:17   ` Jerin Jacob
2019-11-11  5:41 ` [dpdk-dev] [PATCH v3 3/3] config: add cortex-a76 configuration Gavin Hu
2019-11-12  4:24   ` Jerin Jacob
2019-09-11 10:44 [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP configuration Jerin Jacob Kollanukkaran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VE1PR08MB51491D661ECE16A8851F387F98610@VE1PR08MB5149.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Ola.Liljedahl@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=nd@arm.com \
    --cc=pbhagavatula@marvell.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).