From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8A8C1A00C2; Thu, 5 May 2022 19:44:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B6384014F; Thu, 5 May 2022 19:44:20 +0200 (CEST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by mails.dpdk.org (Postfix) with ESMTP id 3002A40042 for ; Thu, 5 May 2022 19:44:19 +0200 (CEST) Received: by mail-lj1-f182.google.com with SMTP id g16so6535800lja.3 for ; Thu, 05 May 2022 10:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H3fNqQBntGHCBH3NhOTP5INQEk6/kO39iAXmQ5Xp4vM=; b=ZzkSNIJAs5sinxmg1tbMPPFhGXV8/PqN2wDumnsCvBzLseACKFoUqW36tYaV/+wecw IPxVoF2ShSH7Bf5cDqdTpjOOgT+jfgvqSTphqszyFZAPn7dtT95ZmVvOYcEYLR762Ocf O546FVmg7lHNN6QT6sqtXGHmH0U4dneXVGrQkZltk5sSuo1KtgunwejrqLaKD+Hiu+sA Q4Rxzf7RdBYXL9c4mArVWhFPiO271gO5w9m5jVlA86Mh9qeK5BAm5LAdaQI4ocB61m88 oRy9ZZQZBNT9NQfs8MgXKjz4XPTQS2dwUN7PGstjuSc033pXTQC5Q8cy9kDyXq9dxBSg mq6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3fNqQBntGHCBH3NhOTP5INQEk6/kO39iAXmQ5Xp4vM=; b=OqO3wpwClWBV+MhN+xbRpUJsPjGHpmwSOgvJFs76XkKlunHCJO8gbIQ1ZVi6UUv+0E vHW4AovzLdDxyTG+FpvGMoiIE5wrgvgXxHJw8NWp5eJmAL5L1+2yYzRH3fO6cDmhovgs +NSvFTFEhZL9IX+ae7MskeJ4QG+7sSOnDttT2LGvJ3aWojhGdDC4BqEPu7VIG3rE3abV d5U1vJRd3RiL5Urxm+YJWDnk4F6Z7sUKY5KwkUIxS7YmMnooka+R7S1ftxMK25iF49sK RWZe++2ehhgQoLFNruwEuqea//4bVHcPThOH8J0SaujHqkkqJPlhhSvji5g3WdBZNvP7 FnpA== X-Gm-Message-State: AOAM532liblBjzbV4wNNG/r8EV+ZugHsFOClkY1srWnhOZVjtDSvSRVs uLGroYZUhPh9xT8sSokLx2c/ZWyAaMklzM3G3DPZKg== X-Google-Smtp-Source: ABdhPJwCNfCe2G5OXPrsjJra7Aeom4j9oPi0vB+o3qR1C/zqBTXPnaFfAhb1XckSETgIunSbIbfM72X3PKUbAgPCbi0= X-Received: by 2002:a05:651c:19a5:b0:24f:5210:d352 with SMTP id bx37-20020a05651c19a500b0024f5210d352mr14147922ljb.410.1651772658707; Thu, 05 May 2022 10:44:18 -0700 (PDT) MIME-Version: 1.0 References: <20220505173003.3242618-1-kda@semihalf.com> <20220505173003.3242618-10-kda@semihalf.com> <20220505103516.5486d020@hermes.local> In-Reply-To: <20220505103516.5486d020@hermes.local> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= Date: Thu, 5 May 2022 19:43:43 +0200 Message-ID: Subject: Re: [PATCH 09/11] test/ring: disable problematic tests for RISC-V To: Stephen Hemminger Cc: Honnappa Nagarahalli , dev , Frank Zhao , Sam Grove , Marcin Wojtas , upstream@semihalf.com Content-Type: multipart/alternative; boundary="00000000000092944205de474a47" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --00000000000092944205de474a47 Content-Type: text/plain; charset="UTF-8" On Thu, May 5, 2022 at 7:35 PM Stephen Hemminger wrote: > On Thu, 5 May 2022 19:30:01 +0200 > Stanislaw Kardach wrote: > > > When compiling for RISC-V in debug mode the large amount of inlining in > > test_ring_basic_ex() and test_ring_with_exact_size() (in test_ring.c) > > leads to large loop bodies. This causes 'goto' and 'for' loop > > PC-relative jumps generated by the compiler to go beyond the architecture > > limitation of +/-1MB offset (the 'j ' instruction). This > > instruction should not be generated by the compiler since C language does > > not limit the maximum distance for 'goto' or 'for' loop jumps. > > > > This only happens in the unit test for ring which tries to perform long > > loops with ring enqueue/dequeue and it seems to be caused by excessive > > __rte_always_inline usage. ring perf test compiles just fine under > > debug. > > > > To work around this, disable the offending tests in debug mode. > > > > Signed-off-by: Stanislaw Kardach > > Sponsored-by: Frank Zhao > > Sponsored-by: Sam Grove > > --- > > It seems to me that fixing the excessive inlining in the ring code > could benefit all architectures, rather than neutering the tests > on RISCV. > True. Since this only happened in the tests that I've mentioned, my other approach was to introduce a "slow" wrapper over test_ring_dequeue|enqueue() which did not force inlining via __rte_always_inline and use it in functional test functions. However after talking with Thomas Monjalon we've decided to guard the debug build of RISC-V only. Another thing is that this is a clear bug in the compiler, the relaxation of the jump should not be done since RISC-V has long jump construct for arbitrary jumps (auipc+jalr). --00000000000092944205de474a47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 5, 2022 at 7:35 PM Stephen He= mminger <stephen@networkplumber.org> wrote:
On T= hu,=C2=A0 5 May 2022 19:30:01 +0200
Stanislaw Kardach <kda@semihalf.com> wrote:

> When compiling for RISC-V in debug mode the large amount of inlining i= n
> test_ring_basic_ex() and test_ring_with_exact_size() (in test_ring.c)<= br> > leads to large loop bodies. This causes 'goto' and 'for= 9; loop
> PC-relative jumps generated by the compiler to go beyond the architect= ure
> limitation of +/-1MB offset (the 'j <offset>' instructio= n). This
> instruction should not be generated by the compiler since C language d= oes
> not limit the maximum distance for 'goto' or 'for' loo= p jumps.
>
> This only happens in the unit test for ring which tries to perform lon= g
> loops with ring enqueue/dequeue and it seems to be caused by excessive=
> __rte_always_inline usage. ring perf test compiles just fine under
> debug.
>
> To work around this, disable the offending tests in debug mode.
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
> Sponsored-by: Sam Grove <sam.grove@sifive.com>
> ---

It seems to me that fixing the excessive inlining in the ring code
could benefit all architectures, rather than neutering the tests
on RISCV.
=C2=A0True. Since this only happened in the = tests that I've mentioned, my other approach was to introduce a "s= low" wrapper over test_ring_dequeue|enqueue() which did not force inli= ning via __rte_always_inline and use it in functional test functions. Howev= er after talking with Thomas Monjalon we've decided to guard the debug = build of RISC-V only.
Another thing is that this is a clear bug i= n the compiler, the relaxation of the jump should not be done since RISC-V = has long jump construct for arbitrary jumps (auipc+jalr).
--00000000000092944205de474a47--