From patchwork Wed May 11 15:07:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislaw Kardach X-Patchwork-Id: 111034 X-Patchwork-Delegate: david.marchand@redhat.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 89960A0032; Wed, 11 May 2022 17:07:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3233040DDD; Wed, 11 May 2022 17:07:49 +0200 (CEST) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mails.dpdk.org (Postfix) with ESMTP id 0B36C406B4 for ; Wed, 11 May 2022 17:07:47 +0200 (CEST) Received: by mail-ej1-f44.google.com with SMTP id i27so4653100ejd.9 for ; Wed, 11 May 2022 08:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NBbVosrxCGv/8ZNQhQBRzHTrfnX92KlH9Tz1+iW6T9A=; b=zwciaBsevjsLevXZX6255ojZHwwuWzrKjQursX1iLdyJV7f0O5LbHq88KsiAxGt6Zw wTG12OuONw1WgVySn4vW8pj9Pxi8RRytSLYH0lowHws0DO/9nnvFUuE64HLtl17bpFLH B9c4UXgQD8myNt+BCwux4UNDXfxv6KyvBAVbDK+rg6WSqtIGqmyaFl/Zm3NN6Fd0hFgq 5ES25DmL7Q/DEblx+iMUDX0d1mb9029eJQxYMHw9srA9Y96TCZiy8PNWBM6sH8o4ShB6 pIDiHV3juL9Vym2+Idy5M/kxLjMkJfdAp0lZrl3C6Gs2TuakeJxsrWjMbWDNKNxr3gWD C/KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NBbVosrxCGv/8ZNQhQBRzHTrfnX92KlH9Tz1+iW6T9A=; b=duCz2C40VXe2/QN/kcSAQ6tNRexLimD/Ak/FBmOTrv7uPZO/LYX6wN+JAy8sMqyBUT gQ3MRjSNrwiEMY8UJLtqNoEzbwDx4AMM8RALyt1HCpLXKMXBMyYJKU4hY4UUtyg0l2Yk zsAiOI7hC2MZ+euGpkRe6u1TMnDbxvZ8dNdjjnNTkeMtHZHQQf4zRBdHwppIg4NTn0N+ 9m6WhGdxRDZNCQOW67VYmOZhw2NN3CPAuPRgM1jDwMsrz2Kyf71jC37OXJX1HRLhp2RB vn35rga3Jw+M3Dnudi4ki/4gZOak9GzaWFb35k6FbNxS2fqgyWN6jG6wf+mgN3isIhhB LIsA== X-Gm-Message-State: AOAM532kdw/e7WJ7byCsGx9niFgD/TbKK7Hxqgpf4YPzA6dnklruc7OF xtp/1SIGu1h8OF4tu3EoKWZLTw== X-Google-Smtp-Source: ABdhPJz3zbnZzW7hui8tm7S8QxnzY1Y32CpoucPVwJfGnzOGO5BYrE5+P2nEcHN9Q1tjBeID41sRKA== X-Received: by 2002:a17:907:96a8:b0:6f4:45f1:6e76 with SMTP id hd40-20020a17090796a800b006f445f16e76mr25909525ejc.186.1652281666645; Wed, 11 May 2022 08:07:46 -0700 (PDT) Received: from localhost.localdomain (89-73-146-138.dynamic.chello.pl. [89.73.146.138]) by smtp.gmail.com with ESMTPSA id bu8-20020a170906a14800b006f3ef214dabsm1128623ejb.17.2022.05.11.08.07.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 May 2022 08:07:46 -0700 (PDT) From: Stanislaw Kardach To: Honnappa Nagarahalli Cc: Stanislaw Kardach , dev@dpdk.org, Frank Zhao , Sam Grove , mw@semihalf.com, upstream@semihalf.com Subject: [PATCH v2 1/1] test/ring: remove excessive inlining Date: Wed, 11 May 2022 17:07:25 +0200 Message-Id: <20220511150725.744021-1-kda@semihalf.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220510115758.457794-1-kda@semihalf.com> References: <20220510115758.457794-1-kda@semihalf.com> MIME-Version: 1.0 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 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 ) 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 Acked-by: Bruce Richardson Reviewed-by: Honnappa Nagarahalli Acked-by: Konstantin Ananyev Reviewed-by: Honnappa Nagarahalli Acked-by: Konstantin Ananyev --- 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;