From patchwork Tue May 10 11:57:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislaw Kardach X-Patchwork-Id: 110975 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 98304A0093; Tue, 10 May 2022 13:58:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8889742821; Tue, 10 May 2022 13:58:11 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id 22A374161A for ; Tue, 10 May 2022 13:58:10 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id m23so20552584ljc.0 for ; Tue, 10 May 2022 04:58:10 -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:mime-version :content-transfer-encoding; bh=KPogMWIS5IPdJl/edOtpOEk3Vg4+dfZudmlvKb7c99k=; b=ZiLl1M9EcUBoDz/aBoO8MDkmUW/wwUsQhiRoXPw09xOcTpjp8ILbDM6RVxLKqK/vpw vGN6osLl1rtTxktY7/3rEB1C6kx/RlLTKLO8RLIdsa4NA7dz6tOqgYVIPIehamiHmKWO ofC7VtKspENTpnMMRMopxioHBVduiyqGh7ZzFMbVvxGAg8U5hAmiNmWteXg7FRx5MWDt YmvTiURoKM6NikxYLwzwHqZGCtzFJNYWoE31nHXUuLTXfFsWqcT9AXj0YqoAwuuKSQBd ak7E0t9HUhYdYK0IOK8SnuTlze6A1NqORMFvE0Lei9AmLSBPx++BajoL+tdCZoZVz+qm kviA== 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:mime-version :content-transfer-encoding; bh=KPogMWIS5IPdJl/edOtpOEk3Vg4+dfZudmlvKb7c99k=; b=3BEqFNe+wY/bhsx+q0JKBcMcqaMkCqpEnoI601kUQsv4fHobYQgYHZ9ZfmGINKaKvg v/zPkiojrA9h8ZjEimnOkjIcyk5Z47hQetpseJNFNKzpwhHF06A4oeRzxwLuFQ7n+PN9 UVu8DHdCeAab9nl+hC8GynzmV+6zupbH99hL1kGvKjchBay1yvkCpN0AQ8blMy4K9cR6 gy9eHmqyCuHYdC2sG/5btQ/8h+7KI8tnJnSgF0DOk/LHuEqbLiuP5wTJC+6E+XkrlNi+ 9lPU+xhQ1OWs/5RX8+ukmForlI7dCg2814Tzi2F8igegpd4+2sj1nGGy0f0Pdee9c0i3 2iKw== X-Gm-Message-State: AOAM533IyAqWllIJWBWsesB0B4RfXYBXqjYPNe3lKZZQLZHyN09vxkS3 NCRjYM+n868a+af4lYwAV9NDTg== X-Google-Smtp-Source: ABdhPJxuEULne/MdUJpG2zJ24xpYso1Iah9TYVxfJ7q9XX6mIDKo0IcVGkRWXv9Txbxy88HtwsJRQQ== X-Received: by 2002:a05:651c:10b3:b0:24f:1573:bb3c with SMTP id k19-20020a05651c10b300b0024f1573bb3cmr14118894ljn.403.1652183889739; Tue, 10 May 2022 04:58:09 -0700 (PDT) Received: from toster.office.semihalf.net ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id p18-20020a056512235200b00473cb4f7cf6sm2256714lfu.309.2022.05.10.04.58.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 04:58:09 -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 1/1] test/ring: remove excessive inlining Date: Tue, 10 May 2022 13:57:58 +0200 Message-Id: <20220510115758.457794-1-kda@semihalf.com> X-Mailer: git-send-email 2.30.2 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. Fixes: a9fe152363 test/ring: add custom element size functional tests Signed-off-by: Stanislaw Kardach --- 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;