patch 'test/ring: remove excessive inlining' has been queued to stable release 21.11.2

[Kevin Traynor <ktraynor@redhat.com>]

Hi,

FYI, your patch has been queued to stable release 21.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 06/13/22. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/3ec90e3ec0b68d06e9b9494798b79f2abaa2a49f

Thanks.

Kevin

---
From 3ec90e3ec0b68d06e9b9494798b79f2abaa2a49f Mon Sep 17 00:00:00 2001
From: Stanislaw Kardach <kda@semihalf.com>
Date: Wed, 11 May 2022 17:07:25 +0200
Subject: [PATCH] test/ring: remove excessive inlining

[ upstream commit 981a025741f80b4036f994ed30b04e757299ab19 ]

Forcing inlining in test_ring_enqueue and test_ring_dequeue can cause
the compiled code to grow extensively when compiled with no optimization
(-O0 or -Og). This is default in the meson's debug configuration. This
can collide with compiler bugs and cause issues during linking of unit
tests where the api_type or esize are non-const variables causing
inlining cascade. In perf tests this is not the case in perf-tests as
esize and api_type are const values.

One such case was discovered when porting DPDK to RISC-V. GCC 11.2 (and
no fix still in 12.1) is generating a short relative jump instruction
(J <offset>) for goto and for loops. When loop body grows extensively in
ring test, the target offset goes beyond supported offfset of +/- 1MB
from PC. This is an obvious bug in the GCC as RISC-V has a
two-instruction construct to jump to any absolute address (AUIPC+JALR).

However there is no reason to force inlining as the test code works
perfectly fine without it.

GCC has a bug report for a similar case (with conditionals):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062

Fixes: a9fe152363e2 ("test/ring: add custom element size functional tests")

Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 app/test/test_ring.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/app/test/test_ring.h b/app/test/test_ring.h
index c8bfec8399..45c263f3ff 100644
--- a/app/test/test_ring.h
+++ b/app/test/test_ring.h
@@ -98,5 +98,5 @@ test_ring_copy_from(struct rte_ring_zc_data *zcd, void *dst, int esize,
 }
 
-static __rte_always_inline unsigned int
+static inline unsigned int
 test_ring_enqueue(struct rte_ring *r, void **obj, int esize, unsigned int n,
 			unsigned int api_type)
@@ -159,5 +159,5 @@ test_ring_enqueue(struct rte_ring *r, void **obj, int esize, unsigned int n,
 }
 
-static __rte_always_inline unsigned int
+static inline unsigned int
 test_ring_dequeue(struct rte_ring *r, void **obj, int esize, unsigned int n,
 			unsigned int api_type)
@@ -223,5 +223,5 @@ test_ring_dequeue(struct rte_ring *r, void **obj, int esize, unsigned int n,
  * performance and functional tests.
  */
-static __rte_always_inline void *
+static inline void *
 test_ring_calloc(unsigned int rsize, int esize)
 {
-- 
2.34.3

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2022-06-09 12:34:29.852349481 +0100
+++ 0002-test-ring-remove-excessive-inlining.patch	2022-06-09 12:34:29.606980404 +0100
@@ -1 +1 @@
-From 981a025741f80b4036f994ed30b04e757299ab19 Mon Sep 17 00:00:00 2001
+From 3ec90e3ec0b68d06e9b9494798b79f2abaa2a49f Mon Sep 17 00:00:00 2001
@@ -4,0 +5,2 @@
+
+[ upstream commit 981a025741f80b4036f994ed30b04e757299ab19 ]