From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> 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 <dev@dpdk.org>; Thu, 5 May 2022 19:44:19 +0200 (CEST) Received: by mail-lj1-f182.google.com with SMTP id g16so6535800lja.3 for <dev@dpdk.org>; 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?= <kda@semihalf.com> Date: Thu, 5 May 2022 19:43:43 +0200 Message-ID: <CALVGJWKiqaSEBD9zm-C-7z3QeK9Q=GSkgbhfrVfe-k3jWGDx-g@mail.gmail.com> Subject: Re: [PATCH 09/11] test/ring: disable problematic tests for RISC-V To: Stephen Hemminger <stephen@networkplumber.org> Cc: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>, dev <dev@dpdk.org>, Frank Zhao <Frank.Zhao@starfivetech.com>, Sam Grove <sam.grove@sifive.com>, Marcin Wojtas <mw@semihalf.com>, 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 <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 --00000000000092944205de474a47 Content-Type: text/plain; charset="UTF-8" On Thu, May 5, 2022 at 7:35 PM Stephen Hemminger <stephen@networkplumber.org> wrote: > On Thu, 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 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 <offset>' 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 <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. > 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 <div dir=3D"ltr"><div dir=3D"ltr">On Thu, May 5, 2022 at 7:35 PM Stephen He= mminger <<a href=3D"mailto:stephen@networkplumber.org" target=3D"_blank"= >stephen@networkplumber.org</a>> wrote:<br></div><div dir=3D"ltr"><div c= lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On T= hu,=C2=A0 5 May 2022 19:30:01 +0200<br> Stanislaw Kardach <<a href=3D"mailto:kda@semihalf.com" target=3D"_blank"= >kda@semihalf.com</a>> wrote:<br> <br> > When compiling for RISC-V in debug mode the large amount of inlining i= n<br> > 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<br> > PC-relative jumps generated by the compiler to go beyond the architect= ure<br> > limitation of +/-1MB offset (the 'j <offset>' instructio= n). This<br> > instruction should not be generated by the compiler since C language d= oes<br> > not limit the maximum distance for 'goto' or 'for' loo= p jumps.<br> > <br> > This only happens in the unit test for ring which tries to perform lon= g<br> > loops with ring enqueue/dequeue and it seems to be caused by excessive= <br> > __rte_always_inline usage. ring perf test compiles just fine under<br> > debug.<br> > <br> > To work around this, disable the offending tests in debug mode.<br> > <br> > Signed-off-by: Stanislaw Kardach <<a href=3D"mailto:kda@semihalf.co= m" target=3D"_blank">kda@semihalf.com</a>><br> > Sponsored-by: Frank Zhao <<a href=3D"mailto:Frank.Zhao@starfivetech= .com" target=3D"_blank">Frank.Zhao@starfivetech.com</a>><br> > Sponsored-by: Sam Grove <<a href=3D"mailto:sam.grove@sifive.com" ta= rget=3D"_blank">sam.grove@sifive.com</a>><br> > ---<br> <br> It seems to me that fixing the excessive inlining in the ring code<br> could benefit all architectures, rather than neutering the tests<br> on RISCV.<br></blockquote><div>=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.</div><div>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).</div></div></div> </div> --00000000000092944205de474a47--