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 DEF1DA00C2; Thu, 5 May 2022 20:06:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C1B834014F; Thu, 5 May 2022 20:06:38 +0200 (CEST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id B905640042 for ; Thu, 5 May 2022 20:06:37 +0200 (CEST) Received: by mail-pf1-f178.google.com with SMTP id j6so4240892pfe.13 for ; Thu, 05 May 2022 11:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3+MGQm4FL83MPjnKdey+qhs2ZX4nP3gUeo9CfkNcClA=; b=S6ShtwiiYS0gBREDbIEMgemyV0QkWzoI1OKUmQGO1o5XvLEksJC0q00dROx28ZS1A/ sECJGIPyGEJ6Mi+0S4FfUKl1y7SGZZnyIS5Q/6Q7D9gynzUk7JDFkZ4vfu/IeGqKhIsw 1ePngGwkN0Eux8BDs01n7102xfpsTKEczNCVFOdH6zCZJT5SVwBsgMnaMoH7H/zVNpRx B8pUX+uNKm1e8KnaFuwt7Gjz1DLYucIpmjUTBz4lLx78po5JTRTgAq8/Cm1egSKYiHvl BKKmpkaA0nNb9vFj37JCTodIu4om+HvWe4RxUtseDZYxzES2F4dWFD2lNTY6vMuLV+oG Xrxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3+MGQm4FL83MPjnKdey+qhs2ZX4nP3gUeo9CfkNcClA=; b=tHOZODEL9JiSzGmg/CqlhtCEFkw0jKQL39aLvdtgR5eJ5hwIGs64IWuk37+eah2aHT vsohIUW+yXRPvRqDvRnFVccpEmItGrLvNsfS+FQ/GN1fKP+FMjv7LGPQbBx8HzbqfSwa njXD1Uf2Wo1R8aWqmZtpxjkveMcE/tPjT6I0KTQ/AaYJBrRMQc2Z3gH6CGuxQjulEyar LodAYBOAz2KODJfXfEpqOZNn3Vy1wTljKS+CIY/2wAcjYXMaggVC0IT63XdZJvVGe3iR HqgktNRzSKgchUdw4vcwP+q7SPg2BqgN/dq9LM/oY+NVG98ZXwV7TFvffz7AUZGpzI7V H6sQ== X-Gm-Message-State: AOAM530ePL7uPobItniunTmAD5FWTuZNEScJmJlbsSpFAPaKocJ/8KcA MRYCFrQdi3cMdwooMmDgGpz0XQ== X-Google-Smtp-Source: ABdhPJybUa9kM15xc3tPb0uSrxIv++2ntwz4op1QY2XITiKPKnaqKXjHRyrmy7pt9ZR1H+jR6XZbtA== X-Received: by 2002:a63:610a:0:b0:3c5:a1f9:c556 with SMTP id v10-20020a63610a000000b003c5a1f9c556mr8668539pgb.366.1651773996473; Thu, 05 May 2022 11:06:36 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id p7-20020a1709028a8700b0015e8d4eb1ffsm1834616plo.73.2022.05.05.11.06.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 11:06:36 -0700 (PDT) Date: Thu, 5 May 2022 11:06:33 -0700 From: Stephen Hemminger To: =?UTF-8?B?U3RhbmlzxYJhdw==?= Kardach Cc: Honnappa Nagarahalli , dev , Frank Zhao , Sam Grove , Marcin Wojtas , upstream@semihalf.com Subject: Re: [PATCH 09/11] test/ring: disable problematic tests for RISC-V Message-ID: <20220505110633.014ca59a@hermes.local> In-Reply-To: References: <20220505173003.3242618-1-kda@semihalf.com> <20220505173003.3242618-10-kda@semihalf.com> <20220505103516.5486d020@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Thu, 5 May 2022 19:43:43 +0200 Stanis=C5=82aw Kardach wrote: > On Thu, May 5, 2022 at 7:35 PM Stephen Hemminger > wrote: >=20 > > On Thu, 5 May 2022 19:30:01 +0200 > > Stanislaw Kardach wrote: > > =20 > > > 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 architec= ture > > > 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 lo= ng > > > 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 > > > --- =20 > > > > It seems to me that fixing the excessive inlining in the ring code > > could benefit all architectures, rather than neutering the tests > > on RISCV. > > =20 > 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). There is no good reason the __rte_always_inline should be in the ring code. The purpose of always inline should be only for code that would break if not inlined.