please help backporting some patches to stable release 23.11.3

please help backporting some patches to stable release 23.11.3

[Xueming Li]

Hi commit authors (and maintainers),

Despite being selected by the DPDK maintenance tool ./devtools/git-log-fixes.sh
I didn't apply following commits from DPDK main to 23.11
stable branch, as conflicts or build errors occur.

Can authors check your patches in the following list and either:
    - Backport your patches to the 23.11 branch, or
    - Indicate that the patch should not be backported

Please do either of the above by 11/30/24.

You can find the a temporary work-in-progress branch of the coming 23.11.3
release at:
    https://git.dpdk.org/dpdk-stable/log/?h=23.11-staging
It is recommended to backport on top of that to minimize further conflicts or
misunderstandings.

Some notes on stable backports:

A backport should contain a reference to the DPDK main branch commit
in it's commit message in the following fashion:
    [ upstream commit <commit's dpdk main branch SHA-1 checksum> ]

For example:
    https://git.dpdk.org/dpdk-stable/commit/?h=18.11&id=d90e6ae6f936ecdc2fd3811ff9f26aec7f3c06eb

When sending the backported patch, please indicate the target branch in the
subject line, as we have multiple branches, for example:
    [PATCH 23.11] foo/bar: fix baz

With git format-patch, this can be achieved by appending the parameter:
    --subject-prefix='PATCH 23.11'

Send the backported patch to "stable@dpdk.org" but not "dev@dpdk.org".

FYI, branch 23.11 is located at tree:
   https://git.dpdk.org/dpdk-stable

Thanks.

Xueming Li <xuemingl@nvidia.com>

---
b0bad8e998  Anatoly Burakov  net/i40e/base: fix setting MAC type for X722
e4a4087992  Gavin Li         net/mlx5: set errno for ipool allocation failures
6f96937dad  Robin Jarry      ethdev: fix race on ports in telemetry endpoints

Re: please help backporting some patches to stable release 23.11.3

[Robin Jarry]

Xueming Li, Nov 11, 2024 at 07:54:
> 6f96937dad  Robin Jarry      ethdev: fix race on ports in telemetry endpoints

Hi Xueming,

backporting this patch requires also backporting ceb5914cd1e1 
("telemetry: register command with private argument").

I don't know if this is something that we want or not.

Re: please help backporting some patches to stable release 23.11.3

[Xueming Li]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

Hi Robin,

The dependency is a new API, I'm afraid we don't want it in LTS.

________________________________
From: Robin Jarry <rjarry@redhat.com>
Sent: Monday, November 11, 2024 7:44 PM
To: dpdk stable <stable@dpdk.org>
Cc: Xueming Li <xuemingl@nvidia.com>; Alexander Kozyrev <akozyrev@nvidia.com>; Anatoly Burakov <anatoly.burakov@intel.com>; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Bing Zhao <bingz@nvidia.com>; Bruce Richardson <bruce.richardson@intel.com>; Ciara Power <ciara.power@intel.com>; Dariusz Sosnowski <dsosnowski@nvidia.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Minggang(Gavin) Li <gavinl@nvidia.com>; Ian Stokes <ian.stokes@intel.com>; Keith Wiles <keith.wiles@intel.com>; Matan Azrad <matan@nvidia.com>; Ori Kam <orika@nvidia.com>; Qi Zhang <qi.z.zhang@intel.com>; Qiming Yang <qiming.yang@intel.com>; Stephen Hemminger <stephen@networkplumber.org>; Suanming Mou <suanmingm@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Slava Ovsiienko <viacheslavo@nvidia.com>
Subject: Re: please help backporting some patches to stable release 23.11.3

Xueming Li, Nov 11, 2024 at 07:54:
> 6f96937dad  Robin Jarry      ethdev: fix race on ports in telemetry endpoints

Hi Xueming,

backporting this patch requires also backporting ceb5914cd1e1
("telemetry: register command with private argument").

I don't know if this is something that we want or not.


[-- Attachment #2: Type: text/html, Size: 2917 bytes --]

please help backporting some patches to stable release 23.11.3

[Xueming Li]

Hi commit authors (and maintainers),

Despite being selected by the DPDK maintenance tool ./devtools/git-log-fixes.sh
I didn't apply following commits from DPDK main to 23.11
stable branch, as conflicts or build errors occur.

Can authors check your patches in the following list and either:
    - Backport your patches to the 23.11 branch, or
    - Indicate that the patch should not be backported

Please do either of the above by 12/10/24.

You can find the a temporary work-in-progress branch of the coming 23.11.3
release at:
    https://git.dpdk.org/dpdk-stable/log/?h=23.11-staging
It is recommended to backport on top of that to minimize further conflicts or
misunderstandings.

Some notes on stable backports:

A backport should contain a reference to the DPDK main branch commit
in it's commit message in the following fashion:
    [ upstream commit <commit's dpdk main branch SHA-1 checksum> ]

For example:
    https://git.dpdk.org/dpdk-stable/commit/?h=18.11&id=d90e6ae6f936ecdc2fd3811ff9f26aec7f3c06eb

When sending the backported patch, please indicate the target branch in the
subject line, as we have multiple branches, for example:
    [PATCH 23.11] foo/bar: fix baz

With git format-patch, this can be achieved by appending the parameter:
    --subject-prefix='PATCH 23.11'

Send the backported patch to "stable@dpdk.org" but not "dev@dpdk.org".

FYI, branch 23.11 is located at tree:
   https://git.dpdk.org/dpdk-stable

Thanks.

Xueming Li <xuemingl@nvidia.com>

---
ffe827f38e  Andre Muezerie   rcu: fix implicit conversion in bit shift
d46f3b525a  Gregory Etelson  net/mlx5: fix error notifications in counter initialization
8782e4de3e  Kishore Padmanabha net/bnxt/tf_ulp: fix parent child DB counters

[PATCH 23.11] rcu: fix implicit conversion in bit shift

[Andre Muezerie]

[ upstream commit ffe827f38e6e0be8a307d7ef9c0e1347874f0af7 ]

../lib/rcu/rte_rcu_qsbr.c(101): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)
../lib/rcu/rte_rcu_qsbr.c(107): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)
../lib/rcu/rte_rcu_qsbr.c(145): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)

These warnings are being issued by the MSVC compiler. Since the result is
being stored in a variable of type uint64_t, it makes sense to shift a
64-bit number instead of shifting a 32-bit number and then having the
compiler to convert the result implicitly to 64 bits.
UINT64_C was used in the fix as it is the portable way to define a 64-bit
constant (ULL suffix is architecture dependent).

From reading the code this is also a bugfix:
(1 << id), where id = thread_id & 0x3f, was wrong when thread_id > 0x1f.

Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
---
 lib/rcu/rte_rcu_qsbr.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu/rte_rcu_qsbr.c
index 41a44be4b9..e46ce7958e 100644
--- a/lib/rcu/rte_rcu_qsbr.c
+++ b/lib/rcu/rte_rcu_qsbr.c
@@ -104,11 +104,11 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
 	/* 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)
+	if (old_bmap & RTE_BIT64(id))
 		return 0;
 
 	do {
-		new_bmap = old_bmap | (1UL << id);
+		new_bmap = old_bmap | RTE_BIT64(id);
 		success = rte_atomic_compare_exchange_strong_explicit(
 					__RTE_QSBR_THRID_ARRAY_ELM(v, i),
 					&old_bmap, new_bmap,
@@ -117,7 +117,7 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
 		if (success)
 			rte_atomic_fetch_add_explicit(&v->num_threads,
 						1, rte_memory_order_relaxed);
-		else if (old_bmap & (1UL << id))
+		else if (old_bmap & RTE_BIT64(id))
 			/* Someone else registered this thread.
 			 * Counter should not be incremented.
 			 */
@@ -156,11 +156,11 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
 	/* 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)))
+	if (!(old_bmap & RTE_BIT64(id)))
 		return 0;
 
 	do {
-		new_bmap = old_bmap & ~(1UL << id);
+		new_bmap = old_bmap & ~RTE_BIT64(id);
 		/* Make sure any loads of the shared data structure are
 		 * completed before removal of the thread from the list of
 		 * reporting threads.
@@ -173,7 +173,7 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
 		if (success)
 			rte_atomic_fetch_sub_explicit(&v->num_threads,
 						1, rte_memory_order_relaxed);
-		else if (!(old_bmap & (1UL << id)))
+		else if (!(old_bmap & RTE_BIT64(id)))
 			/* Someone else unregistered this thread.
 			 * Counter should not be incremented.
 			 */
@@ -234,7 +234,7 @@ rte_rcu_qsbr_dump(FILE *f, struct rte_rcu_qsbr *v)
 			t = rte_ctz64(bmap);
 			fprintf(f, "%u ", id + t);
 
-			bmap &= ~(1UL << t);
+			bmap &= ~RTE_BIT64(t);
 		}
 	}
 
@@ -261,7 +261,7 @@ rte_rcu_qsbr_dump(FILE *f, struct rte_rcu_qsbr *v)
 				rte_atomic_load_explicit(
 					&v->qsbr_cnt[id + t].lock_cnt,
 					rte_memory_order_relaxed));
-			bmap &= ~(1UL << t);
+			bmap &= ~RTE_BIT64(t);
 		}
 	}
 
-- 
2.47.0.vfs.0.3

Re: [PATCH 23.11] rcu: fix implicit conversion in bit shift

[Xueming Li]

[-- Attachment #1: Type: text/plain, Size: 5024 bytes --]

Hi Andre,

Thanks for your help, patch enqueued to 23.11 LTS patch list.

Regards,
Xueming

________________________________
From: Andre Muezerie <andremue@linux.microsoft.com>
Sent: Monday, December 9, 2024 11:56 PM
To: stable@dpdk.org <stable@dpdk.org>
Cc: Andre Muezerie <andremue@linux.microsoft.com>
Subject: [PATCH 23.11] rcu: fix implicit conversion in bit shift

[ upstream commit ffe827f38e6e0be8a307d7ef9c0e1347874f0af7 ]

../lib/rcu/rte_rcu_qsbr.c(101): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)
../lib/rcu/rte_rcu_qsbr.c(107): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)
../lib/rcu/rte_rcu_qsbr.c(145): warning C4334: '<<': result of 32-bit
 shift implicitly converted to 64 bits (was 64-bit shift intended?)

These warnings are being issued by the MSVC compiler. Since the result is
being stored in a variable of type uint64_t, it makes sense to shift a
64-bit number instead of shifting a 32-bit number and then having the
compiler to convert the result implicitly to 64 bits.
UINT64_C was used in the fix as it is the portable way to define a 64-bit
constant (ULL suffix is architecture dependent).

From reading the code this is also a bugfix:
(1 << id), where id = thread_id & 0x3f, was wrong when thread_id > 0x1f.

Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
---
 lib/rcu/rte_rcu_qsbr.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu/rte_rcu_qsbr.c
index 41a44be4b9..e46ce7958e 100644
--- a/lib/rcu/rte_rcu_qsbr.c
+++ b/lib/rcu/rte_rcu_qsbr.c
@@ -104,11 +104,11 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
         /* 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)
+       if (old_bmap & RTE_BIT64(id))
                 return 0;

         do {
-               new_bmap = old_bmap | (1UL << id);
+               new_bmap = old_bmap | RTE_BIT64(id);
                 success = rte_atomic_compare_exchange_strong_explicit(
                                         __RTE_QSBR_THRID_ARRAY_ELM(v, i),
                                         &old_bmap, new_bmap,
@@ -117,7 +117,7 @@ rte_rcu_qsbr_thread_register(struct rte_rcu_qsbr *v, unsigned int thread_id)
                 if (success)
                         rte_atomic_fetch_add_explicit(&v->num_threads,
                                                 1, rte_memory_order_relaxed);
-               else if (old_bmap & (1UL << id))
+               else if (old_bmap & RTE_BIT64(id))
                         /* Someone else registered this thread.
                          * Counter should not be incremented.
                          */
@@ -156,11 +156,11 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
         /* 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)))
+       if (!(old_bmap & RTE_BIT64(id)))
                 return 0;

         do {
-               new_bmap = old_bmap & ~(1UL << id);
+               new_bmap = old_bmap & ~RTE_BIT64(id);
                 /* Make sure any loads of the shared data structure are
                  * completed before removal of the thread from the list of
                  * reporting threads.
@@ -173,7 +173,7 @@ rte_rcu_qsbr_thread_unregister(struct rte_rcu_qsbr *v, unsigned int thread_id)
                 if (success)
                         rte_atomic_fetch_sub_explicit(&v->num_threads,
                                                 1, rte_memory_order_relaxed);
-               else if (!(old_bmap & (1UL << id)))
+               else if (!(old_bmap & RTE_BIT64(id)))
                         /* Someone else unregistered this thread.
                          * Counter should not be incremented.
                          */
@@ -234,7 +234,7 @@ rte_rcu_qsbr_dump(FILE *f, struct rte_rcu_qsbr *v)
                         t = rte_ctz64(bmap);
                         fprintf(f, "%u ", id + t);

-                       bmap &= ~(1UL << t);
+                       bmap &= ~RTE_BIT64(t);
                 }
         }

@@ -261,7 +261,7 @@ rte_rcu_qsbr_dump(FILE *f, struct rte_rcu_qsbr *v)
                                 rte_atomic_load_explicit(
                                         &v->qsbr_cnt[id + t].lock_cnt,
                                         rte_memory_order_relaxed));
-                       bmap &= ~(1UL << t);
+                       bmap &= ~RTE_BIT64(t);
                 }
         }

--
2.47.0.vfs.0.3


[-- Attachment #2: Type: text/html, Size: 12769 bytes --]