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 3CF9A432D9; Wed, 8 Nov 2023 18:04:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B82E7402BB; Wed, 8 Nov 2023 18:04:54 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 6A727402A7 for ; Wed, 8 Nov 2023 18:04:53 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6E42E3200917; Wed, 8 Nov 2023 12:04:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 08 Nov 2023 12:04:52 -0500 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:sender:subject:subject:to:to; s=fm3; t= 1699463090; x=1699549490; bh=6fBzQKdAc2R+0ZPY8d77Lev/KgzeabW3ma6 VkngziIY=; b=fdG4h/o4Co9xRFwFDn5CvSzLw2TSL1B3AZ6xg5n4A6s7kNHvUNY t8YKZ/RYXSQFH6BkYQ7wJauW4/iCmR3V+O/eElGidZyk8F2hdH391+z8arlyrgR2 TMh8nxZcz2AajyNst2xYLvx532YpUZ/Bj8pyO4fH/B7upGH3/i6qQ/P3FO+RYgOr Sr2eRTdeYy8A2nC/O0TboWi3/dl5IV50kTwz2tU1eJ9IlMOHO8vNAXBiyzREJksP HujKkFCw6AZmFo9P6Oko3TbnmXP2ZTRgNlw8IxYi5iZ7oqPr3Sg4q4VRBROn1Lk/ iwt9b+F2ZWG7D3AUX0lJeviXBpD2AbLFjaA== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699463090; x=1699549490; bh=6fBzQKdAc2R+0ZPY8d77Lev/KgzeabW3ma6 VkngziIY=; b=GPap30qhcNXQtKBoMo8wb09hypgNfcCJR+IZj/FfAkuuwgSl6Z9 46w3tut1VhVAg8GkBWKbVNF5Gy6q1tZsCk0K4MIAaeX8WPACbRkMa0kuQxN/8oFI 0lh41/P2C+Id6c1rysgy5iuicND2vdvb7MRjOOTk1XIJIkPvNWGdKElIN6zSXTiS Si2HgS0Zr4HYNXiFv3XAo/hy5eEBBwLQIk5sIHLaPKJ7elCj+n4zJSiwjvdnidGr TfTSyB/p6IPmk3ZeFovSVGJzU3rGsISuj8lIip4pPrkK+EByawYHf9w3WGaibiUl xXgvkTLRZs7kef0JtMnEavtMfXsjhGOl2Lw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 12:04:48 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff Cc: dev@dpdk.org, Bruce Richardson , David Hunt , Honnappa Nagarahalli , Jerin Jacob , Konstantin Ananyev , Sameh Gobriel , Sunil Kumar Kori , Vladimir Medvedkin , Yipeng Wang Subject: Re: [PATCH 0/5] use rte atomic thread fence Date: Wed, 08 Nov 2023 18:04:47 +0100 Message-ID: <2796747.XrmoMso0CX@thomas> In-Reply-To: <1698894265-22963-1-git-send-email-roretzla@linux.microsoft.com> References: <1698894265-22963-1-git-send-email-roretzla@linux.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 02/11/2023 04:04, Tyler Retzlaff: > Replace use of __atomic_thread_fence with __rte_atomic_thread_fence. > > It may be appropriate to use rte_atomic_thread_fence instead but it > will be up to maintainers to evaluate and make the change if appropriate. I don't understand the use of __rte_atomic_thread_fence which is supposed to be EAL-internal only, isn't it? On x86, we have this: static __rte_always_inline void rte_atomic_thread_fence(rte_memory_order memorder) { if (memorder == rte_memory_order_seq_cst) rte_smp_mb(); else __rte_atomic_thread_fence(memorder); } This is skipped if you use __rte_atomic_thread_fence() directly.