<snip>

> >>
> >> On 4/21/2023 3:54 PM, Nipun Gupta wrote:
> >>> Adding support for AMD CDX devices
> >>>
> >>> Signed-off-by: Nipun Gupta <nipun.gu...@amd.com>
> >>> ---
> >>>  config/arm/arm64_cdx_linux_gcc | 17 +++++++++++++++++
> >>>  config/arm/meson.build         | 14 ++++++++++++++
> >>>  2 files changed, 31 insertions(+)
> >>>  create mode 100644 config/arm/arm64_cdx_linux_gcc
> >>>
> >>> diff --git a/config/arm/arm64_cdx_linux_gcc
> >> b/config/arm/arm64_cdx_linux_gcc
> >>> new file mode 100644
> >>> index 0000000000..8e6d619dae
> >>> --- /dev/null
> >>> +++ b/config/arm/arm64_cdx_linux_gcc
> >>> @@ -0,0 +1,17 @@
> >>> +[binaries]
> >>> +c = ['ccache', 'aarch64-linux-gnu-gcc'] cpp = ['ccache',
> >>> +'aarch64-linux-gnu-g++'] ar = 'aarch64-linux-gnu-ar'
> >>> +as = 'aarch64-linux-gnu-as'
> >>> +strip = 'aarch64-linux-gnu-strip'
> >>> +pkgconfig = 'aarch64-linux-gnu-pkg-config'
> >>> +pcap-config = ''
> >>> +
> >>> +[host_machine]
> >>> +system = 'linux'
> >>> +cpu_family = 'aarch64'
> >>> +cpu = 'armv8-a'
> >>> +endian = 'little'
> >>> +
> >>> +[properties]
> >>> +platform = 'cdx'
> >>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> >>> 5213434ca4..39b8929534 100644
> >>> --- a/config/arm/meson.build
> >>> +++ b/config/arm/meson.build
> >>> @@ -305,6 +305,18 @@ soc_bluefield = {
> >>>      'numa': false
> >>>  }
> >>>
> >>> +soc_cdx = {
> >>> +    'description': 'AMD CDX',
> >>> +    'implementer': '0x41',
> >>> +    'part_number': '0xd42',
> >>> +    'flags': [
> >>> +        ['RTE_MACHINE', '"cdx"'],
> >>> +        ['RTE_MAX_LCORE', 16],
> >>> +        ['RTE_MAX_NUMA_NODES', 1]
> >>> +    ],
> >>> +    'numa': false
> >>> +}
> >>
> >> Hi Nipun,
> >>
> >> Why we need a new arm platform/config? Is it because of above flags?
> >> If it can work with default values, I think we can drop this patch.
> >
> > Hi Ferruh,
> >
> > CDX driver works with generic ARM compilation too
> (arm64_armv8_linux_gcc).
> >
> > The versal platforms supporting CDX have A78 cores, and adding this
> > cdx config Helps to provide gcc option "march= armv8.4-a" which is for
> > implementer "0xd42" (ARM cortex A78 cores)., whereas for generic ARM
> > compilation "march= armv8-a".
> >
> > Maybe ARM guys can provide more information regarding if there is any
> > impact on using generic architecture flag (i.e. march= armv8a) on A78 cores.
> >
> 
> Hi Honnappa, Ruifeng,
> 
> Can you please support on this question, what is the difference of 'march=
> armv8-a' flag (comparing march= armv8a)?
I am assuming you meant, 'march=armv8.4-a' vs 'march=armv8-a'.

'march=armv8-a' will compile for the ARM V8.0-a ISA which is the base V8-a 
version of the ISA. This compilation ensures that the binaries can run on any 
ARM V8-a platforms.
'march=armv8.4-a' will compile the binary for ARM V8.4 ISA. The binary will use 
additional (possibly instructions that improve performance) instructions which 
are not supported in ARM V8.0-a. This binary can run only on machines that 
support V8.4-a and higher. But, it will provide optimized binary for the target 
platform.

> Should we consider adding an arm config file to support this flag?
We support the optimized binary through the config files. We should keep these 
config changes.

> 
> Thanks,
> ferruh
> 

Reply via email to