From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 55D57C433F5
	for <dpdk-dev@archiver.kernel.org>; Thu, 19 May 2022 22:52:05 +0000 (UTC)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 30B4740151;
	Fri, 20 May 2022 00:52:04 +0200 (CEST)
Received: from forward501o.mail.yandex.net (forward501o.mail.yandex.net
 [37.140.190.203])
 by mails.dpdk.org (Postfix) with ESMTP id 4915B40146
 for <dev@dpdk.org>; Fri, 20 May 2022 00:52:02 +0200 (CEST)
Received: from iva4-3f047a428f41.qloud-c.yandex.net
 (iva4-3f047a428f41.qloud-c.yandex.net
 [IPv6:2a02:6b8:c0c:128e:0:640:3f04:7a42])
 by forward501o.mail.yandex.net (Yandex) with ESMTP id 4745245C4E90;
 Fri, 20 May 2022 01:50:55 +0300 (MSK)
Received: from iva1-dcde80888020.qloud-c.yandex.net
 (iva1-dcde80888020.qloud-c.yandex.net [2a02:6b8:c0c:7695:0:640:dcde:8088])
 by iva4-3f047a428f41.qloud-c.yandex.net (mxback/Yandex) with ESMTP id
 4ayVKzQsjX-osfqsItv; Fri, 20 May 2022 01:50:55 +0300
X-Yandex-Fwd: 2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1653000655; bh=N1ZrD9R1xa2TQzfYKYqg1hoaN4enJnYYN9GsMMqmaM0=;
 h=In-Reply-To:From:Subject:Cc:References:Date:Message-ID:To;
 b=AiAClK82Qi5BaBrWIPjSXGMRa5GftyUUGZmcOReJ3wvMqCKkhY6sr4n+XNYDl+9fT
 tdiiFOXuNAYs/k52LpMBHJykdNzoTtWgeNBqaRmd8WQjlkCh/WTLosKRJmusBcccOv
 MYmbCQWYUCrJnXCAlsnk4+oOQqa8idfast0ddiBQ=
Authentication-Results: iva4-3f047a428f41.qloud-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: by iva1-dcde80888020.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA
 id AZHZEooBL9-opci3eh6; Fri, 20 May 2022 01:50:53 +0300
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
 (Client certificate not present)
Message-ID: <80ec6716-a94d-0146-cbad-63081386f5b4@yandex.ru>
Date: Thu, 19 May 2022 23:50:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH v2 1/1] test/ring: remove excessive inlining
Content-Language: en-US
To: Stanislaw Kardach <kda@semihalf.com>,
 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Cc: dev@dpdk.org, Frank Zhao <Frank.Zhao@starfivetech.com>,
 Sam Grove <sam.grove@sifive.com>, mw@semihalf.com, upstream@semihalf.com
References: <20220510115758.457794-1-kda@semihalf.com>
 <20220511150725.744021-1-kda@semihalf.com>
From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
In-Reply-To: <20220511150725.744021-1-kda@semihalf.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

11/05/2022 16:07, Stanislaw Kardach пишет:
> 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: a9fe152363 test/ring: add custom element size functional tests
> 
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> ---
>   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
> @@ -97,7 +97,7 @@ 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)
>   {
> @@ -158,7 +158,7 @@ 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)
>   {
> @@ -222,7 +222,7 @@ test_ring_dequeue(struct rte_ring *r, void **obj, int esize, unsigned int n,
>   /* This function is placed here as it is required for both
>    * performance and functional tests.
>    */
> -static __rte_always_inline void *
> +static inline void *
>   test_ring_calloc(unsigned int rsize, int esize)
>   {
>   	unsigned int sz;

Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>