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 29739428D2; Wed, 5 Apr 2023 12:45:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1631E41611; Wed, 5 Apr 2023 12:45:28 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 1B07541133 for ; Wed, 5 Apr 2023 12:45:27 +0200 (CEST) Received: from frapeml500005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ps1QF1tLXz67GLL; Wed, 5 Apr 2023 18:41:25 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 5 Apr 2023 12:45:26 +0200 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.023; Wed, 5 Apr 2023 12:45:26 +0200 From: Konstantin Ananyev To: Tyler Retzlaff , "dev@dpdk.org" CC: "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "thomas@monjalon.net" , "mb@smartsharesystems.com" Subject: RE: [PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc Thread-Topic: [PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc Thread-Index: AQHZZzEbeQLS5fzOKkiQMXqVX6Q+e68cguIg Date: Wed, 5 Apr 2023 10:45:26 +0000 Message-ID: References: <1680558751-17931-1-git-send-email-roretzla@linux.microsoft.com> <1680638847-26430-1-git-send-email-roretzla@linux.microsoft.com> <1680638847-26430-4-git-send-email-roretzla@linux.microsoft.com> In-Reply-To: <1680638847-26430-4-git-send-email-roretzla@linux.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.34.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 > Inline assembly is not supported for msvc x64 instead use > _mm_{s,l,m}fence() intrinsics. >=20 > Signed-off-by: Tyler Retzlaff > --- > lib/eal/include/generic/rte_atomic.h | 4 ++++ > lib/eal/x86/include/rte_atomic.h | 10 +++++++++- > 2 files changed, 13 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/gener= ic/rte_atomic.h > index 234b268..e973184 100644 > --- a/lib/eal/include/generic/rte_atomic.h > +++ b/lib/eal/include/generic/rte_atomic.h > @@ -116,9 +116,13 @@ > * Guarantees that operation reordering does not occur at compile time > * for operations directly before and after the barrier. > */ > +#ifndef RTE_TOOLCHAIN_MSVC > #define rte_compiler_barrier() do { \ > asm volatile ("" : : : "memory"); \ > } while(0) > +#else > +#define rte_compiler_barrier() _ReadWriteBarrier() > +#endif >=20 > /** > * Synchronization fence between threads based on the specified memory o= rder. > diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_a= tomic.h > index f2ee1a9..7ae3a41 100644 > --- a/lib/eal/x86/include/rte_atomic.h > +++ b/lib/eal/x86/include/rte_atomic.h > @@ -27,9 +27,13 @@ >=20 > #define rte_rmb() _mm_lfence() >=20 > +#ifndef RTE_TOOLCHAIN_MSVC > #define rte_smp_wmb() rte_compiler_barrier() > - > #define rte_smp_rmb() rte_compiler_barrier() > +#else > +#define rte_smp_wmb() _mm_sfence() > +#define rte_smp_rmb() _mm_lfence() With x86 memory model CPU doesn't reorder with older reads and write with o= lder writes (there are few exceptions for writes: NT stores, fast string ops, but I thi= nk it can be skipped here). For more info pls refer to: IA Software Developer's Manual, 3.8.3 8.2 MEMOR= Y ORDERING. That's why DPDK uses compiler_barrier() as expansion of smp_wmb() and smp_r= mb() for x86 platforms. There is nothing wrong in using sfence and lfence here, except that it is p= robably an overkill.=20 > +#endif >=20 > /* > * From Intel Software Development Manual; Vol 3; > @@ -66,11 +70,15 @@ > static __rte_always_inline void > rte_smp_mb(void) > { > +#ifndef RTE_TOOLCHAIN_MSVC > #ifdef RTE_ARCH_I686 > asm volatile("lock addl $0, -128(%%esp); " ::: "memory"); > #else > asm volatile("lock addl $0, -128(%%rsp); " ::: "memory"); > #endif > +#else > + _mm_mfence(); > +#endif > } >=20 > #define rte_io_mb() rte_mb() > -- > 1.8.3.1