From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: pbhagavatula@marvell.com
Cc: jerinj@marvell.com, Ruifeng.Wang@arm.com, nd@arm.com,
Bruce Richardson <bruce.richardson@intel.com>,
dev@dpdk.org
Subject: Re: [PATCH 1/2] config/arm: avoid mcpu and march conflicts
Date: Mon, 22 Jan 2024 11:55:07 +0100 [thread overview]
Message-ID: <CAOb5WZZiSgJim-BNFRoSyVMZMoLRMeZ13qZxog3MLct0h+j=Ww@mail.gmail.com> (raw)
In-Reply-To: <20240121093653.2890-1-pbhagavatula@marvell.com>
On Sun, Jan 21, 2024 at 10:37 AM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> The compiler options march and mtune are a subset
> of mcpu and will lead to conflicts if improper march
> is chosen for a given mcpu.
> To avoid conflicts, force part number march when
> mcpu is available and is supported by the compiler.
>
> Example:
> march = armv9-a
> mcpu = neoverse-n2
>
> mcpu supported, march supported
> machine_args = ['-mcpu=neoverse-n2', '-march=armv9-a']
>
> mcpu supported, march not supported
> machine_args = ['-mcpu=neoverse-n2']
>
> mcpu not supported, march supported
> machine_args = ['-march=armv9-a']
>
> mcpu not supported, march not supported
> machine_args = ['-march=armv8.6-a']
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> config/arm/meson.build | 109 +++++++++++++++++++++++++----------------
> 1 file changed, 67 insertions(+), 42 deletions(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 36f21d2259..8c8cfccca0 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
<snip>
> @@ -127,21 +128,22 @@ implementer_cavium = {
> ],
> 'part_number_config': {
> '0xa1': {
> - 'compiler_options': ['-mcpu=thunderxt88'],
> + 'mcpu': 'thunderxt88',
> 'flags': flags_part_number_thunderx
> },
> '0xa2': {
> - 'compiler_options': ['-mcpu=thunderxt81'],
> + 'mcpu': 'thunderxt81',
> 'flags': flags_part_number_thunderx
> },
> '0xa3': {
> - 'compiler_options': ['-march=armv8-a+crc', '-mcpu=thunderxt83'],
> + 'mcpu': 'thunderxt83',
> + 'compiler_options': ['-march=armv8-a+crc'],
Let's unify this with the rest and specify 'march': 'armv8-a+crc'
instead of having it under compiler_options.
> 'flags': flags_part_number_thunderx
> },
> '0xaf': {
> 'march': 'armv8.1-a',
> 'march_features': ['crc', 'crypto'],
> - 'compiler_options': ['-mcpu=thunderx2t99'],
> + 'mcpu': 'thunderx2t99',
> 'flags': [
> ['RTE_MACHINE', '"thunderx2"'],
> ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -153,7 +155,7 @@ implementer_cavium = {
> '0xb2': {
> 'march': 'armv8.2-a',
> 'march_features': ['crc', 'crypto', 'lse'],
> - 'compiler_options': ['-mcpu=octeontx2'],
> + 'mcpu': 'octeontx2',
> 'flags': [
> ['RTE_MACHINE', '"cn9k"'],
> ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -176,7 +178,7 @@ implementer_ampere = {
> '0x0': {
> 'march': 'armv8-a',
> 'march_features': ['crc', 'crypto'],
> - 'compiler_options': ['-mtune=emag'],
> + 'mcpu': 'emag',
We're changing mtune to mcpu, is this equivalent?
> 'flags': [
> ['RTE_MACHINE', '"eMAG"'],
> ['RTE_MAX_LCORE', 32],
> @@ -186,7 +188,7 @@ implementer_ampere = {
> '0xac3': {
> 'march': 'armv8.6-a',
> 'march_features': ['crc', 'crypto'],
> - 'compiler_options': ['-mcpu=ampere1'],
> + 'mcpu': 'ampere1',
> 'flags': [
> ['RTE_MACHINE', '"AmpereOne"'],
> ['RTE_MAX_LCORE', 320],
> @@ -206,7 +208,7 @@ implementer_hisilicon = {
> '0xd01': {
> 'march': 'armv8.2-a',
> 'march_features': ['crypto'],
> - 'compiler_options': ['-mtune=tsv110'],
> + 'mcpu': 'tsv110',
> 'flags': [
> ['RTE_MACHINE', '"Kunpeng 920"'],
> ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -695,11 +697,23 @@ if update_flags
>
> machine_args = [] # Clear previous machine args
>
> + candidate_mcpu = ''
> + support_mcpu = false
> + if part_number_config.has_key('mcpu')
> + mcpu = part_number_config['mcpu']
> + if (cc.has_argument('-mcpu=' + mcpu))
> + candidate_mcpu = mcpu
> + support_mcpu = true
> + endif
> + endif
> +
> # probe supported archs and their features
> candidate_march = ''
> if part_number_config.has_key('march')
> - if part_number_config.get('force_march', false)
> - candidate_march = part_number_config['march']
> + if part_number_config.get('force_march', false) or support_mcpu
Instead of using the extra "support_mcpu" variable, we could do the
same check as with candidate march (if candidate_mcpu != '', which we
actually do below in the last lines of the patch).
If I understand the logic correctly, we don't want to do the march
fallback if mcpu is specified - either the march works with the given
mcpu or we do without it (because we don't actually need it with
mcpu). Is that correct?
> + if cc.has_argument('-march=' + part_number_config['march'])
Now that we've added mcpu into the mix, is this still the right
condition? Can the below happen?
This check finds that machine_args = ['-march=armv9-a'] is supported.
But taken together with mcpu (machine_args = ['-mcpu=neoverse-n2',
'-march=armv9-a']), it is not supported? In this case we'll end up
with invalid configuration.
> + candidate_march = part_number_config['march']
> + endif
> else
> supported_marchs = ['armv8.6-a', 'armv8.5-a', 'armv8.4-a', 'armv8.3-a',
> 'armv8.2-a', 'armv8.1-a', 'armv8-a']
next prev parent reply other threads:[~2024-01-22 10:55 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-21 9:36 pbhagavatula
2024-01-21 9:36 ` [PATCH 2/2] config/arm: add support for fallback march pbhagavatula
2024-01-22 6:30 ` Ruifeng Wang
2024-01-22 11:04 ` Juraj Linkeš
2024-01-22 12:16 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-01-22 16:29 ` Juraj Linkeš
2024-01-24 15:25 ` Pavan Nikhilesh Bhagavatula
2024-01-22 6:29 ` [PATCH 1/2] config/arm: avoid mcpu and march conflicts Ruifeng Wang
2024-01-22 10:55 ` Juraj Linkeš [this message]
2024-01-22 11:54 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-01-22 16:26 ` Juraj Linkeš
2024-01-24 15:21 ` Pavan Nikhilesh Bhagavatula
2024-01-29 8:44 ` Juraj Linkeš
2024-01-30 16:16 ` Pavan Nikhilesh Bhagavatula
2024-01-31 9:03 ` Juraj Linkeš
2024-02-01 21:57 ` [PATCH v2 1/3] " pbhagavatula
2024-02-01 21:57 ` [PATCH v2 2/3] config/arm: add support for fallback march pbhagavatula
2024-02-01 21:57 ` [PATCH v2 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-02-07 2:55 ` Honnappa Nagarahalli
2024-02-10 6:47 ` Pavan Nikhilesh Bhagavatula
2024-02-10 16:36 ` Honnappa Nagarahalli
2024-02-10 16:40 ` Pavan Nikhilesh Bhagavatula
2024-02-02 8:50 ` [PATCH v3 1/3] config/arm: avoid mcpu and march conflicts pbhagavatula
2024-02-02 8:50 ` [PATCH v3 2/3] config/arm: add support for fallback march pbhagavatula
2024-02-07 20:24 ` Wathsala Wathawana Vithanage
2024-02-02 8:50 ` [PATCH v3 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-02-10 16:56 ` Honnappa Nagarahalli
2024-02-12 19:21 ` Wathsala Wathawana Vithanage
2024-02-06 4:10 ` [PATCH v3 1/3] config/arm: avoid mcpu and march conflicts Wathsala Wathawana Vithanage
2024-02-06 4:44 ` Honnappa Nagarahalli
2024-02-06 10:21 ` Pavan Nikhilesh Bhagavatula
2024-02-07 0:01 ` Wathsala Wathawana Vithanage
2024-02-10 6:49 ` Pavan Nikhilesh Bhagavatula
2024-02-10 15:20 ` Honnappa Nagarahalli
2024-02-10 17:21 ` Honnappa Nagarahalli
2024-02-21 20:20 ` [PATCH v4 " pbhagavatula
2024-02-21 20:20 ` [PATCH v4 2/3] config/arm: add support for fallback march pbhagavatula
2024-02-22 10:47 ` Juraj Linkeš
2024-02-22 12:32 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 20:20 ` [PATCH v4 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-02-22 9:37 ` [PATCH v4 1/3] config/arm: avoid mcpu and march conflicts Juraj Linkeš
2024-02-22 9:49 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-22 12:45 ` [PATCH v5 " pbhagavatula
2024-02-22 12:45 ` [PATCH v5 2/3] config/arm: add support for fallback march pbhagavatula
2024-02-23 11:49 ` Juraj Linkeš
2024-02-26 7:11 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26 7:31 ` Juraj Linkeš
2024-02-26 7:34 ` Juraj Linkeš
2024-02-22 12:45 ` [PATCH v5 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-02-23 11:19 ` [PATCH v5 1/3] config/arm: avoid mcpu and march conflicts Juraj Linkeš
2024-02-26 7:08 ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26 7:38 ` [PATCH v6 " pbhagavatula
2024-02-26 7:38 ` [PATCH v6 2/3] config/arm: add support for fallback march pbhagavatula
2024-02-26 7:38 ` [PATCH v6 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-03-06 15:49 ` [PATCH v7 1/3] config/arm: avoid mcpu and march conflicts pbhagavatula
2024-03-06 15:49 ` [PATCH v7 2/3] config/arm: add support for fallback march pbhagavatula
2024-03-06 15:49 ` [PATCH v7 3/3] config/arm: allow WFE to be enabled config time pbhagavatula
2024-03-07 3:57 ` [PATCH v7 1/3] config/arm: avoid mcpu and march conflicts Pavan Nikhilesh Bhagavatula
2024-03-14 11:38 ` [PATCH v8 1/5] " pbhagavatula
2024-03-14 11:38 ` [PATCH v8 2/5] config/arm: add armv9-a march support pbhagavatula
2024-03-14 11:38 ` [PATCH v8 3/5] config/arm: add crypto march feature to thunderxt83 pbhagavatula
2024-03-14 12:00 ` Jerin Jacob
2024-03-14 11:38 ` [PATCH v8 4/5] config/arm: add support for fallback march pbhagavatula
2024-03-14 11:38 ` [PATCH v8 5/5] config/arm: allow WFE to be enabled config time pbhagavatula
2024-03-15 11:17 ` [PATCH v8 1/5] config/arm: avoid mcpu and march conflicts 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='CAOb5WZZiSgJim-BNFRoSyVMZMoLRMeZ13qZxog3MLct0h+j=Ww@mail.gmail.com' \
--to=juraj.linkes@pantheon.tech \
--cc=Ruifeng.Wang@arm.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=nd@arm.com \
--cc=pbhagavatula@marvell.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 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).