All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>,
	"Ruifeng Wang" <Ruifeng.Wang@arm.com>,
	thomas@monjalon.net
Cc: <dev@dpdk.org>, <stable@dpdk.org>, <viktorin@rehivetech.com>,
	<bruce.richardson@intel.com>, <stephen@networkplumber.org>,
	"Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>,
	"nd" <nd@arm.com>, "nd" <nd@arm.com>
Subject: RE: [PATCH] build: add missing arch define for Arm
Date: Mon, 17 Jan 2022 14:50:20 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86E0C@smartserver.smartshare.dk> (raw)
In-Reply-To: <794237e109494b63b45ba2ceb1f4b8f0@pantheon.tech>

> From: Juraj Linkeš [mailto:juraj.linkes@pantheon.tech]
> Sent: Monday, 17 January 2022 14.12
> 
> > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > Sent: Friday, January 14, 2022 10:05 AM
> >
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Friday, January 14, 2022 1:33 AM
> > >
> > > 17/12/2021 09:54, Ruifeng Wang:
> > > > As per design document, RTE_ARCH is the name of the architecture.
> > > > However, the definition was missing on Arm with meson build.
> > > > It impacts applications that refers to this string.
> > > >
> > > > Added for Arm builds.
> > > >
> > > > Fixes: b1d48c41189a ("build: support ARM with meson")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > ---
> > > >                  ['RTE_ARCH_ARMv8_AARCH32', true],
> > > > +                ['RTE_ARCH', 'arm64_aarch32'],
> > >
> > > Why not armv8_aarch32?
> >
> > Thanks for the comments.
> > Agreed. armv8_aarch32 is consistent with the RTE_ARCH_xx macro above.
> >
> > >
> > > [...]
> > > >          dpdk_conf.set('RTE_ARCH_ARMv7', true)
> > > > +        dpdk_conf.set('RTE_ARCH', 'armv7')
> > > [...]
> > > >      # armv8 build
> > > > +    dpdk_conf.set('RTE_ARCH', 'arm64')
> > >
> > > Why not armv8?
> > >
> > > What I prefer the most in silicon industry is the naming craziness
> :)
> >
> > While armv8 usually refers to one generation of the Arm architecture,
> arm64 is
> > more generic for 64-bit architectures.
> > And what defined for armv8 build is RTE_ARCH_ARM64. So for
> consistency,
> > arm64 is better?
> >
> 
> Using armv8_aarch32 along with arm64 doesn't seem right. We should
> unite these and I think armv8 makes sense. As you mentioned arvm8 is an
> arm64 architecture and using the more precise identification is better
> in my opinion (as that gives more information). As for the consistency
> with RTE_ARCH_ARM64, I think the problem is that we don't have the
> RTE_ARCH_ARMv8 flag (which would provide the consistency, but won't be
> used):
> The current code is, accurately, written for 64bit arm architectures
> (all of them).
> There is currently no need to differentiate between 64bit arm
> architectures which is why RTE_ARCH_ARMv8 doesn't exist.
> However, armv8 exists and we know how to identify it which is why I
> think setting RTE_ARCH to armv8 is the way to go.
> 
> So my thinking is RTE_ARCH should be set to armv8, which implies
> RTE_ARCH_ARMv8 which in turn implies RTE_ARCH_ARM64. We're just missing
> the middle part since there's no use for it now.
> 
> And to be fully consistent, we could add RTE_ARCH_ARM32 to armv7 (as a
> superset of RTE_ARCH_ARMv7, but that likely won't be of much use).
> 

DPDK already has the cross-platform RTE_ARCH_64 and RTE_ARCH_32 to indicate 64/32 bit word size.

You don't need ARM-specific versions of these!



  reply	other threads:[~2022-01-17 13:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  8:54 [PATCH] build: add missing arch define for Arm Ruifeng Wang
2022-01-13 17:32 ` Thomas Monjalon
2022-01-14  9:05   ` Ruifeng Wang
2022-01-14 12:50     ` Thomas Monjalon
2022-01-17 13:12     ` Juraj Linkeš
2022-01-17 13:50       ` Morten Brørup [this message]
2022-01-19  9:44       ` Ruifeng Wang
2022-01-17  7:15 ` [PATCH v2] " Ruifeng Wang
2022-01-19  9:01   ` Thomas Monjalon
2022-01-19  9:51     ` Ruifeng Wang
2022-01-20  2:38 ` [PATCH v3] " Ruifeng Wang
2022-01-20 14:09   ` Thomas Monjalon

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=98CBD80474FA8B44BF855DF32C47DC35D86E0C@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=juraj.linkes@pantheon.tech \
    --cc=nd@arm.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=viktorin@rehivetech.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.