DPDK patches and discussions
 help / color / mirror / Atom feed
From: Doug Foster <doug.foster@arm.com>
Cc: dev@dpdk.org, nd@arm.com, Doug Foster <doug.foster@arm.com>,
	Wathsala Vithanage <wathsala.vithanage@arm.com>,
	Dhruv Tripathi <dhruv.tripathi@arm.com>
Subject: [PATCH] doc/linux_gsg: add build instructions for new Arm SoCs
Date: Fri, 16 May 2025 18:53:07 +0000	[thread overview]
Message-ID: <20250516185307.1494231-1-doug.foster@arm.com> (raw)

Add explanation of recent build configuration changes for Arm SoCs and
instructions for adding a build configuration for a new Arm SoC.

Signed-off-by: Doug Foster <doug.foster@arm.com>
Reviewed-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
Reviewed-by: Dhruv Tripathi <dhruv.tripathi@arm.com>
---
 doc/guides/linux_gsg/build_dpdk.rst | 116 ++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)

diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index 9c0dd9daf6..aa5b518821 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -149,6 +149,122 @@ When `-Dexamples=all` is set as a meson option, meson will check each example ap
 and add all which can be built to the list of tasks in the ninja build configuration file.
 
 
+.. _building_new_arm_soc:
+
+Building DPDK for a New ARM SoC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The DPDK build system for ARM platforms has been updated to improve clarity, usability,
+and performance optimization.
+Previously, the ARM build process utilized a mixture of compiler flags (``-mcpu``,
+``-march``, and ``-mtune``), which could inadvertently cause the compiler to fall back
+to older instruction sets, resulting in suboptimal performance.
+Following Arm's official guidance, the recommended practice is to prioritize the
+``-mcpu`` flag whenever the compiler supports the targeted CPU.
+The ``-mcpu`` option specifies the exact CPU, enabling the compiler to optimize code
+generation, select appropriate instruction sets, and fine-tune performance
+characteristics explicitly for the given processor.
+In contrast, ``-march`` defines the general architecture, and ``-mtune`` optimizes
+performance for a specific CPU but does not allow the compiler to make assumptions
+about available instructions.
+Prioritizing ``-mcpu`` ensures the build system generates optimized binaries tailored
+precisely for the intended CPU.
+The changes also include explicit build failures if the compiler does not support the
+specified CPU setting, avoiding unintended fallbacks to lower-performing architectures.
+
+
+**Summary of Changes and Impact**
+
+* For CPUs directly supported by a compiler's ``-mcpu`` option, references to
+  ``-march`` and related features have been eliminated to simplify and improve the
+  build configuration.
+
+* Introduction of Pseudo-CPU Definitions: For CPUs lacking direct compiler support,
+  pseudo-CPU definitions explicitly specify architecture (``march``) and extensions
+  (``march_extensions``) to ensure optimal performance without unintended downgrades.
+
+* Explicit Build Failures: Builds now explicitly fail when unsupported ``-mcpu``,
+  ``march``, or extensions are specified, providing guidance to resolve the issue
+  without silent fallbacks.
+
+
+**Adding Support for a New SoC**
+
+If building DPDK for an ARM SoC that is not already supported, follow the guidelines
+below to add support for a new SoC based on compiler support.
+
+* Compiler ``-mcpu`` option supports the SoC
+
+  #. In the appropriate ``part_number_config`` dictionary (located in
+     ``config/arm/meson.build``), assign to ``mcpu`` the SoC supported by the compiler
+     ``-mcpu`` option.
+     The following example is for SoC *foo* where the compiler supports ``-mcpu=foo``.
+
+     .. code-block:: meson
+
+        '<Part_Number>': {
+            'mcpu': 'foo',
+            'flags': [
+                ['RTE_MACHINE', '"Foo"'],
+                # Additional flags as needed
+            ]
+        },
+
+* Compiler lacks specific ``-mcpu`` support or features (pseudo-CPU required)
+
+  If the compiler does not fully support your SoC, perform the following steps:
+
+  #. Assign a pseudo-CPU name:
+
+     In the appropriate ``part_number_config`` dictionary (located in
+     ``config/arm/meson.build``), assign to ``mcpu`` a unique pseudo-CPU name
+     prefixed with ``mcpu_``.
+     This name should clearly represent your SoC.
+     The following example is for SoC *foo*.
+
+     .. code-block:: meson
+
+        '<Part_Number>': {
+            'mcpu': 'mcpu_foo',
+            'flags': [
+                ['RTE_MACHINE', '"Foo"'],
+                # Additional flags as needed
+            ]
+        },
+
+  #. Define the pseudo-CPU details:
+
+     In the ``mcpu_defs`` dictionary, add your pseudo-CPU definition.
+     Clearly specify the architecture (``march``) and list any compiler-supported
+     extensions (``march_extensions``).
+     Extensions such as ``sve`` or ``crypto`` are examples.
+     It is acceptable to leave ``march_extensions`` empty if no specific extensions
+     are required.
+
+     .. code-block:: meson
+
+        'mcpu_foo': {
+            'march': 'armv8.x-a',
+            'march_extensions': ['sve', 'crypto']
+        },
+
+     Replace ``armv8.x-a`` and the listed extensions with the appropriate ISA and
+     features for your SoC.
+
+* Older compiler without specific ``-mcpu`` support
+
+  #. Upgrade your compiler to a newer version that supports the required CPU.
+
+  #. Alternatively, utilize a generic build configuration:
+
+     .. code-block:: console
+
+        meson setup -Dplatform=generic build
+
+By adhering to these guidelines, you will ensure the most optimized build for
+ARM-based DPDK targets.
+
+
 Building 32-bit DPDK on 64-bit Systems
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.34.1


                 reply	other threads:[~2025-05-16 18:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20250516185307.1494231-1-doug.foster@arm.com \
    --to=doug.foster@arm.com \
    --cc=dev@dpdk.org \
    --cc=dhruv.tripathi@arm.com \
    --cc=nd@arm.com \
    --cc=wathsala.vithanage@arm.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).