[dpdk-dev] [PATCH] config/arm: add ability to express arch extensions

[dpdk-dev] [PATCH] config/arm: add ability to express arch extensions

[pbhagavatula]

From: Pavan Nikhilesh <pbhagavatula@marvell.com>

The ARM architecture allows SoCs to have extensions in addition
to base profiles such as Large System Extension (LSE), CRC etc.

Add ability to declare SoC specific extensions.

Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---

 More details about ARM extensions
 https://developer.arm.com/documentation/102378/0200

 config/arm/meson.build | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 22cd81319..8aa961e5b 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -230,6 +230,7 @@ soc_cn10k = {
         ['RTE_MAX_LCORE', 24],
         ['RTE_MAX_NUMA_NODES', 1]
     ],
+    'extensions' : ['lse', 'crc'],
     'part_number': '0xd49',
     'numa': false
 }
@@ -387,6 +388,7 @@ else
     endif

     soc_flags = []
+    soc_extensions = []
     if soc_config.has_key('not_supported')
         error('SoC @0@ not supported.'.format(soc))
     elif soc_config != {}
@@ -394,6 +396,7 @@ else
         implementer_config = implementers[implementer_id]
         part_number = soc_config['part_number']
         soc_flags = soc_config.get('flags', [])
+        soc_extensions = soc_config.get('extensions', [])
         if not soc_config.get('numa', true)
             has_libnuma = 0
         endif
@@ -431,6 +434,11 @@ else
     # apply supported machine args
     machine_args = [] # Clear previous machine args
     foreach flag: part_number_config['machine_args']
+        if flag.startswith('-march') and soc_extensions.length() != 0
+            foreach ex: soc_extensions
+                flag += '+' + ex
+            endforeach
+        endif
         if cc.has_argument(flag)
             machine_args += flag
         endif
--
2.17.1

Re: [dpdk-dev] [PATCH] config/arm: add ability to express arch extensions

[Jerin Jacob]

On Wed, May 5, 2021 at 5:44 PM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> The ARM architecture allows SoCs to have extensions in addition
> to base profiles such as Large System Extension (LSE), CRC etc.
>
> Add ability to declare SoC specific extensions.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>


Acked-by: Jerin Jacob <jerinj@marvell.com>



> ---
>
>  More details about ARM extensions
>  https://developer.arm.com/documentation/102378/0200
>
>  config/arm/meson.build | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 22cd81319..8aa961e5b 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -230,6 +230,7 @@ soc_cn10k = {
>          ['RTE_MAX_LCORE', 24],
>          ['RTE_MAX_NUMA_NODES', 1]
>      ],
> +    'extensions' : ['lse', 'crc'],
>      'part_number': '0xd49',
>      'numa': false
>  }
> @@ -387,6 +388,7 @@ else
>      endif
>
>      soc_flags = []
> +    soc_extensions = []
>      if soc_config.has_key('not_supported')
>          error('SoC @0@ not supported.'.format(soc))
>      elif soc_config != {}
> @@ -394,6 +396,7 @@ else
>          implementer_config = implementers[implementer_id]
>          part_number = soc_config['part_number']
>          soc_flags = soc_config.get('flags', [])
> +        soc_extensions = soc_config.get('extensions', [])
>          if not soc_config.get('numa', true)
>              has_libnuma = 0
>          endif
> @@ -431,6 +434,11 @@ else
>      # apply supported machine args
>      machine_args = [] # Clear previous machine args
>      foreach flag: part_number_config['machine_args']
> +        if flag.startswith('-march') and soc_extensions.length() != 0
> +            foreach ex: soc_extensions
> +                flag += '+' + ex
> +            endforeach
> +        endif
>          if cc.has_argument(flag)
>              machine_args += flag
>          endif
> --
> 2.17.1
>

Re: [dpdk-dev] [PATCH] config/arm: add ability to express arch extensions

[Thomas Monjalon]

05/05/2021 14:14, pbhagavatula@marvell.com:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> 
> The ARM architecture allows SoCs to have extensions in addition
> to base profiles such as Large System Extension (LSE), CRC etc.
> 
> Add ability to declare SoC specific extensions.
> 
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>

I don't know what it is fixing. It is an optimization?
Is it candidate for next release?

> ---
> 
>  More details about ARM extensions
>  https://developer.arm.com/documentation/102378/0200
> 
>  config/arm/meson.build | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 22cd81319..8aa961e5b 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -230,6 +230,7 @@ soc_cn10k = {
>          ['RTE_MAX_LCORE', 24],
>          ['RTE_MAX_NUMA_NODES', 1]
>      ],
> +    'extensions' : ['lse', 'crc'],
>      'part_number': '0xd49',
>      'numa': false
>  }
> @@ -387,6 +388,7 @@ else
>      endif
> 
>      soc_flags = []
> +    soc_extensions = []
>      if soc_config.has_key('not_supported')
>          error('SoC @0@ not supported.'.format(soc))
>      elif soc_config != {}
> @@ -394,6 +396,7 @@ else
>          implementer_config = implementers[implementer_id]
>          part_number = soc_config['part_number']
>          soc_flags = soc_config.get('flags', [])
> +        soc_extensions = soc_config.get('extensions', [])
>          if not soc_config.get('numa', true)
>              has_libnuma = 0
>          endif
> @@ -431,6 +434,11 @@ else
>      # apply supported machine args
>      machine_args = [] # Clear previous machine args
>      foreach flag: part_number_config['machine_args']
> +        if flag.startswith('-march') and soc_extensions.length() != 0

Why condition on start with -march?

> +            foreach ex: soc_extensions
> +                flag += '+' + ex
> +            endforeach
> +        endif

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

>05/05/2021 14:14, pbhagavatula@marvell.com:
>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>
>> The ARM architecture allows SoCs to have extensions in addition
>> to base profiles such as Large System Extension (LSE), CRC etc.
>>
>> Add ability to declare SoC specific extensions.
>>
>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
>I don't know what it is fixing. It is an optimization?
>Is it candidate for next release?

Its more of an enhancement, the default n2 march flag doesn't describe 
anything about the extensions that a specific SoC has. 
In case of OCTEON 10 SoC it has support for LSE and CRC in additional to 
the basic n2 profile. 
This patch allows SoC to add extensions to the -march flag.
Default n2 march :    -march=armv8.5-a+crypto+sve2
OCTEON 10 march :  -march=armv8.5-a+crypto+sve2+lse+crc

Including extensions in march helps compiler generate better code.
Example adding '+lse' tells the compiler to inline C11 atomics rather than
having a run time jump

https://gcc.godbolt.org/z/8hPv87dbr

I don't think this is limited to OCTEON 10 other SoC should also add their
extensions to march.

>
>> ---
>>
>>  More details about ARM extensions
>>  https://urldefense.proofpoint.com/v2/url?u=https-
>3A__developer.arm.com_documentation_102378_0200&d=DwICAg&c
>=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDs
>IJzo6FN6Z0&m=yCt4te5_7VJvaJT5OXrOpFXH3UBOUqRDlHZuSVEUZHM
>&s=DquFBMwxMpjxWcM2Qw1c2t_ak-j6DN4rz8ce_I43RJk&e=
>>
>>  config/arm/meson.build | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/config/arm/meson.build b/config/arm/meson.build
>> index 22cd81319..8aa961e5b 100644
>> --- a/config/arm/meson.build
>> +++ b/config/arm/meson.build
>> @@ -230,6 +230,7 @@ soc_cn10k = {
>>          ['RTE_MAX_LCORE', 24],
>>          ['RTE_MAX_NUMA_NODES', 1]
>>      ],
>> +    'extensions' : ['lse', 'crc'],
>>      'part_number': '0xd49',
>>      'numa': false
>>  }
>> @@ -387,6 +388,7 @@ else
>>      endif
>>
>>      soc_flags = []
>> +    soc_extensions = []
>>      if soc_config.has_key('not_supported')
>>          error('SoC @0@ not supported.'.format(soc))
>>      elif soc_config != {}
>> @@ -394,6 +396,7 @@ else
>>          implementer_config = implementers[implementer_id]
>>          part_number = soc_config['part_number']
>>          soc_flags = soc_config.get('flags', [])
>> +        soc_extensions = soc_config.get('extensions', [])
>>          if not soc_config.get('numa', true)
>>              has_libnuma = 0
>>          endif
>> @@ -431,6 +434,11 @@ else
>>      # apply supported machine args
>>      machine_args = [] # Clear previous machine args
>>      foreach flag: part_number_config['machine_args']
>> +        if flag.startswith('-march') and soc_extensions.length() != 0
>
>Why condition on start with -march?

There are some implementer flags which don't have -march to add extensions to.

>
>> +            foreach ex: soc_extensions
>> +                flag += '+' + ex
>> +            endforeach
>> +        endif
>
>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>
> 
> >05/05/2021 14:14, pbhagavatula@marvell.com:
> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>
> >> The ARM architecture allows SoCs to have extensions in addition to
> >> base profiles such as Large System Extension (LSE), CRC etc.
> >>
> >> Add ability to declare SoC specific extensions.
> >>
> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >
> >I don't know what it is fixing. It is an optimization?
> >Is it candidate for next release?
> 
> Its more of an enhancement, the default n2 march flag doesn't describe
> anything about the extensions that a specific SoC has.
> In case of OCTEON 10 SoC it has support for LSE and CRC in additional to the
> basic n2 profile.
> This patch allows SoC to add extensions to the -march flag.
> Default n2 march :    -march=armv8.5-a+crypto+sve2
> OCTEON 10 march :  -march=armv8.5-a+crypto+sve2+lse+crc
> 
> Including extensions in march helps compiler generate better code.
> Example adding '+lse' tells the compiler to inline C11 atomics rather than
> having a run time jump
> 
> https://gcc.godbolt.org/z/8hPv87dbr
Can you compile the code with armv8.5-a instead of armv8-a? I see that LSE instructions are used.
https://gcc.godbolt.org/z/18MYhY7xv

> 
> I don't think this is limited to OCTEON 10 other SoC should also add their
> extensions to march.
> 
> >
> >> ---
> >>
> >>  More details about ARM extensions
> >>  https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__developer.arm.com_documentation_102378_0200&d=DwICAg&c
> >=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDs
> >IJzo6FN6Z0&m=yCt4te5_7VJvaJT5OXrOpFXH3UBOUqRDlHZuSVEUZHM
> >&s=DquFBMwxMpjxWcM2Qw1c2t_ak-j6DN4rz8ce_I43RJk&e=
> >>
> >>  config/arm/meson.build | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> >> 22cd81319..8aa961e5b 100644
> >> --- a/config/arm/meson.build
> >> +++ b/config/arm/meson.build
> >> @@ -230,6 +230,7 @@ soc_cn10k = {
> >>          ['RTE_MAX_LCORE', 24],
> >>          ['RTE_MAX_NUMA_NODES', 1]
> >>      ],
> >> +    'extensions' : ['lse', 'crc'],
> >>      'part_number': '0xd49',
> >>      'numa': false
> >>  }
> >> @@ -387,6 +388,7 @@ else
> >>      endif
> >>
> >>      soc_flags = []
> >> +    soc_extensions = []
> >>      if soc_config.has_key('not_supported')
> >>          error('SoC @0@ not supported.'.format(soc))
> >>      elif soc_config != {}
> >> @@ -394,6 +396,7 @@ else
> >>          implementer_config = implementers[implementer_id]
> >>          part_number = soc_config['part_number']
> >>          soc_flags = soc_config.get('flags', [])
> >> +        soc_extensions = soc_config.get('extensions', [])
> >>          if not soc_config.get('numa', true)
> >>              has_libnuma = 0
> >>          endif
> >> @@ -431,6 +434,11 @@ else
> >>      # apply supported machine args
> >>      machine_args = [] # Clear previous machine args
> >>      foreach flag: part_number_config['machine_args']
> >> +        if flag.startswith('-march') and soc_extensions.length() !=
> >> + 0
> >
> >Why condition on start with -march?
> 
> There are some implementer flags which don't have -march to add extensions
> to.
> 
> >
> >> +            foreach ex: soc_extensions
> >> +                flag += '+' + ex
> >> +            endforeach
> >> +        endif
> >
> >

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

>-----Original Message-----
>From: dev <dev-bounces@dpdk.org> On Behalf Of Honnappa
>Nagarahalli
>Sent: Monday, May 10, 2021 10:51 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>;
>thomas@monjalon.net
>Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
>juraj.linkes@pantheon.tech; Jan Viktorin <viktorin@rehivetech.com>;
>Ruifeng Wang <Ruifeng.Wang@arm.com>; Bruce Richardson
><bruce.richardson@intel.com>; dev@dpdk.org; nd <nd@arm.com>;
>Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd
><nd@arm.com>
>Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to
>express arch extensions
>
><snip>
>>
>> >05/05/2021 14:14, pbhagavatula@marvell.com:
>> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> >>
>> >> The ARM architecture allows SoCs to have extensions in addition to
>> >> base profiles such as Large System Extension (LSE), CRC etc.
>> >>
>> >> Add ability to declare SoC specific extensions.
>> >>
>> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> >
>> >I don't know what it is fixing. It is an optimization?
>> >Is it candidate for next release?
>>
>> Its more of an enhancement, the default n2 march flag doesn't
>describe
>> anything about the extensions that a specific SoC has.
>> In case of OCTEON 10 SoC it has support for LSE and CRC in additional
>to the
>> basic n2 profile.
>> This patch allows SoC to add extensions to the -march flag.
>> Default n2 march :    -march=armv8.5-a+crypto+sve2
>> OCTEON 10 march :  -march=armv8.5-a+crypto+sve2+lse+crc
>>
>> Including extensions in march helps compiler generate better code.
>> Example adding '+lse' tells the compiler to inline C11 atomics rather
>than
>> having a run time jump
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-
>3A__gcc.godbolt.org_z_8hPv87dbr&d=DwIFAg&c=nKjWec2b6R0mOyPa
>z7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=Us6Ig
>UW0QYnSuSc8dYw0yLXgzYvGHoBD8AKNLX0bzhw&s=mk9V9_YgFBdO23
>6JpZBIN_yhCkYAXGcE_1X315c7jGk&e=
>Can you compile the code with armv8.5-a instead of armv8-a? I see that
>LSE instructions are used.

Is LSE extension made mandatory from v8.1? I couldn't find a relevant
documentation on ARM website.

I have seen some compilers not in lining unless 'lse' is mentioned in march.

The patch still holds true for CRC though as it is listed separately below
https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools/feature-names-for-a-profile

Also, looks like sve2 support in n2 core might be optional as per above doc?

>https://urldefense.proofpoint.com/v2/url?u=https-
>3A__gcc.godbolt.org_z_18MYhY7xv&d=DwIFAg&c=nKjWec2b6R0mOyP
>az7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=Us6I
>gUW0QYnSuSc8dYw0yLXgzYvGHoBD8AKNLX0bzhw&s=IpCFzI_hPuBl0P6
>Ylbrfm-1WXvdGg9mwnuzpwC6PrCM&e=
>
>>
>> I don't think this is limited to OCTEON 10 other SoC should also add
>their
>> extensions to march.
>>
>> >
>> >> ---
>> >>
>> >>  More details about ARM extensions
>> >>  https://urldefense.proofpoint.com/v2/url?u=https-
>>
>>3A__developer.arm.com_documentation_102378_0200&d=DwICAg&
>c
>>
>>=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPID
>s
>>
>>IJzo6FN6Z0&m=yCt4te5_7VJvaJT5OXrOpFXH3UBOUqRDlHZuSVEUZH
>M
>> >&s=DquFBMwxMpjxWcM2Qw1c2t_ak-j6DN4rz8ce_I43RJk&e=
>> >>
>> >>  config/arm/meson.build | 8 ++++++++
>> >>  1 file changed, 8 insertions(+)
>> >>
>> >> diff --git a/config/arm/meson.build b/config/arm/meson.build
>index
>> >> 22cd81319..8aa961e5b 100644
>> >> --- a/config/arm/meson.build
>> >> +++ b/config/arm/meson.build
>> >> @@ -230,6 +230,7 @@ soc_cn10k = {
>> >>          ['RTE_MAX_LCORE', 24],
>> >>          ['RTE_MAX_NUMA_NODES', 1]
>> >>      ],
>> >> +    'extensions' : ['lse', 'crc'],
>> >>      'part_number': '0xd49',
>> >>      'numa': false
>> >>  }
>> >> @@ -387,6 +388,7 @@ else
>> >>      endif
>> >>
>> >>      soc_flags = []
>> >> +    soc_extensions = []
>> >>      if soc_config.has_key('not_supported')
>> >>          error('SoC @0@ not supported.'.format(soc))
>> >>      elif soc_config != {}
>> >> @@ -394,6 +396,7 @@ else
>> >>          implementer_config = implementers[implementer_id]
>> >>          part_number = soc_config['part_number']
>> >>          soc_flags = soc_config.get('flags', [])
>> >> +        soc_extensions = soc_config.get('extensions', [])
>> >>          if not soc_config.get('numa', true)
>> >>              has_libnuma = 0
>> >>          endif
>> >> @@ -431,6 +434,11 @@ else
>> >>      # apply supported machine args
>> >>      machine_args = [] # Clear previous machine args
>> >>      foreach flag: part_number_config['machine_args']
>> >> +        if flag.startswith('-march') and soc_extensions.length() !=
>> >> + 0
>> >
>> >Why condition on start with -march?
>>
>> There are some implementer flags which don't have -march to add
>extensions
>> to.
>>
>> >
>> >> +            foreach ex: soc_extensions
>> >> +                flag += '+' + ex
>> >> +            endforeach
>> >> +        endif
>> >
>> >

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>
> >>
> >> >05/05/2021 14:14, pbhagavatula@marvell.com:
> >> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >> >>
> >> >> The ARM architecture allows SoCs to have extensions in addition to
> >> >> base profiles such as Large System Extension (LSE), CRC etc.
> >> >>
> >> >> Add ability to declare SoC specific extensions.
> >> >>
> >> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >> >
> >> >I don't know what it is fixing. It is an optimization?
> >> >Is it candidate for next release?
> >>
> >> Its more of an enhancement, the default n2 march flag doesn't
> >describe
> >> anything about the extensions that a specific SoC has.
> >> In case of OCTEON 10 SoC it has support for LSE and CRC in additional
> >to the
> >> basic n2 profile.
> >> This patch allows SoC to add extensions to the -march flag.
> >> Default n2 march :    -march=armv8.5-a+crypto+sve2
> >> OCTEON 10 march :  -march=armv8.5-a+crypto+sve2+lse+crc
> >>
> >> Including extensions in march helps compiler generate better code.
> >> Example adding '+lse' tells the compiler to inline C11 atomics rather
> >than
> >> having a run time jump
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__gcc.godbolt.org_z_8hPv87dbr&d=DwIFAg&c=nKjWec2b6R0mOyPa
> >z7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=Us6Ig
> >UW0QYnSuSc8dYw0yLXgzYvGHoBD8AKNLX0bzhw&s=mk9V9_YgFBdO23
> >6JpZBIN_yhCkYAXGcE_1X315c7jGk&e=
> >Can you compile the code with armv8.5-a instead of armv8-a? I see that
> >LSE instructions are used.
> 
> Is LSE extension made mandatory from v8.1? I couldn't find a relevant
> documentation on ARM website.
Yes, LSE is mandatory in v8.1. You can refer to Arm-ARM document.

> 
> I have seen some compilers not in lining unless 'lse' is mentioned in march.
If march provided is >= v8.1 the compiler should generate the LSE instructions.

> 
> The patch still holds true for CRC though as it is listed separately below
> https://developer.arm.com/architectures/cpu-architecture/a-
> profile/exploration-tools/feature-names-for-a-profile
> 
> Also, looks like sve2 support in n2 core might be optional as per above doc?
I need to check on this. Some of the info here might not be public yet.

> 
> >https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__gcc.godbolt.org_z_18MYhY7xv&d=DwIFAg&c=nKjWec2b6R0mOyP
> >az7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=Us6I
> >gUW0QYnSuSc8dYw0yLXgzYvGHoBD8AKNLX0bzhw&s=IpCFzI_hPuBl0P6
> >Ylbrfm-1WXvdGg9mwnuzpwC6PrCM&e=
> >
> >>
> >> I don't think this is limited to OCTEON 10 other SoC should also add
> >their
> >> extensions to march.
> >>
> >> >
> >> >> ---
> >> >>
> >> >>  More details about ARM extensions
> >> >>  https://urldefense.proofpoint.com/v2/url?u=https-
> >>
> >>3A__developer.arm.com_documentation_102378_0200&d=DwICAg&
> >c
> >>
> >>=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh745jHNmj2fD85sUMIJ2IPID
> >s
> >>
> >>IJzo6FN6Z0&m=yCt4te5_7VJvaJT5OXrOpFXH3UBOUqRDlHZuSVEUZH
> >M
> >> >&s=DquFBMwxMpjxWcM2Qw1c2t_ak-j6DN4rz8ce_I43RJk&e=
> >> >>
> >> >>  config/arm/meson.build | 8 ++++++++
> >> >>  1 file changed, 8 insertions(+)
> >> >>
> >> >> diff --git a/config/arm/meson.build b/config/arm/meson.build
> >index
> >> >> 22cd81319..8aa961e5b 100644
> >> >> --- a/config/arm/meson.build
> >> >> +++ b/config/arm/meson.build
> >> >> @@ -230,6 +230,7 @@ soc_cn10k = {
> >> >>          ['RTE_MAX_LCORE', 24],
> >> >>          ['RTE_MAX_NUMA_NODES', 1]
> >> >>      ],
> >> >> +    'extensions' : ['lse', 'crc'],
> >> >>      'part_number': '0xd49',
> >> >>      'numa': false
> >> >>  }
> >> >> @@ -387,6 +388,7 @@ else
> >> >>      endif
> >> >>
> >> >>      soc_flags = []
> >> >> +    soc_extensions = []
> >> >>      if soc_config.has_key('not_supported')
> >> >>          error('SoC @0@ not supported.'.format(soc))
> >> >>      elif soc_config != {}
> >> >> @@ -394,6 +396,7 @@ else
> >> >>          implementer_config = implementers[implementer_id]
> >> >>          part_number = soc_config['part_number']
> >> >>          soc_flags = soc_config.get('flags', [])
> >> >> +        soc_extensions = soc_config.get('extensions', [])
> >> >>          if not soc_config.get('numa', true)
> >> >>              has_libnuma = 0
> >> >>          endif
> >> >> @@ -431,6 +434,11 @@ else
> >> >>      # apply supported machine args
> >> >>      machine_args = [] # Clear previous machine args
> >> >>      foreach flag: part_number_config['machine_args']
> >> >> +        if flag.startswith('-march') and soc_extensions.length()
> >> >> + !=
> >> >> + 0
> >> >
> >> >Why condition on start with -march?
> >>
> >> There are some implementer flags which don't have -march to add
> >extensions
> >> to.
> >>
> >> >
> >> >> +            foreach ex: soc_extensions
> >> >> +                flag += '+' + ex
> >> >> +            endforeach
> >> >> +        endif
> >> >
> >> >

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>
> 
> >
> > The patch still holds true for CRC though as it is listed separately
> > below
> > https://developer.arm.com/architectures/cpu-architecture/a-
> > profile/exploration-tools/feature-names-for-a-profile
CRC is mandatory starting in V8.1, refer to Arm-ARM document.

> >
> > Also, looks like sve2 support in n2 core might be optional as per above doc?
> I need to check on this. Some of the info here might not be public yet.
I found [1]. SVE2 is mandatory feature.

[1] https://developer.arm.com/ip-products/processors/neoverse/neoverse-n2

<snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

>
><snip>
>>
>> >
>> > The patch still holds true for CRC though as it is listed separately
>> > below
>> > https://urldefense.proofpoint.com/v2/url?u=https-
>3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMcW
>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&e=
>> > profile/exploration-tools/feature-names-for-a-profile
>CRC is mandatory starting in V8.1, refer to Arm-ARM document.
>
>> >
>> > Also, looks like sve2 support in n2 core might be optional as per
>above doc?
>> I need to check on this. Some of the info here might not be public yet.
>I found [1]. SVE2 is mandatory feature.
>

I see thanks for the info I will remove extension from cnxk.

Do you think the extension infra is still useful for other cases? i.e. older 
cores or cases where vendor wants to enable some extensions by default?

I found a document[1] which describes about extensions not enabled by default but supported by a given march.
In case of n2 I think memory tagging is one such feature

[1]https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/architecture-support


>[1] https://urldefense.proofpoint.com/v2/url?u=https-
>3A__developer.arm.com_ip-
>2Dproducts_processors_neoverse_neoverse-
>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMcW
>d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-3EhTVBabm3SW8&e=
>
><snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>

> >>
> >> >
> >> > The patch still holds true for CRC though as it is listed
> >> > separately below
> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >fmvgGV3o-
> >g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMcW
> >d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&e=
> >> > profile/exploration-tools/feature-names-for-a-profile
> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> >
> >> >
> >> > Also, looks like sve2 support in n2 core might be optional as per
> >above doc?
> >> I need to check on this. Some of the info here might not be public yet.
> >I found [1]. SVE2 is mandatory feature.
> >
> 
> I see thanks for the info I will remove extension from cnxk.
> 
> Do you think the extension infra is still useful for other cases? i.e. older cores
> or cases where vendor wants to enable some extensions by default?
> 
> I found a document[1] which describes about extensions not enabled by
> default but supported by a given march.
> In case of n2 I think memory tagging is one such feature
I think the reference is providing a different information than what you are trying to achieve here.

It looks like you are trying to address a use case where in the same CPU IP has different features enabled/disabled on different SoCs.
This is a valid use case from crypto perspective (due to export control reasons) where-in 2 different SoCs might have crypto enabled/disabled. I am not sure if other features can be enabled/disabled. But, Crypto feature is a good enough reason to address such a use case.

IMO,  we should capture the SoC specific details in SoC specific files, in this case in 'arm64_cn10k_linux_gcc'. I believe there were some challenges in doing this.
Juraj, do you remember the exact issue?

> 
> [1]https://developer.arm.com/tools-and-software/open-source-
> software/developer-tools/gnu-toolchain/architecture-support
> 
> 
> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__developer.arm.com_ip-
> >2Dproducts_processors_neoverse_neoverse-
> >2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >fmvgGV3o-
> >g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMcW
> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-3EhTVBabm3SW8&e=
> >
> ><snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

>> >>
>> >> >
>> >> > The patch still holds true for CRC though as it is listed
>> >> > separately below
>> >> > https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
>> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>> >fmvgGV3o-
>>
>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>W
>>
>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&e
>=
>> >> > profile/exploration-tools/feature-names-for-a-profile
>> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
>> >
>> >> >
>> >> > Also, looks like sve2 support in n2 core might be optional as per
>> >above doc?
>> >> I need to check on this. Some of the info here might not be public
>yet.
>> >I found [1]. SVE2 is mandatory feature.
>> >
>>
>> I see thanks for the info I will remove extension from cnxk.
>>
>> Do you think the extension infra is still useful for other cases? i.e.
>older cores
>> or cases where vendor wants to enable some extensions by default?
>>
>> I found a document[1] which describes about extensions not enabled
>by
>> default but supported by a given march.
>> In case of n2 I think memory tagging is one such feature
>I think the reference is providing a different information than what you
>are trying to achieve here.
>
>It looks like you are trying to address a use case where in the same CPU
>IP has different features enabled/disabled on different SoCs.
>This is a valid use case from crypto perspective (due to export control
>reasons) where-in 2 different SoCs might have crypto
>enabled/disabled. I am not sure if other features can be
>enabled/disabled. But, Crypto feature is a good enough reason to
>address such a use case.

Yes, that's my intension apologies if the commit log doesn't clarify it properly.

>
>IMO,  we should capture the SoC specific details in SoC specific files, in
>this case in 'arm64_cn10k_linux_gcc'. I believe there were some
>challenges in doing this.

Since, all the flags are populated through soc_* variable and arm64_cn10k_linux_gcc
also translates to soc_cn10k I believe the extensions should be reported through 
soc_* variables.

Also, do you think +crypto needs to be removed from default n2 config as its optional?

>Juraj, do you remember the exact issue?
>
>>
>> [1]https://urldefense.proofpoint.com/v2/url?u=https-
>3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource-
>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO-
>oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezPK
>D9oEn7nGFvvgS2ul9ZYx-Kg&e=
>> software/developer-tools/gnu-toolchain/architecture-support
>>
>>
>> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__developer.arm.com_ip-
>> >2Dproducts_processors_neoverse_neoverse-
>>
>>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB
>-
>> >fmvgGV3o-
>>
>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>W
>> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
>3EhTVBabm3SW8&e=
>> >
>> ><snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>

> 
> >> >>
> >> >> >
> >> >> > The patch still holds true for CRC though as it is listed
> >> >> > separately below
> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> >> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >> >fmvgGV3o-
> >>
> >>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> >W
> >>
> >>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&e
> >=
> >> >> > profile/exploration-tools/feature-names-for-a-profile
> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> >> >
> >> >> >
> >> >> > Also, looks like sve2 support in n2 core might be optional as
> >> >> > per
> >> >above doc?
> >> >> I need to check on this. Some of the info here might not be public
> >yet.
> >> >I found [1]. SVE2 is mandatory feature.
> >> >
> >>
> >> I see thanks for the info I will remove extension from cnxk.
> >>
> >> Do you think the extension infra is still useful for other cases? i.e.
> >older cores
> >> or cases where vendor wants to enable some extensions by default?
> >>
> >> I found a document[1] which describes about extensions not enabled
> >by
> >> default but supported by a given march.
> >> In case of n2 I think memory tagging is one such feature
> >I think the reference is providing a different information than what
> >you are trying to achieve here.
> >
> >It looks like you are trying to address a use case where in the same
> >CPU IP has different features enabled/disabled on different SoCs.
> >This is a valid use case from crypto perspective (due to export control
> >reasons) where-in 2 different SoCs might have crypto enabled/disabled.
> >I am not sure if other features can be enabled/disabled. But, Crypto
> >feature is a good enough reason to address such a use case.
> 
> Yes, that's my intension apologies if the commit log doesn't clarify it properly.
> 
> >
> >IMO,  we should capture the SoC specific details in SoC specific files,
> >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some
> >challenges in doing this.
> 
> Since, all the flags are populated through soc_* variable and
> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the extensions
> should be reported through
> soc_* variables.
IMO, there will be more SoCs in the future. I prefer to not grow meson.build. 
> 
> Also, do you think +crypto needs to be removed from default n2 config as its
> optional?
Agree. Better to move it to SoC specific configuration.

> 
> >Juraj, do you remember the exact issue?
> >
> >>
> >> [1]https://urldefense.proofpoint.com/v2/url?u=https-
> >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource-
> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO-
> >oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezPK
> >D9oEn7nGFvvgS2ul9ZYx-Kg&e=
> >> software/developer-tools/gnu-toolchain/architecture-support
> >>
> >>
> >> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__developer.arm.com_ip-
> >> >2Dproducts_processors_neoverse_neoverse-
> >>
> >>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB
> >-
> >> >fmvgGV3o-
> >>
> >>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> >W
> >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
> >3EhTVBabm3SW8&e=
> >> >
> >> ><snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

><snip>
>
>>
>> >> >>
>> >> >> >
>> >> >> > The patch still holds true for CRC though as it is listed
>> >> >> > separately below
>> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
>> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
>> >>
>>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>> >> >fmvgGV3o-
>> >>
>>
>>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>> >W
>> >>
>>
>>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&
>e
>> >=
>> >> >> > profile/exploration-tools/feature-names-for-a-profile
>> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
>> >> >
>> >> >> >
>> >> >> > Also, looks like sve2 support in n2 core might be optional as
>> >> >> > per
>> >> >above doc?
>> >> >> I need to check on this. Some of the info here might not be
>public
>> >yet.
>> >> >I found [1]. SVE2 is mandatory feature.
>> >> >
>> >>
>> >> I see thanks for the info I will remove extension from cnxk.
>> >>
>> >> Do you think the extension infra is still useful for other cases? i.e.
>> >older cores
>> >> or cases where vendor wants to enable some extensions by
>default?
>> >>
>> >> I found a document[1] which describes about extensions not
>enabled
>> >by
>> >> default but supported by a given march.
>> >> In case of n2 I think memory tagging is one such feature
>> >I think the reference is providing a different information than what
>> >you are trying to achieve here.
>> >
>> >It looks like you are trying to address a use case where in the same
>> >CPU IP has different features enabled/disabled on different SoCs.
>> >This is a valid use case from crypto perspective (due to export
>control
>> >reasons) where-in 2 different SoCs might have crypto
>enabled/disabled.
>> >I am not sure if other features can be enabled/disabled. But, Crypto
>> >feature is a good enough reason to address such a use case.
>>
>> Yes, that's my intension apologies if the commit log doesn't clarify it
>properly.
>>
>> >
>> >IMO,  we should capture the SoC specific details in SoC specific files,
>> >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some
>> >challenges in doing this.
>>
>> Since, all the flags are populated through soc_* variable and
>> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the
>extensions
>> should be reported through
>> soc_* variables.
>IMO, there will be more SoCs in the future. I prefer to not grow
>meson.build.

Problem is native build wouldn't read arm64_*_linux_gcc, it will be really 
hard to parse it and read extensions if they are placed there.

>>
>> Also, do you think +crypto needs to be removed from default n2
>config as its
>> optional?
>Agree. Better to move it to SoC specific configuration.
>
>>
>> >Juraj, do you remember the exact issue?
>> >
>> >>
>> >> [1]https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource-
>> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>> >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO-
>>
>>oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezP
>K
>> >D9oEn7nGFvvgS2ul9ZYx-Kg&e=
>> >> software/developer-tools/gnu-toolchain/architecture-support
>> >>
>> >>
>> >> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
>> >> >3A__developer.arm.com_ip-
>> >> >2Dproducts_processors_neoverse_neoverse-
>> >>
>>
>>>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVs
>B
>> >-
>> >> >fmvgGV3o-
>> >>
>>
>>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>> >W
>> >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
>> >3EhTVBabm3SW8&e=
>> >> >
>> >> ><snip>

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Bruce Richardson]

On Wed, May 12, 2021 at 09:17:31AM +0000, Pavan Nikhilesh Bhagavatula wrote:
> 
> ><snip>
> >
> >>
> >> >> >>
> >> >> >> >
> >> >> >> > The patch still holds true for CRC though as it is listed
> >> >> >> > separately below
> >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> >> >>
> >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >> >> >fmvgGV3o-
> >> >>
> >>
> >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> >> >W
> >> >>
> >>
> >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&
> >e
> >> >=
> >> >> >> > profile/exploration-tools/feature-names-for-a-profile
> >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> >> >> >
> >> >> >> >
> >> >> >> > Also, looks like sve2 support in n2 core might be optional as
> >> >> >> > per
> >> >> >above doc?
> >> >> >> I need to check on this. Some of the info here might not be
> >public
> >> >yet.
> >> >> >I found [1]. SVE2 is mandatory feature.
> >> >> >
> >> >>
> >> >> I see thanks for the info I will remove extension from cnxk.
> >> >>
> >> >> Do you think the extension infra is still useful for other cases? i.e.
> >> >older cores
> >> >> or cases where vendor wants to enable some extensions by
> >default?
> >> >>
> >> >> I found a document[1] which describes about extensions not
> >enabled
> >> >by
> >> >> default but supported by a given march.
> >> >> In case of n2 I think memory tagging is one such feature
> >> >I think the reference is providing a different information than what
> >> >you are trying to achieve here.
> >> >
> >> >It looks like you are trying to address a use case where in the same
> >> >CPU IP has different features enabled/disabled on different SoCs.
> >> >This is a valid use case from crypto perspective (due to export
> >control
> >> >reasons) where-in 2 different SoCs might have crypto
> >enabled/disabled.
> >> >I am not sure if other features can be enabled/disabled. But, Crypto
> >> >feature is a good enough reason to address such a use case.
> >>
> >> Yes, that's my intension apologies if the commit log doesn't clarify it
> >properly.
> >>
> >> >
> >> >IMO,  we should capture the SoC specific details in SoC specific files,
> >> >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some
> >> >challenges in doing this.
> >>
> >> Since, all the flags are populated through soc_* variable and
> >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the
> >extensions
> >> should be reported through
> >> soc_* variables.
> >IMO, there will be more SoCs in the future. I prefer to not grow
> >meson.build.
> 
> Problem is native build wouldn't read arm64_*_linux_gcc, it will be really 
> hard to parse it and read extensions if they are placed there.
> 
Since our minimum meson version for DPDK is >0.49, would native-build
files[1] for meson offer a solution here?

/Bruce

[1] https://mesonbuild.com/Native-environments.html

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Juraj Linkeš]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Wednesday, May 12, 2021 11:31 AM
> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj
> Linkeš <juraj.linkes@pantheon.tech>; Jan Viktorin <viktorin@rehivetech.com>;
> Ruifeng Wang <Ruifeng.Wang@arm.com>; dev@dpdk.org; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express
> arch extensions
> 
> On Wed, May 12, 2021 at 09:17:31AM +0000, Pavan Nikhilesh Bhagavatula
> wrote:
> >
> > ><snip>
> > >
> > >>
> > >> >> >>
> > >> >> >> >
> > >> >> >> > The patch still holds true for CRC though as it is listed
> > >> >> >> > separately below
> > >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> > >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> > >> >>
> > >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> > >> >> >fmvgGV3o-
> > >> >>
> > >>
> > >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> > >> >W
> > >> >>
> > >>
> > >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&
> > >e
> > >> >=
> > >> >> >> > profile/exploration-tools/feature-names-for-a-profile
> > >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> > >> >> >
> > >> >> >> >
> > >> >> >> > Also, looks like sve2 support in n2 core might be optional
> > >> >> >> > as per
> > >> >> >above doc?
> > >> >> >> I need to check on this. Some of the info here might not be
> > >public
> > >> >yet.
> > >> >> >I found [1]. SVE2 is mandatory feature.
> > >> >> >
> > >> >>
> > >> >> I see thanks for the info I will remove extension from cnxk.
> > >> >>
> > >> >> Do you think the extension infra is still useful for other cases? i.e.
> > >> >older cores
> > >> >> or cases where vendor wants to enable some extensions by
> > >default?
> > >> >>
> > >> >> I found a document[1] which describes about extensions not
> > >enabled
> > >> >by
> > >> >> default but supported by a given march.
> > >> >> In case of n2 I think memory tagging is one such feature
> > >> >I think the reference is providing a different information than
> > >> >what you are trying to achieve here.
> > >> >
> > >> >It looks like you are trying to address a use case where in the
> > >> >same CPU IP has different features enabled/disabled on different SoCs.
> > >> >This is a valid use case from crypto perspective (due to export
> > >control
> > >> >reasons) where-in 2 different SoCs might have crypto
> > >enabled/disabled.
> > >> >I am not sure if other features can be enabled/disabled. But,
> > >> >Crypto feature is a good enough reason to address such a use case.
> > >>
> > >> Yes, that's my intension apologies if the commit log doesn't
> > >> clarify it
> > >properly.
> > >>
> > >> >
> > >> >IMO,  we should capture the SoC specific details in SoC specific
> > >> >files, in this case in 'arm64_cn10k_linux_gcc'. I believe there
> > >> >were some challenges in doing this.
> > >>
> > >> Since, all the flags are populated through soc_* variable and
> > >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the
> > >extensions
> > >> should be reported through
> > >> soc_* variables.
> > >IMO, there will be more SoCs in the future. I prefer to not grow
> > >meson.build.
> >
> > Problem is native build wouldn't read arm64_*_linux_gcc, it will be
> > really hard to parse it and read extensions if they are placed there.
> >
> Since our minimum meson version for DPDK is >0.49, would native-build files[1]
> for meson offer a solution here?
> 

We need a place to define SoC specific configuration that would be accessible to both native and cross builds. A separate file for each SoC would be great and I've thought about native files in the past where we'd have:
1. an SoC specific file such as soc_armada_config
2. a cross file for each compiler, such as arm64_linux_gcc

This we'd we could use the first file in native builds (and we wouldn't need the platform parameter) and we'd use both files in cross builds.

I have a hazy memory of trying something similar in 0.47.1 (splitting the cross file into SoC config and the rest), but it didn't work, both of the files needed all of the mandatory sections and I suspect this is still true judging from the docs (even for the latest Meson).

> /Bruce
> 
> [1] https://mesonbuild.com/Native-environments.html

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Honnappa Nagarahalli]

<snip>

> > > >
> > > >>
> > > >> >> >>
> > > >> >> >> >
> > > >> >> >> > The patch still holds true for CRC though as it is listed
> > > >> >> >> > separately below
> > > >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> > > >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> > > >> >>
> > > >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> > > >> >> >fmvgGV3o-
> > > >> >>
> > > >>
> > > >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> > > >> >W
> > > >> >>
> > > >>
> > > >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&
> > > >e
> > > >> >=
> > > >> >> >> > profile/exploration-tools/feature-names-for-a-profile
> > > >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> > > >> >> >
> > > >> >> >> >
> > > >> >> >> > Also, looks like sve2 support in n2 core might be
> > > >> >> >> > optional as per
> > > >> >> >above doc?
> > > >> >> >> I need to check on this. Some of the info here might not be
> > > >public
> > > >> >yet.
> > > >> >> >I found [1]. SVE2 is mandatory feature.
> > > >> >> >
> > > >> >>
> > > >> >> I see thanks for the info I will remove extension from cnxk.
> > > >> >>
> > > >> >> Do you think the extension infra is still useful for other cases? i.e.
> > > >> >older cores
> > > >> >> or cases where vendor wants to enable some extensions by
> > > >default?
> > > >> >>
> > > >> >> I found a document[1] which describes about extensions not
> > > >enabled
> > > >> >by
> > > >> >> default but supported by a given march.
> > > >> >> In case of n2 I think memory tagging is one such feature
> > > >> >I think the reference is providing a different information than
> > > >> >what you are trying to achieve here.
> > > >> >
> > > >> >It looks like you are trying to address a use case where in the
> > > >> >same CPU IP has different features enabled/disabled on different
> SoCs.
> > > >> >This is a valid use case from crypto perspective (due to export
> > > >control
> > > >> >reasons) where-in 2 different SoCs might have crypto
> > > >enabled/disabled.
> > > >> >I am not sure if other features can be enabled/disabled. But,
> > > >> >Crypto feature is a good enough reason to address such a use case.
> > > >>
> > > >> Yes, that's my intension apologies if the commit log doesn't
> > > >> clarify it
> > > >properly.
> > > >>
> > > >> >
> > > >> >IMO,  we should capture the SoC specific details in SoC specific
> > > >> >files, in this case in 'arm64_cn10k_linux_gcc'. I believe there
> > > >> >were some challenges in doing this.
> > > >>
> > > >> Since, all the flags are populated through soc_* variable and
> > > >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the
> > > >extensions
> > > >> should be reported through
> > > >> soc_* variables.
> > > >IMO, there will be more SoCs in the future. I prefer to not grow
> > > >meson.build.
> > >
> > > Problem is native build wouldn't read arm64_*_linux_gcc, it will be
> > > really hard to parse it and read extensions if they are placed there.
> > >
> > Since our minimum meson version for DPDK is >0.49, would native-build
> > files[1] for meson offer a solution here?
> >
> 
> We need a place to define SoC specific configuration that would be accessible
> to both native and cross builds. A separate file for each SoC would be great
> and I've thought about native files in the past where we'd have:
> 1. an SoC specific file such as soc_armada_config 2. a cross file for each
> compiler, such as arm64_linux_gcc
> 
> This we'd we could use the first file in native builds (and we wouldn't need the
> platform parameter) and we'd use both files in cross builds.
> 
> I have a hazy memory of trying something similar in 0.47.1 (splitting the cross
> file into SoC config and the rest), but it didn't work, both of the files needed
> all of the mandatory sections and I suspect this is still true judging from the
> docs (even for the latest Meson).
Are we concluding there is no solution?

> 
> > /Bruce
> >
> > [1] https://mesonbuild.com/Native-environments.html
> 

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Thomas Monjalon]

18/05/2021 15:20, Honnappa Nagarahalli:
> Are we concluding there is no solution?

Should I mark this patch as rejected?

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Juraj Linkeš]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Saturday, July 24, 2021 10:52 AM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Bruce Richardson
> <bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; jerinj@marvell.com; Jan Viktorin
> <viktorin@rehivetech.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; nd
> <nd@arm.com>
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express
> arch extensions
> 
> 18/05/2021 15:20, Honnappa Nagarahalli:
> > Are we concluding there is no solution?
> 
> Should I mark this patch as rejected?
> 
> 

Pavan, does my series [0] add what you originally wanted? If so, I think we can drop this patch.

[0] http://patches.dpdk.org/project/dpdk/list/?series=17910

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Pavan Nikhilesh Bhagavatula]

>-----Original Message-----
>From: dev <dev-bounces@dpdk.org> On Behalf Of Juraj Linkeš
>Sent: Tuesday, July 27, 2021 6:35 PM
>To: Thomas Monjalon <thomas@monjalon.net>; Bruce Richardson
><bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
><pbhagavatula@marvell.com>; Honnappa Nagarahalli
><Honnappa.Nagarahalli@arm.com>
>Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
>Jan Viktorin <viktorin@rehivetech.com>; Ruifeng Wang
><Ruifeng.Wang@arm.com>; nd <nd@arm.com>
>Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to
>express arch extensions
>
>
>
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Saturday, July 24, 2021 10:52 AM
>> To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Bruce Richardson
>> <bruce.richardson@intel.com>; Pavan Nikhilesh Bhagavatula
>> <pbhagavatula@marvell.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>
>> Cc: dev@dpdk.org; jerinj@marvell.com; Jan Viktorin
>> <viktorin@rehivetech.com>; Ruifeng Wang
><Ruifeng.Wang@arm.com>; nd
>> <nd@arm.com>
>> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to
>express
>> arch extensions
>>
>> 18/05/2021 15:20, Honnappa Nagarahalli:
>> > Are we concluding there is no solution?
>>
>> Should I mark this patch as rejected?
>>
>>
>
>Pavan, does my series [0] add what you originally wanted? If so, I think
>we can drop this patch.

Sorry, I was travelling and couldn't reply. Yes the series addresses the original 
intent of my patch, we can drop my patch now.

Thanks,
Pavan.

>
>[0] https://urldefense.proofpoint.com/v2/url?u=http-
>3A__patches.dpdk.org_project_dpdk_list_-3Fseries-
>3D17910&d=DwIFBA&c=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh745j
>HNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=BSth2w5D9pmqmZYtfKHTZvy2T
>zm-
>vlIBTESJF0QuoIY&s=rpSmQv_12wMFv7j8a0P6c1_DUfaZyspAdWPOxltgJ
>Hw&e=

Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

[Juraj Linkeš]

> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
> Sent: Wednesday, May 12, 2021 11:18 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> thomas@monjalon.net
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>; Jan Viktorin <viktorin@rehivetech.com>; Ruifeng
> Wang <Ruifeng.Wang@arm.com>; Bruce Richardson
> <bruce.richardson@intel.com>; dev@dpdk.org; nd <nd@arm.com>; nd
> <nd@arm.com>
> Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express
> arch extensions
> 
> 
> ><snip>
> >
> >>
> >> >> >>
> >> >> >> >
> >> >> >> > The patch still holds true for CRC though as it is listed
> >> >> >> > separately below
> >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a-
> >> >>
> >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >> >> >fmvgGV3o-
> >> >>
> >>
> >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> >> >W
> >> >>
> >>
> >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c&
> >e
> >> >=
> >> >> >> > profile/exploration-tools/feature-names-for-a-profile
> >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document.
> >> >> >
> >> >> >> >
> >> >> >> > Also, looks like sve2 support in n2 core might be optional as
> >> >> >> > per
> >> >> >above doc?
> >> >> >> I need to check on this. Some of the info here might not be
> >public
> >> >yet.
> >> >> >I found [1]. SVE2 is mandatory feature.
> >> >> >
> >> >>
> >> >> I see thanks for the info I will remove extension from cnxk.
> >> >>
> >> >> Do you think the extension infra is still useful for other cases? i.e.
> >> >older cores
> >> >> or cases where vendor wants to enable some extensions by
> >default?
> >> >>
> >> >> I found a document[1] which describes about extensions not
> >enabled
> >> >by
> >> >> default but supported by a given march.
> >> >> In case of n2 I think memory tagging is one such feature
> >> >I think the reference is providing a different information than what
> >> >you are trying to achieve here.
> >> >
> >> >It looks like you are trying to address a use case where in the same
> >> >CPU IP has different features enabled/disabled on different SoCs.
> >> >This is a valid use case from crypto perspective (due to export
> >control
> >> >reasons) where-in 2 different SoCs might have crypto
> >enabled/disabled.
> >> >I am not sure if other features can be enabled/disabled. But, Crypto
> >> >feature is a good enough reason to address such a use case.
> >>
> >> Yes, that's my intension apologies if the commit log doesn't clarify
> >> it
> >properly.
> >>
> >> >
> >> >IMO,  we should capture the SoC specific details in SoC specific
> >> >files, in this case in 'arm64_cn10k_linux_gcc'. I believe there were
> >> >some challenges in doing this.
> >>
> >> Since, all the flags are populated through soc_* variable and
> >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the
> >extensions
> >> should be reported through
> >> soc_* variables.
> >IMO, there will be more SoCs in the future. I prefer to not grow
> >meson.build.
> 
> Problem is native build wouldn't read arm64_*_linux_gcc, it will be really hard to
> parse it and read extensions if they are placed there.
> 

Yes, this is the reason we have the SoC configuration in meson.build and not anywhere else. In meson 0.47.1, it was the only way to use SoC config in both native and cross builds. This implies that even these arch extension would need to in meson.build so that we could use those for both native and cross builds.

> >>
> >> Also, do you think +crypto needs to be removed from default n2
> >config as its
> >> optional?
> >Agree. Better to move it to SoC specific configuration.
> >
> >>
> >> >Juraj, do you remember the exact issue?
> >> >
> >> >>
> >> >> [1]https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource-
> >> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
> >> >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO-
> >>
> >>oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezP
> >K
> >> >D9oEn7nGFvvgS2ul9ZYx-Kg&e=
> >> >> software/developer-tools/gnu-toolchain/architecture-support
> >> >>
> >> >>
> >> >> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
> >> >> >3A__developer.arm.com_ip-
> >> >> >2Dproducts_processors_neoverse_neoverse-
> >> >>
> >>
> >>>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVs
> >B
> >> >-
> >> >> >fmvgGV3o-
> >> >>
> >>
> >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
> >> >W
> >> >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
> >> >3EhTVBabm3SW8&e=
> >> >> >
> >> >> ><snip>