From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by smtp.lore.kernel.org (Postfix) with ESMTP id C68CDC4332F
	for <dpdk-dev@archiver.kernel.org>; Wed,  8 Nov 2023 18:49:25 +0000 (UTC)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id BE5D3410EA;
	Wed,  8 Nov 2023 19:49:23 +0100 (CET)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id C61A9406A2
 for <dev@dpdk.org>; Wed,  8 Nov 2023 19:49:22 +0100 (CET)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id 0D8B320B74C0; Wed,  8 Nov 2023 10:49:22 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0D8B320B74C0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1699469362;
 bh=N1x4sqMS1fBb3nqiQwzSXIxgOuAd7LK2E5/BrDUjeCc=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=n2mKVP9YYC4wnCdvVfy4CTtSUAn08q22XtpVlmwZGxy9CgT97b9htCAc/djUSw1GE
 Sf+MCBOiBIc1lP7npC7jbQabAkOKZyKgbJGZwati9Hr+yqF59zecoQ9zRGVq6/OBJs
 9ElqtDqryRn4veM765m3QGChxCLCiMzJCPElK+xI=
Date: Wed, 8 Nov 2023 10:49:22 -0800
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,
 David Hunt <david.hunt@intel.com>,
 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
 Jerin Jacob <jerinj@marvell.com>,
 Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
 Sameh Gobriel <sameh.gobriel@intel.com>,
 Sunil Kumar Kori <skori@marvell.com>,
 Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
 Yipeng Wang <yipeng1.wang@intel.com>
Subject: Re: [PATCH 0/5] use rte atomic thread fence
Message-ID: <20231108184922.GB21615@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <1698894265-22963-1-git-send-email-roretzla@linux.microsoft.com>
 <2796747.XrmoMso0CX@thomas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2796747.XrmoMso0CX@thomas>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Wed, Nov 08, 2023 at 06:04:47PM +0100, Thomas Monjalon wrote:
> 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.

correct. that is on purpose because the original code was skipping
condition by using __atomic_thread_fence directly.

this series intends no functional change which is why the replacements
are __rte_atomic_thread_fence instead of to rte_atomic_thread_fence.

i would encourage the maintainers to evaluate whether the code can use
rte_atomic_thread_fence directly without functional regression.

ty