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 C908F428BA; Tue, 4 Apr 2023 14:11:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C67A40EF0; Tue, 4 Apr 2023 14:11:10 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id E49A940A7E for ; Tue, 4 Apr 2023 14:11:08 +0200 (CEST) Received: from frapeml500006.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PrRMd0PQvz67lVK; Tue, 4 Apr 2023 20:07:09 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500006.china.huawei.com (7.182.85.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 4 Apr 2023 14:11:07 +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; Tue, 4 Apr 2023 14:11:07 +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 3/9] eal: use barrier intrinsics when compiling with msvc Thread-Topic: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc Thread-Index: AQHZZnap0PZ0bua2nE60okV7Fqc0Ma8bDxDw Date: Tue, 4 Apr 2023 12:11:07 +0000 Message-ID: <754a877d020a4a199a5310b469e876a7@huawei.com> References: <1680558751-17931-1-git-send-email-roretzla@linux.microsoft.com> <1680558751-17931-4-git-send-email-roretzla@linux.microsoft.com> In-Reply-To: <1680558751-17931-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.206.138.42] 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 > _{Read,Write,ReadWrite}Barrier() 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..5cce9ba 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() _WriteBarrier() > +#define rte_smp_rmb() _ReadBarrier() > +#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 > + rte_compiler_barrier(); > +#endif It doesn't look right to me: compiler_barrier is not identical to LOCK-ed o= peration, and is not enough to serve as a proper memory barrier for SMP. Another ore generic comment - do we really need to pollute all that code wi= th RTE_TOOLCHAIN_MSVC ifdefs? Right now we have ability to have subdir per arch (x86/arm/etc.). Can we treat x86+windows+msvc as a special arch? > } >=20 > #define rte_io_mb() rte_mb() > -- > 1.8.3.1