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 2BF9345A78; Tue, 15 Oct 2024 21:58:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E09A840144; Tue, 15 Oct 2024 21:58:32 +0200 (CEST) Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) by mails.dpdk.org (Postfix) with ESMTP id 8B3A3400D6 for ; Tue, 15 Oct 2024 21:58:31 +0200 (CEST) Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 146D311400AF; Tue, 15 Oct 2024 15:58:31 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Tue, 15 Oct 2024 15:58:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1729022311; x=1729108711; bh=6wT/r/h6b2q/KUHnosZw4VJ6Qhowb7fXeiUadsWLILc=; b= O0TL22z0n7X6MrxT6mhvN4QBsusfjRPQfm1ht6BnnwOnOg7WjlrvbqP3p2Vy8fZV xVImG2GcvR7xy+hPzL0zeZh8aWJZoM7BoDfqaCERpApY/HJY53yW0dKp2wRsl7c0 zHaSi56wLYmmki3QAInssOZy/1qARcXbuT02VNDfwrKbJhj0LV60UIB4D93ZdvZb 46mZZNz4eugW/ooIbM6r2cYvhYFVMtQMLgnWXc8GN+sMxen4CPBgEBv3sNsJUWTw gH4w+ZJrMR+Uc9MPoC3TrPS7onKKatDcH7cn8k711yFOpc5VTdV7uT613rSdj/kD I/awfH8XXCIexTuinIOT6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1729022311; x= 1729108711; bh=6wT/r/h6b2q/KUHnosZw4VJ6Qhowb7fXeiUadsWLILc=; b=D utPjnAUU/jWONwv14sVwyUmZbPnxTwVvzzK/cWMUORmTHomv/CVKqfhbF+gqOODZ RtUSmoNEYa0FbgH5Zva2Ll2v+UmsxPbvxxYa91p3eHEF9JjKRlEWgPMpMcDCyDpm nMA6OWqB59xAhhf1yWvOqgrMQpARSaIwMVK0CUWhwA53R/a+r+5eQdDDlDBl424w 8Uz9LLSCsZv2gxEmLBnaP9j40DLHs0/ayONX0AlmcRKZO1nKXIyNG8GdG+lfTW3E MK3BcKHvCJKa/isuxPE1qyDauB73LBD6sCPJcVHGDuKC9yND6arjL02zHlo5UeOv EiQhM4O+lVgEvcAHECYLg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdegjedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdej necuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjh grlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeev tdehvedtkeeivdeuuedvieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdp nhgspghrtghpthhtohepjedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgsse hsmhgrrhhtshhhrghrvghshihsthgvmhhsrdgtohhmpdhrtghpthhtohepuggrvhhiugdr mhgrrhgthhgrnhgusehrvgguhhgrthdrtghomhdprhgtphhtthhopeguvghvseguphgukh drohhrghdprhgtphhtthhopegsrhhutggvrdhrihgthhgrrhgushhonhesihhnthgvlhdr tghomhdprhgtphhtthhopehkthhrrgihnhhorhesrhgvughhrghtrdgtohhmpdhrtghpth htohepmhgrthhtihgrshdrrhhonhhnsghlohhmsegvrhhitghsshhonhdrtghomhdprhgt phhtthhopehrohhrvghtiihlrgeslhhinhhugidrmhhitghrohhsohhfthdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Oct 2024 15:58:28 -0400 (EDT) From: Thomas Monjalon To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: David Marchand , dev@dpdk.org, bruce.richardson@intel.com, ktraynor@redhat.com, Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Tyler Retzlaff Subject: Re: [PATCH 2/3] bitset: fix build for GCC without experimental API Date: Tue, 15 Oct 2024 21:58:26 +0200 Message-ID: <11673251.MucGe3eQFb@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7DF@smartserver.smartshare.dk> References: <20241015121046.2556695-1-david.marchand@redhat.com> <10943298.zapYfy813O@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F7DF@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 15/10/2024 16:44, Morten Br=C3=B8rup: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Tuesday, 15 October 2024 16.13 > >=20 > > 15/10/2024 14:53, Morten Br=C3=B8rup: > > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > > @@ -255,7 +255,13 @@ __rte_experimental > > > > static inline bool > > > > rte_bitset_test(const uint64_t *bitset, size_t bit_num) > > > > { > > > > +#ifdef ALLOW_EXPERIMENTAL_API > > > > return __RTE_BITSET_DELEGATE(rte_bit_test, bitset, bit_num); > > > > +#else > > > > + RTE_SET_USED(bitset); > > > > + RTE_SET_USED(bit_num); > > > > + return false; > > > > +#endif > > > > } > > > > > > This looks wrong! The API is exposed, but does nothing. > >=20 > > Yes, this is what we did already in the past for other experimental > > functions > > called from inline functions. > > There is no choice, the compiler is hitting the warning. > >=20 > > > It is possible to build without ALLOW_EXPERIMENTAL_API; the compiler > > will emit warnings when using experimental APIs. > >=20 > > Yes it is possible to build, > > but it is not said it should work the same. > >=20 > > > If those compiler warnings are not handled as errors, the compiled > > application will be full of bugs. > >=20 > > Yes, that's why there are warnings. > > We may document it better but that's the behavior we have for years. > > There is no easy solution, and making experimental functions work > > without defining ALLOW_EXPERIMENTAL_API is not a really interesting > > goal. > > I think the word "allow" suggests it is not supposed to work if not > > allowed. >=20 > There's a world of difference between "experimental, might have bugs" - w= hich is what I (and possibly other DPDK consumers) expect - and "experiment= al, we know for a fact that it doesn't work" - which is quite a surprise to= me. It does not work if you don't enable it, and there is a warning when compiling. > > It would be more interesting to make sure the users understand > > why we have this flag and how to enable it. > > I propose adding some docs, and mentioning ALLOW_EXPERIMENTAL_API > > in the the __rte_experimental message in rte_compat.h. > >=20 >=20 > If we know that some of these warnings cause bugs in DPDK, we should elev= ate these specific instances to error level. Technically I don't know whether it is possible. Look at rte_compat.h > Regarding this specific patch: > Would it be possible to change it to behave like patch 1/3, i.e. complete= ly omit the experimental APIs if ALLOW_EXPERIMENTAL_API is not defined? I disagree, it would be a lot of churn in the code to disable all experimen= tal API calls.