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 4974945523; Fri, 28 Jun 2024 17:20:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37CB7410E7; Fri, 28 Jun 2024 17:20:04 +0200 (CEST) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by mails.dpdk.org (Postfix) with ESMTP id 8925A40A71 for ; Fri, 28 Jun 2024 17:20:02 +0200 (CEST) Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-700cd2cba7bso458965a34.0 for ; Fri, 28 Jun 2024 08:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1719588001; x=1720192801; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=IbAXMNlOr0CUQEhKgOJxl4s50jGvpYxZhX/9cYT/gf8=; b=r8dYPkP5AsPDDbt0W9il0YXKXd61qG9yJpcmZHvG+/hBd6XHrDyHYxLWL+Q/9BgzNX gRCGXNArvFpQxsb8Z6Es3JqLxnMuTs+K3355Dk3HyiJZY038jlqPEM1OMADB8IvtHIFz YTI9Gz3l72mLAbgLpW3ac8JSHOxG4gxE51GeXNpdDY7zKTt+EnMZQHMPORGoXaQGZn1G q4azKdxgLzl/ueAB1Dr/PY/plparVQfvqTys8Z8nRiIW3ZaUL7vfiHY5jLiG2aTmdDXT NcUn1qnklmpvd10HALRgZq9DlHZdKHEpLa+7kJ134FzEzWSnFtQ7ANFXWyVzSc0KHnUB 58JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719588001; x=1720192801; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IbAXMNlOr0CUQEhKgOJxl4s50jGvpYxZhX/9cYT/gf8=; b=ecRdxWMa9qkC4g7NNYkYDgX2nP0/+20+k9TIDJSdnUKz/Bvb+O0kC1UU5ukeYcjM7R OwlecdoNr3uSKz4pdWYYWzdDKf5XgBe9zfHTPt+7WFJsGEU6eBakByT7p9xVL8wKbhrA STcE2VuAuzAqZLKj73Fg1QMx+dIX0YIHlVymGDakmJdJGPynSxX5OGY90PQ7v6fb+nRg L+XY6iMD0scMEZsq55mmYpQIOcWNPshURXU8+mUlemtQrBQLcZjQSUPMMj8GGgnhTSXV he3Bup8Owbx287HeAN7QnxaiE6TpJQXRo1iseibvcuzEHRSi72auYnQASmFWfT/dQGAk igcg== X-Forwarded-Encrypted: i=1; AJvYcCVcYCfNEpwgsZw0d5SOYI0W/EE2ZI6obzFhu25rUPvSN4Kd0l0urkLD8Ol9zjQMrfzf24s1/uijwRB7Oog= X-Gm-Message-State: AOJu0YzfuhifktWWp7l3X14OIZ/40PYxfrMuo6LqVsAgsqhBmkWUaNvh LoA9NvENEB32T1Q/F3UUYp8xOM61ne3JRit6vFZxXi2YUydKgAFs2qd2YVz1rmA= X-Google-Smtp-Source: AGHT+IGpaaAHDV86Q2ojMZ/bKupceCBptrBQPRJ2wCQJ0u1F2a3dlBYe4w8tF1vae79HtoLIHJkRDw== X-Received: by 2002:a05:6871:3429:b0:259:821b:a517 with SMTP id 586e51a60fabf-25d06bc7dccmr16490193fac.10.1719588001522; Fri, 28 Jun 2024 08:20:01 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70804a9540fsm1707640b3a.216.2024.06.28.08.20.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jun 2024 08:20:01 -0700 (PDT) Date: Fri, 28 Jun 2024 08:19:58 -0700 From: Stephen Hemminger To: Daniel Gregory Cc: Thomas Monjalon , Ruifeng Wang , dev@dpdk.org, Punit Agrawal , Liang Ma , feifei.wang2@arm.com, david.marchand@redhat.com Subject: Re: [PATCH v2] eal/arm: replace RTE_BUILD_BUG on non-constant Message-ID: <20240628081958.30fc1662@hermes.local> In-Reply-To: <20240628100520.GA3779302@ste-uk-lab-gw> References: <20240502142116.63760-1-daniel.gregory@bytedance.com> <20240503182730.31693-1-daniel.gregory@bytedance.com> <20240503175905.28c590cf@hermes.local> <6615976.zIJbB62Pao@thomas> <20240628100520.GA3779302@ste-uk-lab-gw> 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 Fri, 28 Jun 2024 11:05:20 +0100 Daniel Gregory wrote: > > > > The ARM implementation of rte_pause uses RTE_BUILD_BUG_ON to check > > > > memorder, which is not constant. This causes compile errors when it= is > > > > enabled with RTE_ARM_USE_WFE. eg. > > > >=20 > > > > ../lib/eal/arm/include/rte_pause_64.h: In function =E2=80=98rte_wai= t_until_equal_16=E2=80=99: > > > > ../lib/eal/include/rte_common.h:530:56: error: expression in static= assertion is not constant > > > > 530 | #define RTE_BUILD_BUG_ON(condition) do { static_assert(!(co= ndition), #condition); } while (0) > > > > | ^~~~= ~~~~~~~~ > > > > ../lib/eal/arm/include/rte_pause_64.h:156:9: note: in expansion of = macro =E2=80=98RTE_BUILD_BUG_ON=E2=80=99 > > > > 156 | RTE_BUILD_BUG_ON(memorder !=3D rte_memory_order_acq= uire && > > > > | ^~~~~~~~~~~~~~~~ > > > >=20 > > > > Fix the compile errors by replacing the check with an assert, like = in > > > > the generic implementation (lib/eal/include/generic/rte_pause.h). = =20 > > >=20 > > > No, don't hide the problem. > > >=20 > > > What code is calling these. Looks like a real bug. Could be behind la= yers of wrappers. =20 > >=20 > > I support Stephen's opinion. > > Please look for the real issue. =20 >=20 > In DPDK, I have found 26 calls of rte_wait_until_equal_16, largely split > between app/test-bbdev/test_bbdev_perf.c and app/test/test_timer.c, with > a couple calls in lib/eal/include/rte_pflock.h and > lib/eal/include/rte_ticketlock.h as well. 16 calls of > rte_wait_until_equal_32, spread amongst various test cases > (test_func_reentrancy.c test_mcslock.c, test_mempool_perf.c, ...), two > drivers (drivers/event/opdl/opdl_ring.c and > drivers/net/thunderx/nicvf_rxrx.c), lib/eal/common/eal_common_mcfg.c, > lib/eal/include/generic/rte_spinlock.h, lib/ring/rte_ring_c11_pvt.h, > lib/ring/rte_ring_generic_pvt.h and lib/eal/include/rte_mcslock.h. There > is a single call to rte_wait_until_equal_64 in app/test/test_pmd_perf.c >=20 > They all correctly use the primitives from rte_stdatomic.h >=20 > As I discussed on another chain > https://lore.kernel.org/dpdk-dev/20240509110251.GA3795959@ste-uk-lab-gw/ > from what I've seen, it seems that neither Clang nor GCC allow for > static checks on the parameters of inline functions. For instance, the > following does not compile: >=20 > static inline __attribute__((always_inline)) int > fn(int val) > { > _Static_assert(val =3D=3D 0, "val nonzero"); > return 0; > } >=20 > int main(void) { > return fn(0); > } >=20 > ( https://godbolt.org/z/TrfWqYoGo ) >=20 > With the same "expression in static assertion is not constant" error > that I get when cross-compiling DPDK for ARM with WFE enabled on main: This is unexpected, but I can validate that it works that way. Maybe because of combination of how inlining works and how the static asserts are evaluated. It does work if fn() is a macro #define fn(val) ({ static_assert(val =3D=3D 0, "val nonzero"); 0; })