[PATCH] rcu: refactor rcu register/unregister functions
This simplifies the implementation of rte_rcu_qsbr_thread_register()
and rte_rcu_thread_unregister() functions. The simplified implementation
is easier to read.
Signed-off-by: Doug Foster
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Wathsala Vithanage
---
.mailmap | 1 +
lib/rcu/rte_rcu_qsbr.c | 77 --
2 files changed, 23 insertions(+), 55 deletions(-)
diff --git a/.mailmap b/.mailmap
index f76037213d..63d0f4187a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -360,6 +360,7 @@ Don Provan
Don Wallwork
Doug Dziggel
Douglas Flint
+Doug Foster
Dr. David Alan Gilbert
Drocula Lambda
Dror Birkman
diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu/rte_rcu_qsbr.c
index f08d974d07..40d7c566c8 100644
--- a/lib/rcu/rte_rcu_qsbr.c
+++ b/lib/rcu/rte_rcu_qsbr.c
@@ -81,8 +81,8 @@ rte_rcu_qsbr_init(struct rte_rcu_qsbr *v, uint32_t
max_threads)
int
rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
{
- unsigned int i, id, success;
- uint64_t old_bmap, new_bmap;
+ unsigned int i, id;
+ uint64_t old_bmap;
if (v == NULL || thread_id >= v->max_threads) {
RCU_LOG(ERR, "Invalid input parameter");
@@ -97,31 +97,15 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v,
unsigned int thread_id)
id = thread_id & __RTE_QSBR_THRID_MASK;
i = thread_id >> __RTE_QSBR_THRID_INDEX_SHIFT;
- /* Make sure that the counter for registered threads does not
-* go out of sync. Hence, additional checks are required.
-*/
- /* Check if the thread is already registered */
- old_bmap = rte_atomic_load_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v, i),
- rte_memory_order_relaxed);
- if (old_bmap & 1UL << id)
- return 0;
+ /* Add the thread to the bitmap of registered threads */
+ old_bmap = rte_atomic_fetch_or_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v,
i),
+ (1UL << id),
rte_memory_order_release);
- do {
- new_bmap = old_bmap | (1UL << id);
- success = rte_atomic_compare_exchange_strong_explicit(
- __RTE_QSBR_THRID_ARRAY_ELM(v, i),
- &old_bmap, new_bmap,
- rte_memory_order_release,
rte_memory_order_relaxed);
-
- if (success)
- rte_atomic_fetch_add_explicit(&v->num_threads,
- 1, rte_memory_order_relaxed);
- else if (old_bmap & (1UL << id))
- /* Someone else registered this thread.
-* Counter should not be incremented.
-*/
- return 0;
- } while (success == 0);
+ /* Increment the number of threads registered only if the thread was
not already
+* registered
+*/
+ if (!(old_bmap & (1UL << id)))
+ rte_atomic_fetch_add_explicit(&v->num_threads, 1,
rte_memory_order_relaxed);
return 0;
}
@@ -132,8 +116,8 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v,
unsigned int thread_id)
int
rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
{
- unsigned int i, id, success;
- uint64_t old_bmap, new_bmap;
+ unsigned int i, id;
+ uint64_t old_bmap;
if (v == NULL || thread_id >= v->max_threads) {
RCU_LOG(ERR, "Invalid input parameter");
@@ -148,35 +132,18 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v,
unsigned int thread_id)
id = thread_id & __RTE_QSBR_THRID_MASK;
i = thread_id >> __RTE_QSBR_THRID_INDEX_SHIFT;
- /* Make sure that the counter for registered threads does not
-* go out of sync. Hence, additional checks are required.
+ /* Make sure any loads of the shared data structure are
+* completed before removal of the thread from the bitmap of
+* reporting threads.
*/
- /* Check if the thread is already unregistered */
- old_bmap = rte_atomic_load_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v, i),
- rte_memory_order_relaxed);
- if (!(old_bmap & (1UL << id)))
- return 0;
+ old_bmap = rte_atomic_fetch_and_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v,
i),
+~(1UL << id),
rte_memory_order_release);
- do {
- new_bmap = old_bmap & ~(1UL << id);
- /* Make sure any loads of the shared data structure are
-* completed before removal of the thread from the list of
-* reporting threads.
-*/
-
[PATCH] rcu: refactor rcu register/unregister functions
This simplifies the implementation of rte_rcu_qsbr_thread_register()
and rte_rcu_thread_unregister() functions. The simplified implementation
is easier to read.
Signed-off-by: Doug Foster
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Wathsala Vithanage
---
.mailmap | 1 +
lib/rcu/rte_rcu_qsbr.c | 77 --
2 files changed, 23 insertions(+), 55 deletions(-)
diff --git a/.mailmap b/.mailmap
index f76037213d..63d0f4187a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -360,6 +360,7 @@ Don Provan
Don Wallwork
Doug Dziggel
Douglas Flint
+Doug Foster
Dr. David Alan Gilbert
Drocula Lambda
Dror Birkman
diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu/rte_rcu_qsbr.c
index f08d974d07..40d7c566c8 100644
--- a/lib/rcu/rte_rcu_qsbr.c
+++ b/lib/rcu/rte_rcu_qsbr.c
@@ -81,8 +81,8 @@ rte_rcu_qsbr_init(struct rte_rcu_qsbr *v, uint32_t
max_threads)
int
rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
{
- unsigned int i, id, success;
- uint64_t old_bmap, new_bmap;
+ unsigned int i, id;
+ uint64_t old_bmap;
if (v == NULL || thread_id >= v->max_threads) {
RCU_LOG(ERR, "Invalid input parameter");
@@ -97,31 +97,15 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v,
unsigned int thread_id)
id = thread_id & __RTE_QSBR_THRID_MASK;
i = thread_id >> __RTE_QSBR_THRID_INDEX_SHIFT;
- /* Make sure that the counter for registered threads does not
-* go out of sync. Hence, additional checks are required.
-*/
- /* Check if the thread is already registered */
- old_bmap = rte_atomic_load_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v, i),
- rte_memory_order_relaxed);
- if (old_bmap & 1UL << id)
- return 0;
+ /* Add the thread to the bitmap of registered threads */
+ old_bmap = rte_atomic_fetch_or_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v,
i),
+ (1UL << id),
rte_memory_order_release);
- do {
- new_bmap = old_bmap | (1UL << id);
- success = rte_atomic_compare_exchange_strong_explicit(
- __RTE_QSBR_THRID_ARRAY_ELM(v, i),
- &old_bmap, new_bmap,
- rte_memory_order_release,
rte_memory_order_relaxed);
-
- if (success)
- rte_atomic_fetch_add_explicit(&v->num_threads,
- 1, rte_memory_order_relaxed);
- else if (old_bmap & (1UL << id))
- /* Someone else registered this thread.
-* Counter should not be incremented.
-*/
- return 0;
- } while (success == 0);
+ /* Increment the number of threads registered only if the thread was
not already
+* registered
+*/
+ if (!(old_bmap & (1UL << id)))
+ rte_atomic_fetch_add_explicit(&v->num_threads, 1,
rte_memory_order_relaxed);
return 0;
}
@@ -132,8 +116,8 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v,
unsigned int thread_id)
int
rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
{
- unsigned int i, id, success;
- uint64_t old_bmap, new_bmap;
+ unsigned int i, id;
+ uint64_t old_bmap;
if (v == NULL || thread_id >= v->max_threads) {
RCU_LOG(ERR, "Invalid input parameter");
@@ -148,35 +132,18 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v,
unsigned int thread_id)
id = thread_id & __RTE_QSBR_THRID_MASK;
i = thread_id >> __RTE_QSBR_THRID_INDEX_SHIFT;
- /* Make sure that the counter for registered threads does not
-* go out of sync. Hence, additional checks are required.
+ /* Make sure any loads of the shared data structure are
+* completed before removal of the thread from the bitmap of
+* reporting threads.
*/
- /* Check if the thread is already unregistered */
- old_bmap = rte_atomic_load_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v, i),
- rte_memory_order_relaxed);
- if (!(old_bmap & (1UL << id)))
- return 0;
+ old_bmap = rte_atomic_fetch_and_explicit(__RTE_QSBR_THRID_ARRAY_ELM(v,
i),
+~(1UL << id),
rte_memory_order_release);
- do {
- new_bmap = old_bmap & ~(1UL << id);
- /* Make sure any loads of the shared data structure are
-* completed before removal of the thread from the list of
-* reporting threads.
-*/
-
RE: [PATCH v2 1/2] fib: implement RCU rule reclamation
The check for NULL is not necessary before calling rte_rcu_qsbr_dq_delete.
Similar to other free routines, an error will not occur when the dq pointer is
NULL.
However, it will give a debug log statement to indicate an invalid parameter
and return 0 to indicate success.
-Original Message-
From: Stephen Hemminger
Sent: Tuesday, October 8, 2024 1:18 PM
To: Vladimir Medvedkin
Cc: dev@dpdk.org; rja...@redhat.com; Ruifeng Wang ;
Honnappa Nagarahalli ; david.march...@redhat.com
Subject: Re: [PATCH v2 1/2] fib: implement RCU rule reclamation
On Tue, 8 Oct 2024 17:55:23 +
Vladimir Medvedkin wrote:
> @@ -569,7 +600,60 @@ dir24_8_free(void *p) {
> struct dir24_8_tbl *dp = (struct dir24_8_tbl *)p;
>
> + if (dp->dq != NULL)
> + rte_rcu_qsbr_dq_delete(dp->dq);
> +
Side note:
rte_rcu_qsbr_dq_delete should be changed to accept NULL as nop.
Like all the other free routines
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
[PATCH] doc/linux_gsg: add build instructions for new Arm SoCs
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
Reviewed-by: Wathsala Vithanage
Reviewed-by: Dhruv Tripathi
---
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
+
+'': {
+'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
+
+'': {
+'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 l
[PATCH] config/arm: update neoverse n3 SoC and add neoverse V3
Arm Neoverse N3 build configuration is updated to include mcpu that
aligns with latest GCC. Also, add Arm Neoverse V3 build configuration.
Signed-off-by: Doug Foster
Reviewed-by: Wathsala Vithanage
Reviewed-by: Dhruv Tripathi
---
config/arm/meson.build | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index f971ed3c1b..2f510c3a6c 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -110,17 +110,7 @@ part_number_config_arm = {
]
},
'0xd8e': {
-# Only when -march=armv9-a+wfxt is used will the WFET
-# feature be compiled with armv9 instructions.
-# However, +wfxt is not supported by GCC at the moment.
-# Although armv9-a is the fitting version of Arm ISA for
-# Neoverse N3, it cannot be used when enabling wfxt for
-# the above reasons.
-# The workaround for this is to use armv8.7-a, which
-# doesn't require +wfxt for binutils version 2.36 or greater.
-'march': 'armv8.7-a',
-'march_features': ['sve2'],
-'fallback_march': 'armv8.5-a',
+'mcpu' : 'neoverse-n3',
'flags': [
['RTE_MACHINE', '"neoverse-n3"'],
['RTE_ARM_FEATURE_ATOMICS', true],
@@ -128,6 +118,16 @@ part_number_config_arm = {
['RTE_MAX_LCORE', 192],
['RTE_MAX_NUMA_NODES', 2]
]
+},
+'0xd84': {
+'mcpu' : 'neoverse-v3',
+'flags': [
+['RTE_MACHINE', '"neoverse-v3"'],
+['RTE_ARM_FEATURE_ATOMICS', true],
+['RTE_ARM_FEATURE_WFXT', true],
+['RTE_MAX_LCORE', 128],
+['RTE_MAX_NUMA_NODES', 2]
+]
}
}
implementer_arm = {
@@ -641,6 +641,13 @@ soc_v2 = {
'numa': true
}
+soc_v3 = {
+'description': 'Arm Neoverse V3',
+'implementer': '0x41',
+'part_number': '0xd84',
+'numa': true
+}
+
mcpu_defs = {
'mcpu_centriq2400': {
'march': 'armv8-a',
@@ -712,6 +719,7 @@ kunpeng920: HiSilicon Kunpeng 920
kunpeng930: HiSilicon Kunpeng 930
n1sdp: Arm Neoverse N1SDP
n2: Arm Neoverse N2
+n3: Arm Neoverse N3
odyssey: Marvell Odyssey
stingray:Broadcom Stingray
thunderx2: Marvell ThunderX2 T99
@@ -720,6 +728,7 @@ thunderxt88: Marvell ThunderX T88
tys2500: Phytium TengYun S2500
tys5000c:Phytium TengYun S5000c
v2: Arm Neoverse V2
+v3: Arm Neoverse V3
End of SoCs list
'''
# The string above is included in the documentation, keep it in sync with the
@@ -760,6 +769,7 @@ socs = {
'tys2500': soc_tys2500,
'tys5000c': soc_tys5000c,
'v2': soc_v2,
+'v3': soc_v3
}
dpdk_conf.set('RTE_ARCH_ARM', 1)
--
2.34.1
RE: meson error on ARM Grace server 23.11/22.11
Hi Patrick, While building 22.11 and 23.11 with GCC 13.3, I noticed compiler warnings related to memcpy usage, specifically involving __builtin___memcpy_chk failures. Would these warnings be a concern for CI test runs, or are they generally tolerated? From: Doug Foster Sent: Friday, May 16, 2025 12:16 AM To: Patrick Robb ; Wathsala Wathawana Vithanage Cc: c...@dpdk.org; dev ; Honnappa Nagarahalli ; sta...@dpdk.org; nd Subject: RE: meson error on ARM Grace server 23.11/22.11 Hi Patrick, I will produce the patches with necessary changes to build on Grace for 22.11 and 23.11. From: Patrick Robb <mailto:pr...@iol.unh.edu> Sent: Thursday, May 15, 2025 3:59 PM To: Wathsala Wathawana Vithanage <mailto:wathsala.vithan...@arm.com> Cc: mailto:c...@dpdk.org; dev <mailto:dev@dpdk.org>; Honnappa Nagarahalli <mailto:honnappa.nagaraha...@arm.com>; mailto:sta...@dpdk.org; Doug Foster <mailto:doug.fos...@arm.com>; nd <mailto:n...@arm.com> Subject: Re: meson error on ARM Grace server 23.11/22.11 Thanks Wathsala, How can we help on the UNH side? Do you want us to produce the 22.11 and 23.11 diffs/patches, which would be based on d007038, with some modifications based on what you had said to Doug? I'm not sure what the process looks like exactly for providing backports to LTS maintainers. On Tue, Apr 29, 2025 at 12:00 PM Wathsala Wathawana Vithanage <mailto:wathsala.vithan...@arm.com> wrote: > Hi, > > At the DPDK Community Lab we have been running CI tests with a new ARM > Grace server for the past couple of months on main and next-* branches. I am > trying to add LTS runs now, and ran into a snag with 23.11 and 22.11 for this > system. Stable maintainers I'm not sure whether this should be addressed or > not > for hardware which is new and didn't exist when 22.11 and 23.11 were > released... but I figured I'd make the tickets and find out. I attached the > meson > logs to the tickets and if for whatever reason you guys want to remote into > this > machine, I'm happy to setup the VPN and SSH access. > > 22.11: https://bugs.dpdk.org/show_bug.cgi?id=1703 > 23.11: https://bugs.dpdk.org/show_bug.cgi?id=1702 +doug neoverse-v2 is supported in the GCC 13.3 used for this build although -mtune/-mcpu for grace is not available in that version. Adding neoverse-v2 and soc_grace with crypto extension should bring these releases on par with latest. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
RE: meson error on ARM Grace server 23.11/22.11
Hi Patrick, I will produce the patches with necessary changes to build on Grace for 22.11 and 23.11. From: Patrick Robb Sent: Thursday, May 15, 2025 3:59 PM To: Wathsala Wathawana Vithanage Cc: c...@dpdk.org; dev ; Honnappa Nagarahalli ; sta...@dpdk.org; Doug Foster ; nd Subject: Re: meson error on ARM Grace server 23.11/22.11 Thanks Wathsala, How can we help on the UNH side? Do you want us to produce the 22.11 and 23.11 diffs/patches, which would be based on d007038, with some modifications based on what you had said to Doug? I'm not sure what the process looks like exactly for providing backports to LTS maintainers. On Tue, Apr 29, 2025 at 12:00 PM Wathsala Wathawana Vithanage mailto:wathsala.vithan...@arm.com>> wrote: > Hi, > > At the DPDK Community Lab we have been running CI tests with a new ARM > Grace server for the past couple of months on main and next-* branches. I am > trying to add LTS runs now, and ran into a snag with 23.11 and 22.11 for this > system. Stable maintainers I'm not sure whether this should be addressed or > not > for hardware which is new and didn't exist when 22.11 and 23.11 were > released... but I figured I'd make the tickets and find out. I attached the > meson > logs to the tickets and if for whatever reason you guys want to remote into > this > machine, I'm happy to setup the VPN and SSH access. > > 22.11: https://bugs.dpdk.org/show_bug.cgi?id=1703 > 23.11: https://bugs.dpdk.org/show_bug.cgi?id=1702 +doug neoverse-v2 is supported in the GCC 13.3 used for this build although -mtune/-mcpu for grace is not available in that version. Adding neoverse-v2 and soc_grace with crypto extension should bring these releases on par with latest. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
