[PATCH 0/9] msvc integration changes

[PATCH 0/9] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Tyler Retzlaff (9):
  eal: use rdtsc intrinsic when compiling with msvc
  eal: use rtm and xtest intrinsics when compiling with msvc
  eal: use barrier intrinsics when compiling with msvc
  eal: typedef cpu flag enum as int for msvc
  eal: hide GCC extension based alignment markers
  eal: expand most macros to empty when using msvc
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: disable json print formatting with msvc
  telemetry: avoid expanding versioned symbol macros on msvc

 lib/eal/include/generic/rte_atomic.h    | 11 ++++++++++
 lib/eal/include/generic/rte_cpuflags.h  | 12 ++++++-----
 lib/eal/include/rte_branch_prediction.h |  8 +++++++
 lib/eal/include/rte_common.h            | 37 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++
 lib/eal/x86/include/rte_atomic.h        | 14 ++++++++++++-
 lib/eal/x86/include/rte_cycles.h        |  8 +++++++
 lib/eal/x86/include/rte_rtm.h           | 19 +++++++++++++++++
 lib/telemetry/telemetry_data.c          | 16 ++++++++++++++
 lib/telemetry/telemetry_json.h          |  6 ++++++
 10 files changed, 145 insertions(+), 6 deletions(-)

-- 
1.8.3.1

[PATCH 1/9] eal: use rdtsc intrinsic when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use __rdtsc
intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_cycles.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..0c142ce 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,10 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +27,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -47,6 +52,9 @@
 		     "=a" (tsc.lo_32),
 		     "=d" (tsc.hi_32));
 	return tsc.tsc_64;
+#else
+	return __rdtsc();
+#endif
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH 2/9] eal: use rtm and xtest intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use _xbegin,
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_rtm.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..26672cb 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,9 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <immintrin.h>
+#endif
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +31,47 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned int ret = RTE_XBEGIN_STARTED;
 
 	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
 	return ret;
+#else
+	return _xbegin();
+#endif
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+#else
+	_xend();
+#endif
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define rte_xabort(status) do { \
 	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
 } while (0)
+#else
+#define rte_xabort(status) _xabort(status)
+#endif
 
 static __rte_always_inline
 int rte_xtest(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned char out;
 
 	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
 		"=r" (out) :: "memory");
 	return out;
+#else
+	return _xtest();
+#endif
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use
_{Read,Write,ReadWrite}Barrier() intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h |  4 ++++
 lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
 
 #define	rte_rmb() _mm_lfence()
 
+#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
 
 /*
  * 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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Bruce Richardson]

On Mon, Apr 03, 2023 at 02:52:25PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for msvc x64 instead use
> _{Read,Write,ReadWrite}Barrier() intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/generic/rte_atomic.h |  4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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()

Does this actually add a full memory barrier? If so, that's really not what we
want, and will slow things down.

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Tue, Apr 04, 2023 at 09:53:21AM +0100, Bruce Richardson wrote:
> On Mon, Apr 03, 2023 at 02:52:25PM -0700, Tyler Retzlaff wrote:
> > Inline assembly is not supported for msvc x64 instead use
> > _{Read,Write,ReadWrite}Barrier() intrinsics.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/generic/rte_atomic.h |  4 ++++
> >  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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()
> 
> Does this actually add a full memory barrier? If so, that's really not what we
> want, and will slow things down.

for background MSVC when targeting amd64/arm64 do not permit inline
assmebly. The main reason is inline assembly can't be optimized.
instead it provides intrinsics (that are known) that can participate in
optimization.

specific answer to your question.  yes, it implements only a "compiler
barrier" not a full memory barrier preventing processor reordering.

https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
  "Limits the compiler optimizations that can reorder memory accesses
   across the point of the call."

   note: ignore the caution on the documentation it only applies to C++

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Bruce Richardson]

On Tue, Apr 04, 2023 at 08:43:01AM -0700, Tyler Retzlaff wrote:
> On Tue, Apr 04, 2023 at 09:53:21AM +0100, Bruce Richardson wrote:
> > On Mon, Apr 03, 2023 at 02:52:25PM -0700, Tyler Retzlaff wrote:
> > > Inline assembly is not supported for msvc x64 instead use
> > > _{Read,Write,ReadWrite}Barrier() intrinsics.
> > > 
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > >  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > >  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > >  2 files changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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()
> > 
> > Does this actually add a full memory barrier? If so, that's really not what we
> > want, and will slow things down.
> 
> for background MSVC when targeting amd64/arm64 do not permit inline
> assmebly. The main reason is inline assembly can't be optimized.
> instead it provides intrinsics (that are known) that can participate in
> optimization.
> 
> specific answer to your question.  yes, it implements only a "compiler
> barrier" not a full memory barrier preventing processor reordering.
> 
> https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
>   "Limits the compiler optimizations that can reorder memory accesses
>    across the point of the call."
> 
>    note: ignore the caution on the documentation it only applies to C++

Thanks for clarifying. In that case, I think we need a different
macro/barrier for the rte_smp_mp() case. When mixing reads and writes on
x86, there are cases where we actually do need a full memory
barrier/mfence, rather than just a compiler barrier.

/Bruce

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Tue, Apr 04, 2023 at 05:23:07PM +0100, Bruce Richardson wrote:
> On Tue, Apr 04, 2023 at 08:43:01AM -0700, Tyler Retzlaff wrote:
> > On Tue, Apr 04, 2023 at 09:53:21AM +0100, Bruce Richardson wrote:
> > > On Mon, Apr 03, 2023 at 02:52:25PM -0700, Tyler Retzlaff wrote:
> > > > Inline assembly is not supported for msvc x64 instead use
> > > > _{Read,Write,ReadWrite}Barrier() intrinsics.
> > > > 
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > ---
> > > >  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > > >  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > > >  2 files changed, 13 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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()
> > > 
> > > Does this actually add a full memory barrier? If so, that's really not what we
> > > want, and will slow things down.
> > 
> > for background MSVC when targeting amd64/arm64 do not permit inline
> > assmebly. The main reason is inline assembly can't be optimized.
> > instead it provides intrinsics (that are known) that can participate in
> > optimization.
> > 
> > specific answer to your question.  yes, it implements only a "compiler
> > barrier" not a full memory barrier preventing processor reordering.
> > 
> > https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
> >   "Limits the compiler optimizations that can reorder memory accesses
> >    across the point of the call."
> > 
> >    note: ignore the caution on the documentation it only applies to C++
> 
> Thanks for clarifying. In that case, I think we need a different
> macro/barrier for the rte_smp_mp() case. When mixing reads and writes on
> x86, there are cases where we actually do need a full memory
> barrier/mfence, rather than just a compiler barrier.

yes, unfortunately i got distracted by expansion of rte_smp_{w,r}mp()
macros in lib/eal/x86/include/rte_atomic.h and assumed they were compiler
barriers. i can see now i should have been looking at the documentation
comments of the inline function prototypes in lib/eal/include/generic/rte_atomic.h

> 
> /Bruce

RE: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

> Inline assembly is not supported for msvc x64 instead use
> _{Read,Write,ReadWrite}Barrier() intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/generic/rte_atomic.h |  4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> 
>  /**
>   * Synchronization fence between threads based on the specified memory order.
> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> 
>  #define	rte_rmb() _mm_lfence()
> 
> +#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
> 
>  /*
>   * 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 operation,
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 with 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?

>  }
> 
>  #define rte_io_mb() rte_mb()
> --
> 1.8.3.1

RE: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Morten Brørup]

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Tuesday, 4 April 2023 14.11

[...]

> Another ore generic comment - do we really need to pollute all that code with
> 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?

I disagree with the per-arch suggestion.

We should have arch directories in EAL only, where the differences are significant.

Anything else, such as drivers and libraries, should be allowed to implement architecture and compiler specific variants using #ifdef or subdirectories/-files as the developer deems appropriate, i.e. #ifdef for few/minor variations, and subfiles or -directories for larger variations.

Multi-architecture code is voluminous, but I don't want separate files for only small variations.

It would be nice to agree on some official guidance on this for the coding guidelines.

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Tue, Apr 04, 2023 at 12:11:07PM +0000, Konstantin Ananyev wrote:
> 
> 
> > Inline assembly is not supported for msvc x64 instead use
> > _{Read,Write,ReadWrite}Barrier() intrinsics.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/generic/rte_atomic.h |  4 ++++
> >  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > 
> >  /**
> >   * Synchronization fence between threads based on the specified memory order.
> > diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > 
> >  #define	rte_rmb() _mm_lfence()
> > 
> > +#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
> > 
> >  /*
> >   * 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 operation,
> and is not enough to serve as a proper memory barrier for SMP.

i think i'm confused by the macro naming here.  i'll take another look
thank you for raising it.

> 
> Another ore generic comment - do we really need to pollute all that code with 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?

i asked this question previously and confirmed in the technical board
meeting. the answer i received was that the community did not want new
directory/headers introduced for compiler support matrix and i should
use #ifdef in the existing headers.

> 
> >  }
> > 
> >  #define rte_io_mb() rte_mb()
> > --
> > 1.8.3.1

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

04/04/2023 16:49, Tyler Retzlaff пишет:
> On Tue, Apr 04, 2023 at 12:11:07PM +0000, Konstantin Ananyev wrote:
>>
>>
>>> Inline assembly is not supported for msvc x64 instead use
>>> _{Read,Write,ReadWrite}Barrier() intrinsics.
>>>
>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>> ---
>>>   lib/eal/include/generic/rte_atomic.h |  4 ++++
>>>   lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>>>   2 files changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
>>>
>>>   /**
>>>    * Synchronization fence between threads based on the specified memory order.
>>> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
>>>
>>>   #define	rte_rmb() _mm_lfence()
>>>
>>> +#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
>>>
>>>   /*
>>>    * 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 operation,
>> and is not enough to serve as a proper memory barrier for SMP.
> 
> i think i'm confused by the macro naming here.  i'll take another look
> thank you for raising it.
> 
>>
>> Another ore generic comment - do we really need to pollute all that code with 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?
> 
> i asked this question previously and confirmed in the technical board
> meeting. the answer i received was that the community did not want new
> directory/headers introduced for compiler support matrix and i should
> use #ifdef in the existing headers.

Ok, can I then ask at least to minimize number of ifdefs to absolute 
minimum?
It is really hard to read an follow acode that is heavily ifdefed.
Let say above we probably don't need to re-define 
rte_smp_rmb/rte_smp_wmb, as both are boiled down to compiler_barrier(), 
which is already redefined.
Another question - could it be visa-versa approach:
can we replace some inline assembly with common instincts whenever possible?

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 12:49:21AM +0100, Konstantin Ananyev wrote:
> 04/04/2023 16:49, Tyler Retzlaff пишет:
> >On Tue, Apr 04, 2023 at 12:11:07PM +0000, Konstantin Ananyev wrote:
> >>
> >>
> >>>Inline assembly is not supported for msvc x64 instead use
> >>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> >>>
> >>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >>>---
> >>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> >>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> >>>  2 files changed, 13 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> >>>
> >>>  /**
> >>>   * Synchronization fence between threads based on the specified memory order.
> >>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> >>>
> >>>  #define	rte_rmb() _mm_lfence()
> >>>
> >>>+#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
> >>>
> >>>  /*
> >>>   * 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 operation,
> >>and is not enough to serve as a proper memory barrier for SMP.
> >
> >i think i'm confused by the macro naming here.  i'll take another look
> >thank you for raising it.
> >
> >>
> >>Another ore generic comment - do we really need to pollute all that code with 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?
> >
> >i asked this question previously and confirmed in the technical board
> >meeting. the answer i received was that the community did not want new
> >directory/headers introduced for compiler support matrix and i should
> >use #ifdef in the existing headers.
> 
> Ok, can I then ask at least to minimize number of ifdefs to absolute
> minimum?

in principal no objection at all, one question though is what to do with
comment based documentation attached to macros? e.g.

#ifdef SOME_FOO
/* some documentation */
#define some_macro
#else
#define some_macro
#endif

#ifdef SOME_FOO
/* some documentation 2 */
#define some_macro2
#else
#define some_macro2
#endif

i can either duplicate the documentation for every define so it stays
"attached" or i can only document the first expansion. let me know what
you expect.

so something like this?

#ifdef SOME_FOO
/* some documentation */
#define some_macro
/* some documentation 2 */
#define some_macro2
#else
#define some_macro
#define some_macro2
#endif

or should all documentation be duplicated? which can become a teadious
redundancy for anyone maintaining it. keep in mind we might have to make
an exception for rte_common.h because it seems doing this would be
really ugly there. take a look let me know.

> It is really hard to read an follow acode that is heavily ifdefed.
> Let say above we probably don't need to re-define
> rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> compiler_barrier(), which is already redefined.

can you take a look at v2 of the patch and re-prescribe your advise
here? in v2 only the intel macros expand to the compiler barrier. though
i find this vexing since as you pointed out it seems they aren't
supposed to be compiler only barriers according to the documentation in
generic/rte_atomic.h they are intended to be memory barriers.

please help me if i've goofed up in this regard.

> Another question - could it be visa-versa approach:
> can we replace some inline assembly with common instincts whenever possible?

msvc has only intrinsics and the conditional expansion for msvc is to
use those intrinsics, gcc doesn't generally define intrinsics for processor
specific code does it?

thanks

RE: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

> > >>>Inline assembly is not supported for msvc x64 instead use
> > >>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> > >>>
> > >>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > >>>---
> > >>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > >>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > >>>  2 files changed, 13 insertions(+), 1 deletion(-)
> > >>>
> > >>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > >>>
> > >>>  /**
> > >>>   * Synchronization fence between threads based on the specified memory order.
> > >>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > >>>
> > >>>  #define	rte_rmb() _mm_lfence()
> > >>>
> > >>>+#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
> > >>>
> > >>>  /*
> > >>>   * 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 operation,
> > >>and is not enough to serve as a proper memory barrier for SMP.
> > >
> > >i think i'm confused by the macro naming here.  i'll take another look
> > >thank you for raising it.
> > >
> > >>
> > >>Another ore generic comment - do we really need to pollute all that code with 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?
> > >
> > >i asked this question previously and confirmed in the technical board
> > >meeting. the answer i received was that the community did not want new
> > >directory/headers introduced for compiler support matrix and i should
> > >use #ifdef in the existing headers.
> >
> > Ok, can I then ask at least to minimize number of ifdefs to absolute
> > minimum?
> 
> in principal no objection at all, one question though is what to do with
> comment based documentation attached to macros? e.g.
> 
> #ifdef SOME_FOO
> /* some documentation */
> #define some_macro
> #else
> #define some_macro
> #endif
> 
> #ifdef SOME_FOO
> /* some documentation 2 */
> #define some_macro2
> #else
> #define some_macro2
> #endif
> 
> i can either duplicate the documentation for every define so it stays
> "attached" or i can only document the first expansion. let me know what
> you expect.
> 
> so something like this?
> 
> #ifdef SOME_FOO
> /* some documentation */
> #define some_macro
> /* some documentation 2 */
> #define some_macro2
> #else
> #define some_macro
> #define some_macro2
> #endif
> 
> or should all documentation be duplicated? which can become a teadious
> redundancy for anyone maintaining it. keep in mind we might have to make
> an exception for rte_common.h because it seems doing this would be
> really ugly there. take a look let me know.

My personal preference would be to keep one documentation block for both cases
(yes, I suppose it needs to be updated if required):

/* some documentation, probably for both SOME_FOO on/off */
#ifdef SOME_FOO
#define some_macro
#else
#define some_macro
#endif 


> 
> > It is really hard to read an follow acode that is heavily ifdefed.
> > Let say above we probably don't need to re-define
> > rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> > compiler_barrier(), which is already redefined.
> 
> can you take a look at v2 of the patch and re-prescribe your advise
> here? in v2 only the intel macros expand to the compiler barrier. though
> i find this vexing since as you pointed out it seems they aren't
> supposed to be compiler only barriers according to the documentation in
> generic/rte_atomic.h they are intended to be memory barriers.

Commented, pls check if I explained my thoughts clear enough there.
 
> 
> please help me if i've goofed up in this regard.
> 
> > Another question - could it be visa-versa approach:
> > can we replace some inline assembly with common instincts whenever possible?
> 
> msvc has only intrinsics and the conditional expansion for msvc is to
> use those intrinsics, gcc doesn't generally define intrinsics for processor
> specific code does it?

AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
So my thought was - might be we can use same instincts for all compilers...
One implication I can think about - older versions of gcc.
But might be we can re-order things and have inlines only for these oldere gcc versions?

 

RE: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Morten Brørup]

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Wednesday, 5 April 2023 12.57
> 
> > > >>Another ore generic comment - do we really need to pollute all that code
> with 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?
> > > >
> > > >i asked this question previously and confirmed in the technical board
> > > >meeting. the answer i received was that the community did not want new
> > > >directory/headers introduced for compiler support matrix and i should
> > > >use #ifdef in the existing headers.
> > >
> > > Ok, can I then ask at least to minimize number of ifdefs to absolute
> > > minimum?
> >
> > in principal no objection at all, one question though is what to do with
> > comment based documentation attached to macros? e.g.
> >
> > #ifdef SOME_FOO
> > /* some documentation */
> > #define some_macro
> > #else
> > #define some_macro
> > #endif
> >
> > #ifdef SOME_FOO
> > /* some documentation 2 */
> > #define some_macro2
> > #else
> > #define some_macro2
> > #endif
> >
> > i can either duplicate the documentation for every define so it stays
> > "attached" or i can only document the first expansion. let me know what
> > you expect.
> >
> > so something like this?
> >
> > #ifdef SOME_FOO
> > /* some documentation */
> > #define some_macro
> > /* some documentation 2 */
> > #define some_macro2
> > #else
> > #define some_macro
> > #define some_macro2
> > #endif
> >
> > or should all documentation be duplicated? which can become a teadious
> > redundancy for anyone maintaining it. keep in mind we might have to make
> > an exception for rte_common.h because it seems doing this would be
> > really ugly there. take a look let me know.
> 
> My personal preference would be to keep one documentation block for both cases
> (yes, I suppose it needs to be updated if required):
> 
> /* some documentation, probably for both SOME_FOO on/off */
> #ifdef SOME_FOO
> #define some_macro
> #else
> #define some_macro
> #endif
> 

Or the third option of using a dummy for documentation purposes only. rte_memcpy() does this [1], although it is an inline function and not a macro.

[1]: https://elixir.bootlin.com/dpdk/v23.03/source/lib/eal/include/generic/rte_memcpy.h#L90

No preferences here, just mentioning it!

> 
> >
> > > It is really hard to read an follow acode that is heavily ifdefed.

Yes, and sometimes it is even harder reading code that is spread across multiple arch-depending files.

It is a choice between the plague or cholera.

But it is one of the unavoidable downsides to supporting many architectures and compilers, so we have to seek out the best compromises.

> > > Let say above we probably don't need to re-define
> > > rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> > > compiler_barrier(), which is already redefined.

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 02:35:47PM +0200, Morten Brørup wrote:
> > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > Sent: Wednesday, 5 April 2023 12.57
> > 
> > > > >>Another ore generic comment - do we really need to pollute all that code
> > with 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?
> > > > >
> > > > >i asked this question previously and confirmed in the technical board
> > > > >meeting. the answer i received was that the community did not want new
> > > > >directory/headers introduced for compiler support matrix and i should
> > > > >use #ifdef in the existing headers.
> > > >
> > > > Ok, can I then ask at least to minimize number of ifdefs to absolute
> > > > minimum?
> > >
> > > in principal no objection at all, one question though is what to do with
> > > comment based documentation attached to macros? e.g.
> > >
> > > #ifdef SOME_FOO
> > > /* some documentation */
> > > #define some_macro
> > > #else
> > > #define some_macro
> > > #endif
> > >
> > > #ifdef SOME_FOO
> > > /* some documentation 2 */
> > > #define some_macro2
> > > #else
> > > #define some_macro2
> > > #endif
> > >
> > > i can either duplicate the documentation for every define so it stays
> > > "attached" or i can only document the first expansion. let me know what
> > > you expect.
> > >
> > > so something like this?
> > >
> > > #ifdef SOME_FOO
> > > /* some documentation */
> > > #define some_macro
> > > /* some documentation 2 */
> > > #define some_macro2
> > > #else
> > > #define some_macro
> > > #define some_macro2
> > > #endif
> > >
> > > or should all documentation be duplicated? which can become a teadious
> > > redundancy for anyone maintaining it. keep in mind we might have to make
> > > an exception for rte_common.h because it seems doing this would be
> > > really ugly there. take a look let me know.
> > 
> > My personal preference would be to keep one documentation block for both cases
> > (yes, I suppose it needs to be updated if required):
> > 
> > /* some documentation, probably for both SOME_FOO on/off */
> > #ifdef SOME_FOO
> > #define some_macro
> > #else
> > #define some_macro
> > #endif
> > 
> 
> Or the third option of using a dummy for documentation purposes only. rte_memcpy() does this [1], although it is an inline function and not a macro.
> 
> [1]: https://elixir.bootlin.com/dpdk/v23.03/source/lib/eal/include/generic/rte_memcpy.h#L90
> 
> No preferences here, just mentioning it!
> 
> > 
> > >
> > > > It is really hard to read an follow acode that is heavily ifdefed.
> 
> Yes, and sometimes it is even harder reading code that is spread across multiple arch-depending files.
> 
> It is a choice between the plague or cholera.
> 
> But it is one of the unavoidable downsides to supporting many architectures and compilers, so we have to seek out the best compromises.

yes, there is a conditional that has to be *somewhere*. i would propose
for now that it be done per-macro or whatever. but when i get the bulk
of the changes in i can commit to refactoring some groups out into their
own header. rte_common.h is a good candidate for this because of how
many conditionals it will contain.

generic/rte_common.h
-> msvc/rte_common.h #include "generic/rte_common.h"
-> gnu?/rte_common.h #include "generic/rte_common.h"

this could carry inline/macro documentation in generic/rte_common.h but
again i'd prefer to do this after msvc work is stood up at least to the
point of having unit tests working before i start moving code around.

for other conditionals i don't think it's worth having a whole file e.g.
x86/include/rte_pause.h or something only a couple of blocks are
conditional.


ty

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

05/04/2023 16:38, Tyler Retzlaff пишет:
> On Wed, Apr 05, 2023 at 02:35:47PM +0200, Morten Brørup wrote:
>>> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
>>> Sent: Wednesday, 5 April 2023 12.57
>>>
>>>>>>> Another ore generic comment - do we really need to pollute all that code
>>> with 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?
>>>>>>
>>>>>> i asked this question previously and confirmed in the technical board
>>>>>> meeting. the answer i received was that the community did not want new
>>>>>> directory/headers introduced for compiler support matrix and i should
>>>>>> use #ifdef in the existing headers.
>>>>>
>>>>> Ok, can I then ask at least to minimize number of ifdefs to absolute
>>>>> minimum?
>>>>
>>>> in principal no objection at all, one question though is what to do with
>>>> comment based documentation attached to macros? e.g.
>>>>
>>>> #ifdef SOME_FOO
>>>> /* some documentation */
>>>> #define some_macro
>>>> #else
>>>> #define some_macro
>>>> #endif
>>>>
>>>> #ifdef SOME_FOO
>>>> /* some documentation 2 */
>>>> #define some_macro2
>>>> #else
>>>> #define some_macro2
>>>> #endif
>>>>
>>>> i can either duplicate the documentation for every define so it stays
>>>> "attached" or i can only document the first expansion. let me know what
>>>> you expect.
>>>>
>>>> so something like this?
>>>>
>>>> #ifdef SOME_FOO
>>>> /* some documentation */
>>>> #define some_macro
>>>> /* some documentation 2 */
>>>> #define some_macro2
>>>> #else
>>>> #define some_macro
>>>> #define some_macro2
>>>> #endif
>>>>
>>>> or should all documentation be duplicated? which can become a teadious
>>>> redundancy for anyone maintaining it. keep in mind we might have to make
>>>> an exception for rte_common.h because it seems doing this would be
>>>> really ugly there. take a look let me know.
>>>
>>> My personal preference would be to keep one documentation block for both cases
>>> (yes, I suppose it needs to be updated if required):
>>>
>>> /* some documentation, probably for both SOME_FOO on/off */
>>> #ifdef SOME_FOO
>>> #define some_macro
>>> #else
>>> #define some_macro
>>> #endif
>>>
>>
>> Or the third option of using a dummy for documentation purposes only. rte_memcpy() does this [1], although it is an inline function and not a macro.
>>
>> [1]: https://elixir.bootlin.com/dpdk/v23.03/source/lib/eal/include/generic/rte_memcpy.h#L90
>>
>> No preferences here, just mentioning it!
>>
>>>
>>>>
>>>>> It is really hard to read an follow acode that is heavily ifdefed.
>>
>> Yes, and sometimes it is even harder reading code that is spread across multiple arch-depending files.
>>
>> It is a choice between the plague or cholera.

That's an interesting analogy - never thought about programming
as a decease :)
Back to the subject, at least to me two clear files with one conditional
include is much more sane then one file with bunch of ifdefs inside.

>>
>> But it is one of the unavoidable downsides to supporting many architectures and compilers, so we have to seek out the best compromises.
> 
> yes, there is a conditional that has to be *somewhere*. i would propose
> for now that it be done per-macro or whatever. but when i get the bulk
> of the changes in i can commit to refactoring some groups out into their
> own header. rte_common.h is a good candidate for this because of how
> many conditionals it will contain.
> 
> generic/rte_common.h
> -> msvc/rte_common.h #include "generic/rte_common.h"
> -> gnu?/rte_common.h #include "generic/rte_common.h"
> 
> this could carry inline/macro documentation in generic/rte_common.h but
> again i'd prefer to do this after msvc work is stood up at least to the
> point of having unit tests working before i start moving code around.

About special rte_common.h for msvc - that sounds like a good option to me.

> for other conditionals i don't think it's worth having a whole file e.g.
> x86/include/rte_pause.h or something only a couple of blocks are
> conditional.
> 
> 
> ty
> 

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 10:57:02AM +0000, Konstantin Ananyev wrote:
> 
> > > >>>Inline assembly is not supported for msvc x64 instead use
> > > >>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> > > >>>
> > > >>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > >>>---
> > > >>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > > >>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > > >>>  2 files changed, 13 insertions(+), 1 deletion(-)
> > > >>>
> > > >>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > > >>>
> > > >>>  /**
> > > >>>   * Synchronization fence between threads based on the specified memory order.
> > > >>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > > >>>
> > > >>>  #define	rte_rmb() _mm_lfence()
> > > >>>
> > > >>>+#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
> > > >>>
> > > >>>  /*
> > > >>>   * 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 operation,
> > > >>and is not enough to serve as a proper memory barrier for SMP.
> > > >
> > > >i think i'm confused by the macro naming here.  i'll take another look
> > > >thank you for raising it.
> > > >
> > > >>
> > > >>Another ore generic comment - do we really need to pollute all that code with 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?
> > > >
> > > >i asked this question previously and confirmed in the technical board
> > > >meeting. the answer i received was that the community did not want new
> > > >directory/headers introduced for compiler support matrix and i should
> > > >use #ifdef in the existing headers.
> > >
> > > Ok, can I then ask at least to minimize number of ifdefs to absolute
> > > minimum?
> > 
> > in principal no objection at all, one question though is what to do with
> > comment based documentation attached to macros? e.g.
> > 
> > #ifdef SOME_FOO
> > /* some documentation */
> > #define some_macro
> > #else
> > #define some_macro
> > #endif
> > 
> > #ifdef SOME_FOO
> > /* some documentation 2 */
> > #define some_macro2
> > #else
> > #define some_macro2
> > #endif
> > 
> > i can either duplicate the documentation for every define so it stays
> > "attached" or i can only document the first expansion. let me know what
> > you expect.
> > 
> > so something like this?
> > 
> > #ifdef SOME_FOO
> > /* some documentation */
> > #define some_macro
> > /* some documentation 2 */
> > #define some_macro2
> > #else
> > #define some_macro
> > #define some_macro2
> > #endif
> > 
> > or should all documentation be duplicated? which can become a teadious
> > redundancy for anyone maintaining it. keep in mind we might have to make
> > an exception for rte_common.h because it seems doing this would be
> > really ugly there. take a look let me know.
> 
> My personal preference would be to keep one documentation block for both cases
> (yes, I suppose it needs to be updated if required):
> 
> /* some documentation, probably for both SOME_FOO on/off */
> #ifdef SOME_FOO
> #define some_macro
> #else
> #define some_macro
> #endif 
> 
> 
> > 
> > > It is really hard to read an follow acode that is heavily ifdefed.
> > > Let say above we probably don't need to re-define
> > > rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> > > compiler_barrier(), which is already redefined.
> > 
> > can you take a look at v2 of the patch and re-prescribe your advise
> > here? in v2 only the intel macros expand to the compiler barrier. though
> > i find this vexing since as you pointed out it seems they aren't
> > supposed to be compiler only barriers according to the documentation in
> > generic/rte_atomic.h they are intended to be memory barriers.
> 
> Commented, pls check if I explained my thoughts clear enough there.
>  
> > 
> > please help me if i've goofed up in this regard.
> > 
> > > Another question - could it be visa-versa approach:
> > > can we replace some inline assembly with common instincts whenever possible?
> > 
> > msvc has only intrinsics and the conditional expansion for msvc is to
> > use those intrinsics, gcc doesn't generally define intrinsics for processor
> > specific code does it?
> 
> AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
> So my thought was - might be we can use same instincts for all compilers...
> One implication I can think about - older versions of gcc.
> But might be we can re-order things and have inlines only for these oldere gcc versions?

i'm going to propose if we do this we do it as a separate change later.

i fear it could turn into the following dance which seems not a lot
better given i'm sure some people will argue there is no benefit to
removing inline assembly for gcc/clang. my preference is not to get
side-tracked on refactoring with the short merge window.

#if (defined(__clang__) && clang version < x) ||
    (defined(__GNUC__) && gcc version < x)
__asm(whatever...
#else
__rdtsc()
#endif

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

06/04/2023 01:07, Tyler Retzlaff пишет:
> On Wed, Apr 05, 2023 at 10:57:02AM +0000, Konstantin Ananyev wrote:
>>
>>>>>>> Inline assembly is not supported for msvc x64 instead use
>>>>>>> _{Read,Write,ReadWrite}Barrier() intrinsics.
>>>>>>>
>>>>>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>>>>>> ---
>>>>>>>   lib/eal/include/generic/rte_atomic.h |  4 ++++
>>>>>>>   lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>>>>>>>   2 files changed, 13 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
>>>>>>>
>>>>>>>   /**
>>>>>>>    * Synchronization fence between threads based on the specified memory order.
>>>>>>> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
>>>>>>>
>>>>>>>   #define	rte_rmb() _mm_lfence()
>>>>>>>
>>>>>>> +#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
>>>>>>>
>>>>>>>   /*
>>>>>>>    * 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 operation,
>>>>>> and is not enough to serve as a proper memory barrier for SMP.
>>>>>
>>>>> i think i'm confused by the macro naming here.  i'll take another look
>>>>> thank you for raising it.
>>>>>
>>>>>>
>>>>>> Another ore generic comment - do we really need to pollute all that code with 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?
>>>>>
>>>>> i asked this question previously and confirmed in the technical board
>>>>> meeting. the answer i received was that the community did not want new
>>>>> directory/headers introduced for compiler support matrix and i should
>>>>> use #ifdef in the existing headers.
>>>>
>>>> Ok, can I then ask at least to minimize number of ifdefs to absolute
>>>> minimum?
>>>
>>> in principal no objection at all, one question though is what to do with
>>> comment based documentation attached to macros? e.g.
>>>
>>> #ifdef SOME_FOO
>>> /* some documentation */
>>> #define some_macro
>>> #else
>>> #define some_macro
>>> #endif
>>>
>>> #ifdef SOME_FOO
>>> /* some documentation 2 */
>>> #define some_macro2
>>> #else
>>> #define some_macro2
>>> #endif
>>>
>>> i can either duplicate the documentation for every define so it stays
>>> "attached" or i can only document the first expansion. let me know what
>>> you expect.
>>>
>>> so something like this?
>>>
>>> #ifdef SOME_FOO
>>> /* some documentation */
>>> #define some_macro
>>> /* some documentation 2 */
>>> #define some_macro2
>>> #else
>>> #define some_macro
>>> #define some_macro2
>>> #endif
>>>
>>> or should all documentation be duplicated? which can become a teadious
>>> redundancy for anyone maintaining it. keep in mind we might have to make
>>> an exception for rte_common.h because it seems doing this would be
>>> really ugly there. take a look let me know.
>>
>> My personal preference would be to keep one documentation block for both cases
>> (yes, I suppose it needs to be updated if required):
>>
>> /* some documentation, probably for both SOME_FOO on/off */
>> #ifdef SOME_FOO
>> #define some_macro
>> #else
>> #define some_macro
>> #endif
>>
>>
>>>
>>>> It is really hard to read an follow acode that is heavily ifdefed.
>>>> Let say above we probably don't need to re-define
>>>> rte_smp_rmb/rte_smp_wmb, as both are boiled down to
>>>> compiler_barrier(), which is already redefined.
>>>
>>> can you take a look at v2 of the patch and re-prescribe your advise
>>> here? in v2 only the intel macros expand to the compiler barrier. though
>>> i find this vexing since as you pointed out it seems they aren't
>>> supposed to be compiler only barriers according to the documentation in
>>> generic/rte_atomic.h they are intended to be memory barriers.
>>
>> Commented, pls check if I explained my thoughts clear enough there.
>>   
>>>
>>> please help me if i've goofed up in this regard.
>>>
>>>> Another question - could it be visa-versa approach:
>>>> can we replace some inline assembly with common instincts whenever possible?
>>>
>>> msvc has only intrinsics and the conditional expansion for msvc is to
>>> use those intrinsics, gcc doesn't generally define intrinsics for processor
>>> specific code does it?
>>
>> AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
>> So my thought was - might be we can use same instincts for all compilers...
>> One implication I can think about - older versions of gcc.
>> But might be we can re-order things and have inlines only for these oldere gcc versions?
> 
> i'm going to propose if we do this we do it as a separate change later.
> 
> i fear it could turn into the following dance which seems not a lot
> better given i'm sure some people will argue there is no benefit to
> removing inline assembly for gcc/clang. my preference is not to get
> side-tracked on refactoring with the short merge window.
> 
> #if (defined(__clang__) && clang version < x) ||
>      (defined(__GNUC__) && gcc version < x)
> __asm(whatever...
> #else
> __rdtsc()
> #endif


Played a bit with https://godbolt.org/.
It seems that __rdtsc()  and RMT builtins (xbegin/xend/xtest) are 
supported all way down to gcc 4.8.1.

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Mon, Apr 10, 2023 at 09:02:00PM +0100, Konstantin Ananyev wrote:
> 06/04/2023 01:07, Tyler Retzlaff пишет:
> >On Wed, Apr 05, 2023 at 10:57:02AM +0000, Konstantin Ananyev wrote:
> >>
> >>>>>>>Inline assembly is not supported for msvc x64 instead use
> >>>>>>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> >>>>>>>
> >>>>>>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >>>>>>>---
> >>>>>>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> >>>>>>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> >>>>>>>  2 files changed, 13 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> >>>>>>>
> >>>>>>>  /**
> >>>>>>>   * Synchronization fence between threads based on the specified memory order.
> >>>>>>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> >>>>>>>
> >>>>>>>  #define	rte_rmb() _mm_lfence()
> >>>>>>>
> >>>>>>>+#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
> >>>>>>>
> >>>>>>>  /*
> >>>>>>>   * 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 operation,
> >>>>>>and is not enough to serve as a proper memory barrier for SMP.
> >>>>>
> >>>>>i think i'm confused by the macro naming here.  i'll take another look
> >>>>>thank you for raising it.
> >>>>>
> >>>>>>
> >>>>>>Another ore generic comment - do we really need to pollute all that code with 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?
> >>>>>
> >>>>>i asked this question previously and confirmed in the technical board
> >>>>>meeting. the answer i received was that the community did not want new
> >>>>>directory/headers introduced for compiler support matrix and i should
> >>>>>use #ifdef in the existing headers.
> >>>>
> >>>>Ok, can I then ask at least to minimize number of ifdefs to absolute
> >>>>minimum?
> >>>
> >>>in principal no objection at all, one question though is what to do with
> >>>comment based documentation attached to macros? e.g.
> >>>
> >>>#ifdef SOME_FOO
> >>>/* some documentation */
> >>>#define some_macro
> >>>#else
> >>>#define some_macro
> >>>#endif
> >>>
> >>>#ifdef SOME_FOO
> >>>/* some documentation 2 */
> >>>#define some_macro2
> >>>#else
> >>>#define some_macro2
> >>>#endif
> >>>
> >>>i can either duplicate the documentation for every define so it stays
> >>>"attached" or i can only document the first expansion. let me know what
> >>>you expect.
> >>>
> >>>so something like this?
> >>>
> >>>#ifdef SOME_FOO
> >>>/* some documentation */
> >>>#define some_macro
> >>>/* some documentation 2 */
> >>>#define some_macro2
> >>>#else
> >>>#define some_macro
> >>>#define some_macro2
> >>>#endif
> >>>
> >>>or should all documentation be duplicated? which can become a teadious
> >>>redundancy for anyone maintaining it. keep in mind we might have to make
> >>>an exception for rte_common.h because it seems doing this would be
> >>>really ugly there. take a look let me know.
> >>
> >>My personal preference would be to keep one documentation block for both cases
> >>(yes, I suppose it needs to be updated if required):
> >>
> >>/* some documentation, probably for both SOME_FOO on/off */
> >>#ifdef SOME_FOO
> >>#define some_macro
> >>#else
> >>#define some_macro
> >>#endif
> >>
> >>
> >>>
> >>>>It is really hard to read an follow acode that is heavily ifdefed.
> >>>>Let say above we probably don't need to re-define
> >>>>rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> >>>>compiler_barrier(), which is already redefined.
> >>>
> >>>can you take a look at v2 of the patch and re-prescribe your advise
> >>>here? in v2 only the intel macros expand to the compiler barrier. though
> >>>i find this vexing since as you pointed out it seems they aren't
> >>>supposed to be compiler only barriers according to the documentation in
> >>>generic/rte_atomic.h they are intended to be memory barriers.
> >>
> >>Commented, pls check if I explained my thoughts clear enough there.
> >>>
> >>>please help me if i've goofed up in this regard.
> >>>
> >>>>Another question - could it be visa-versa approach:
> >>>>can we replace some inline assembly with common instincts whenever possible?
> >>>
> >>>msvc has only intrinsics and the conditional expansion for msvc is to
> >>>use those intrinsics, gcc doesn't generally define intrinsics for processor
> >>>specific code does it?
> >>
> >>AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
> >>So my thought was - might be we can use same instincts for all compilers...
> >>One implication I can think about - older versions of gcc.
> >>But might be we can re-order things and have inlines only for these oldere gcc versions?
> >
> >i'm going to propose if we do this we do it as a separate change later.
> >
> >i fear it could turn into the following dance which seems not a lot
> >better given i'm sure some people will argue there is no benefit to
> >removing inline assembly for gcc/clang. my preference is not to get
> >side-tracked on refactoring with the short merge window.
> >
> >#if (defined(__clang__) && clang version < x) ||
> >     (defined(__GNUC__) && gcc version < x)
> >__asm(whatever...
> >#else
> >__rdtsc()
> >#endif
> 
> 
> Played a bit with https://godbolt.org/.
> It seems that __rdtsc()  and RMT builtins (xbegin/xend/xtest) are
> supported all way down to gcc 4.8.1.

Do you know what version of clang comes with RHEL 7. Because for 23.07
release at least I need to know it won't break clang compile on RHEL 7
either (which is what makes this painful).

I played around with clang 7 (which i'm not sure is the right version)
it had __rdtsc() but it did not have xbegin/xend/xtest. For the various
instructions they're appearing in different versions of the compilers.

I'm starting to wonder if i should drop the intrinsics changes into a
separate series?

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Bruce Richardson]

On Mon, Apr 10, 2023 at 01:58:48PM -0700, Tyler Retzlaff wrote:
> On Mon, Apr 10, 2023 at 09:02:00PM +0100, Konstantin Ananyev wrote:
> > 06/04/2023 01:07, Tyler Retzlaff пишет:
> > >On Wed, Apr 05, 2023 at 10:57:02AM +0000, Konstantin Ananyev wrote:
> > >>
> > >>>>>>>Inline assembly is not supported for msvc x64 instead use
> > >>>>>>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> > >>>>>>>
> > >>>>>>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > >>>>>>>---
> > >>>>>>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > >>>>>>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > >>>>>>>  2 files changed, 13 insertions(+), 1 deletion(-)
> > >>>>>>>
> > >>>>>>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > >>>>>>>
> > >>>>>>>  /**
> > >>>>>>>   * Synchronization fence between threads based on the specified memory order.
> > >>>>>>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > >>>>>>>
> > >>>>>>>  #define	rte_rmb() _mm_lfence()
> > >>>>>>>
> > >>>>>>>+#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
> > >>>>>>>
> > >>>>>>>  /*
> > >>>>>>>   * 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 operation,
> > >>>>>>and is not enough to serve as a proper memory barrier for SMP.
> > >>>>>
> > >>>>>i think i'm confused by the macro naming here.  i'll take another look
> > >>>>>thank you for raising it.
> > >>>>>
> > >>>>>>
> > >>>>>>Another ore generic comment - do we really need to pollute all that code with 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?
> > >>>>>
> > >>>>>i asked this question previously and confirmed in the technical board
> > >>>>>meeting. the answer i received was that the community did not want new
> > >>>>>directory/headers introduced for compiler support matrix and i should
> > >>>>>use #ifdef in the existing headers.
> > >>>>
> > >>>>Ok, can I then ask at least to minimize number of ifdefs to absolute
> > >>>>minimum?
> > >>>
> > >>>in principal no objection at all, one question though is what to do with
> > >>>comment based documentation attached to macros? e.g.
> > >>>
> > >>>#ifdef SOME_FOO
> > >>>/* some documentation */
> > >>>#define some_macro
> > >>>#else
> > >>>#define some_macro
> > >>>#endif
> > >>>
> > >>>#ifdef SOME_FOO
> > >>>/* some documentation 2 */
> > >>>#define some_macro2
> > >>>#else
> > >>>#define some_macro2
> > >>>#endif
> > >>>
> > >>>i can either duplicate the documentation for every define so it stays
> > >>>"attached" or i can only document the first expansion. let me know what
> > >>>you expect.
> > >>>
> > >>>so something like this?
> > >>>
> > >>>#ifdef SOME_FOO
> > >>>/* some documentation */
> > >>>#define some_macro
> > >>>/* some documentation 2 */
> > >>>#define some_macro2
> > >>>#else
> > >>>#define some_macro
> > >>>#define some_macro2
> > >>>#endif
> > >>>
> > >>>or should all documentation be duplicated? which can become a teadious
> > >>>redundancy for anyone maintaining it. keep in mind we might have to make
> > >>>an exception for rte_common.h because it seems doing this would be
> > >>>really ugly there. take a look let me know.
> > >>
> > >>My personal preference would be to keep one documentation block for both cases
> > >>(yes, I suppose it needs to be updated if required):
> > >>
> > >>/* some documentation, probably for both SOME_FOO on/off */
> > >>#ifdef SOME_FOO
> > >>#define some_macro
> > >>#else
> > >>#define some_macro
> > >>#endif
> > >>
> > >>
> > >>>
> > >>>>It is really hard to read an follow acode that is heavily ifdefed.
> > >>>>Let say above we probably don't need to re-define
> > >>>>rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> > >>>>compiler_barrier(), which is already redefined.
> > >>>
> > >>>can you take a look at v2 of the patch and re-prescribe your advise
> > >>>here? in v2 only the intel macros expand to the compiler barrier. though
> > >>>i find this vexing since as you pointed out it seems they aren't
> > >>>supposed to be compiler only barriers according to the documentation in
> > >>>generic/rte_atomic.h they are intended to be memory barriers.
> > >>
> > >>Commented, pls check if I explained my thoughts clear enough there.
> > >>>
> > >>>please help me if i've goofed up in this regard.
> > >>>
> > >>>>Another question - could it be visa-versa approach:
> > >>>>can we replace some inline assembly with common instincts whenever possible?
> > >>>
> > >>>msvc has only intrinsics and the conditional expansion for msvc is to
> > >>>use those intrinsics, gcc doesn't generally define intrinsics for processor
> > >>>specific code does it?
> > >>
> > >>AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
> > >>So my thought was - might be we can use same instincts for all compilers...
> > >>One implication I can think about - older versions of gcc.
> > >>But might be we can re-order things and have inlines only for these oldere gcc versions?
> > >
> > >i'm going to propose if we do this we do it as a separate change later.
> > >
> > >i fear it could turn into the following dance which seems not a lot
> > >better given i'm sure some people will argue there is no benefit to
> > >removing inline assembly for gcc/clang. my preference is not to get
> > >side-tracked on refactoring with the short merge window.
> > >
> > >#if (defined(__clang__) && clang version < x) ||
> > >     (defined(__GNUC__) && gcc version < x)
> > >__asm(whatever...
> > >#else
> > >__rdtsc()
> > >#endif
> > 
> > 
> > Played a bit with https://godbolt.org/.
> > It seems that __rdtsc()  and RMT builtins (xbegin/xend/xtest) are
> > supported all way down to gcc 4.8.1.
> 
> Do you know what version of clang comes with RHEL 7. Because for 23.07
> release at least I need to know it won't break clang compile on RHEL 7
> either (which is what makes this painful).
> 

I don't know if we ever stated that we need to support clang from RHEL 7. I
always assumed that it was just gcc 4.8 compiler, but I suppose we never
stated either that we didn't need to support it....

> I played around with clang 7 (which i'm not sure is the right version)
> it had __rdtsc() but it did not have xbegin/xend/xtest. For the various
> instructions they're appearing in different versions of the compilers.
> 

Running Centos 7 in a VM, I see Clang v3.4.2.

> I'm starting to wonder if i should drop the intrinsics changes into a
> separate series?
> 

Re: [PATCH 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Tue, Apr 11, 2023 at 10:10:48AM +0100, Bruce Richardson wrote:
> On Mon, Apr 10, 2023 at 01:58:48PM -0700, Tyler Retzlaff wrote:
> > On Mon, Apr 10, 2023 at 09:02:00PM +0100, Konstantin Ananyev wrote:
> > > 06/04/2023 01:07, Tyler Retzlaff пишет:
> > > >On Wed, Apr 05, 2023 at 10:57:02AM +0000, Konstantin Ananyev wrote:
> > > >>
> > > >>>>>>>Inline assembly is not supported for msvc x64 instead use
> > > >>>>>>>_{Read,Write,ReadWrite}Barrier() intrinsics.
> > > >>>>>>>
> > > >>>>>>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > >>>>>>>---
> > > >>>>>>>  lib/eal/include/generic/rte_atomic.h |  4 ++++
> > > >>>>>>>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> > > >>>>>>>  2 files changed, 13 insertions(+), 1 deletion(-)
> > > >>>>>>>
> > > >>>>>>>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > > >>>>>>>
> > > >>>>>>>  /**
> > > >>>>>>>   * Synchronization fence between threads based on the specified memory order.
> > > >>>>>>>diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > > >>>>>>>
> > > >>>>>>>  #define	rte_rmb() _mm_lfence()
> > > >>>>>>>
> > > >>>>>>>+#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
> > > >>>>>>>
> > > >>>>>>>  /*
> > > >>>>>>>   * 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 operation,
> > > >>>>>>and is not enough to serve as a proper memory barrier for SMP.
> > > >>>>>
> > > >>>>>i think i'm confused by the macro naming here.  i'll take another look
> > > >>>>>thank you for raising it.
> > > >>>>>
> > > >>>>>>
> > > >>>>>>Another ore generic comment - do we really need to pollute all that code with 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?
> > > >>>>>
> > > >>>>>i asked this question previously and confirmed in the technical board
> > > >>>>>meeting. the answer i received was that the community did not want new
> > > >>>>>directory/headers introduced for compiler support matrix and i should
> > > >>>>>use #ifdef in the existing headers.
> > > >>>>
> > > >>>>Ok, can I then ask at least to minimize number of ifdefs to absolute
> > > >>>>minimum?
> > > >>>
> > > >>>in principal no objection at all, one question though is what to do with
> > > >>>comment based documentation attached to macros? e.g.
> > > >>>
> > > >>>#ifdef SOME_FOO
> > > >>>/* some documentation */
> > > >>>#define some_macro
> > > >>>#else
> > > >>>#define some_macro
> > > >>>#endif
> > > >>>
> > > >>>#ifdef SOME_FOO
> > > >>>/* some documentation 2 */
> > > >>>#define some_macro2
> > > >>>#else
> > > >>>#define some_macro2
> > > >>>#endif
> > > >>>
> > > >>>i can either duplicate the documentation for every define so it stays
> > > >>>"attached" or i can only document the first expansion. let me know what
> > > >>>you expect.
> > > >>>
> > > >>>so something like this?
> > > >>>
> > > >>>#ifdef SOME_FOO
> > > >>>/* some documentation */
> > > >>>#define some_macro
> > > >>>/* some documentation 2 */
> > > >>>#define some_macro2
> > > >>>#else
> > > >>>#define some_macro
> > > >>>#define some_macro2
> > > >>>#endif
> > > >>>
> > > >>>or should all documentation be duplicated? which can become a teadious
> > > >>>redundancy for anyone maintaining it. keep in mind we might have to make
> > > >>>an exception for rte_common.h because it seems doing this would be
> > > >>>really ugly there. take a look let me know.
> > > >>
> > > >>My personal preference would be to keep one documentation block for both cases
> > > >>(yes, I suppose it needs to be updated if required):
> > > >>
> > > >>/* some documentation, probably for both SOME_FOO on/off */
> > > >>#ifdef SOME_FOO
> > > >>#define some_macro
> > > >>#else
> > > >>#define some_macro
> > > >>#endif
> > > >>
> > > >>
> > > >>>
> > > >>>>It is really hard to read an follow acode that is heavily ifdefed.
> > > >>>>Let say above we probably don't need to re-define
> > > >>>>rte_smp_rmb/rte_smp_wmb, as both are boiled down to
> > > >>>>compiler_barrier(), which is already redefined.
> > > >>>
> > > >>>can you take a look at v2 of the patch and re-prescribe your advise
> > > >>>here? in v2 only the intel macros expand to the compiler barrier. though
> > > >>>i find this vexing since as you pointed out it seems they aren't
> > > >>>supposed to be compiler only barriers according to the documentation in
> > > >>>generic/rte_atomic.h they are intended to be memory barriers.
> > > >>
> > > >>Commented, pls check if I explained my thoughts clear enough there.
> > > >>>
> > > >>>please help me if i've goofed up in this regard.
> > > >>>
> > > >>>>Another question - could it be visa-versa approach:
> > > >>>>can we replace some inline assembly with common instincts whenever possible?
> > > >>>
> > > >>>msvc has only intrinsics and the conditional expansion for msvc is to
> > > >>>use those intrinsics, gcc doesn't generally define intrinsics for processor
> > > >>>specific code does it?
> > > >>
> > > >>AFAIK latest gcc (and clang) versions do support majority of these instincts: __rdtsc, _xbegin/_xend, etc.
> > > >>So my thought was - might be we can use same instincts for all compilers...
> > > >>One implication I can think about - older versions of gcc.
> > > >>But might be we can re-order things and have inlines only for these oldere gcc versions?
> > > >
> > > >i'm going to propose if we do this we do it as a separate change later.
> > > >
> > > >i fear it could turn into the following dance which seems not a lot
> > > >better given i'm sure some people will argue there is no benefit to
> > > >removing inline assembly for gcc/clang. my preference is not to get
> > > >side-tracked on refactoring with the short merge window.
> > > >
> > > >#if (defined(__clang__) && clang version < x) ||
> > > >     (defined(__GNUC__) && gcc version < x)
> > > >__asm(whatever...
> > > >#else
> > > >__rdtsc()
> > > >#endif
> > > 
> > > 
> > > Played a bit with https://godbolt.org/.
> > > It seems that __rdtsc()  and RMT builtins (xbegin/xend/xtest) are
> > > supported all way down to gcc 4.8.1.
> > 
> > Do you know what version of clang comes with RHEL 7. Because for 23.07
> > release at least I need to know it won't break clang compile on RHEL 7
> > either (which is what makes this painful).
> > 
> 
> I don't know if we ever stated that we need to support clang from RHEL 7. I
> always assumed that it was just gcc 4.8 compiler, but I suppose we never
> stated either that we didn't need to support it....
> 
> > I played around with clang 7 (which i'm not sure is the right version)
> > it had __rdtsc() but it did not have xbegin/xend/xtest. For the various
> > instructions they're appearing in different versions of the compilers.
> > 
> 
> Running Centos 7 in a VM, I see Clang v3.4.2.

Konstantin, Bruce

okay, i'm trying this. i sent a new series version where i use the gcc
intrinsics if they are available in gcc 4.9. for intrinsics that were
not available in 4.9 they have been left as conditional compile for now.

if the CI blows up i will revert back to conditional compile.

this series isn't supposed to be about cleaning up existing code so i'm
trying to be helpful here but please check out the latest and ack if
you're happy. if we want refactor / cleanups beyond this i'll commit to
making the changes in subsequent series that aren't *blocking* this
work.

thanks

[PATCH 4/9] eal: typedef cpu flag enum as int for msvc

[Tyler Retzlaff]

Forward declaration of a typedef is a non-standard extension and is not
supported by msvc. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

[PATCH 5/9] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with msvc don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH 6/9] eal: expand most macros to empty when using msvc

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 ++++++++
 lib/eal/include/rte_common.h            | 33 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++++
 3 files changed, 61 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..3589c97 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(!!(x) == 1)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(!!(x) == 0)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..a724e22 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -88,8 +92,13 @@
 #define __rte_may_alias __attribute__((__may_alias__))
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -117,7 +126,11 @@
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +154,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +162,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +239,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +268,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +466,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH 7/9] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 5cce9ba..20f3380 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -87,6 +87,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -283,6 +285,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH 8/9] telemetry: disable json print formatting with msvc

[Tyler Retzlaff]

VLAs are unsafe and will never be implemented in MSVC. When compiling
with MSVC just return immediately indicating 0 output characters
formatted.

For now telemetry doesn't work on Windows, we will revisit support for
the telemetry library sometime after we establish the DPDK unit tests.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_json.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index 744bbfe..d847003 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -30,6 +30,7 @@
 static inline int
 __json_snprintf(char *buf, const int len, const char *format, ...)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	va_list ap;
 	int ret;
@@ -41,6 +42,7 @@
 		strcpy(buf, tmp);
 		return ret;
 	}
+#endif
 	return 0; /* nothing written or modified */
 }
 
@@ -60,6 +62,7 @@
 static inline int
 __json_format_str(char *buf, const int len, const char *prefix, const char *str, const char *suffix)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	int tmpidx = 0;
 
@@ -98,6 +101,9 @@
 
 	strcpy(buf, tmp);
 	return tmpidx;
+#else
+	return 0;
+#endif
 }
 
 /* Copies an empty array into the provided buffer. */
-- 
1.8.3.1

[PATCH 9/9] telemetry: avoid expanding versioned symbol macros on msvc

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v2 0/9] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64.

Tyler Retzlaff (9):
  eal: use rdtsc intrinsic when compiling with msvc
  eal: use rtm and xtest intrinsics when compiling with msvc
  eal: use barrier intrinsics when compiling with msvc
  eal: typedef cpu flag enum as int for msvc
  eal: hide GCC extension based alignment markers
  eal: expand most macros to empty when using msvc
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: disable json print formatting with msvc
  telemetry: avoid expanding versioned symbol macros on msvc

 lib/eal/include/generic/rte_atomic.h    | 11 ++++++++++
 lib/eal/include/generic/rte_cpuflags.h  | 12 ++++++-----
 lib/eal/include/rte_branch_prediction.h |  8 +++++++
 lib/eal/include/rte_common.h            | 37 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++
 lib/eal/x86/include/rte_atomic.h        | 14 ++++++++++++-
 lib/eal/x86/include/rte_cycles.h        |  8 +++++++
 lib/eal/x86/include/rte_rtm.h           | 19 +++++++++++++++++
 lib/telemetry/telemetry_data.c          | 16 ++++++++++++++
 lib/telemetry/telemetry_json.h          |  6 ++++++
 10 files changed, 145 insertions(+), 6 deletions(-)

-- 
1.8.3.1

[PATCH v2 1/9] eal: use rdtsc intrinsic when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use __rdtsc
intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_cycles.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..0c142ce 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,10 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +27,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -47,6 +52,9 @@
 		     "=a" (tsc.lo_32),
 		     "=d" (tsc.hi_32));
 	return tsc.tsc_64;
+#else
+	return __rdtsc();
+#endif
 }
 
 static inline uint64_t
-- 
1.8.3.1

Re: [PATCH v2 1/9] eal: use rdtsc intrinsic when compiling with msvc

[Bruce Richardson]

On Tue, Apr 04, 2023 at 01:07:19PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for msvc x64 instead use __rdtsc
> intrinsic.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/x86/include/rte_cycles.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
> index a461a4d..0c142ce 100644
> --- a/lib/eal/x86/include/rte_cycles.h
> +++ b/lib/eal/x86/include/rte_cycles.h
> @@ -6,6 +6,10 @@
>  #ifndef _RTE_CYCLES_X86_64_H_
>  #define _RTE_CYCLES_X86_64_H_
>  
> +#ifdef RTE_TOOLCHAIN_MSVC
> +#include <intrin.h>
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> @@ -23,6 +27,7 @@
>  static inline uint64_t
>  rte_rdtsc(void)
>  {
> +#ifndef RTE_TOOLCHAIN_MSVC
>  	union {
>  		uint64_t tsc_64;
>  		RTE_STD_C11
> @@ -47,6 +52,9 @@
>  		     "=a" (tsc.lo_32),
>  		     "=d" (tsc.hi_32));
>  	return tsc.tsc_64;
> +#else
> +	return __rdtsc();
> +#endif
>  }

Checking with google it seems that gcc/clang have an __rdtsc intrinsic as
well, so we may be able to avoid ifdefs here completely.

/Bruce

[PATCH v2 2/9] eal: use rtm and xtest intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use _xbegin,
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_rtm.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..26672cb 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,9 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <immintrin.h>
+#endif
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +31,47 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned int ret = RTE_XBEGIN_STARTED;
 
 	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
 	return ret;
+#else
+	return _xbegin();
+#endif
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+#else
+	_xend();
+#endif
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define rte_xabort(status) do { \
 	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
 } while (0)
+#else
+#define rte_xabort(status) _xabort(status)
+#endif
 
 static __rte_always_inline
 int rte_xtest(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned char out;
 
 	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
 		"=r" (out) :: "memory");
 	return out;
+#else
+	return _xtest();
+#endif
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use
_mm_{s,l,m}fence() intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h |  4 ++++
 lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
 
 #define	rte_rmb() _mm_lfence()
 
+#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()
+#endif
 
 /*
  * 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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

Re: [PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc

[Bruce Richardson]

On Tue, Apr 04, 2023 at 01:07:21PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for msvc x64 instead use
> _mm_{s,l,m}fence() intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/generic/rte_atomic.h |  4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
>  
>  /**
>   * Synchronization fence between threads based on the specified memory order.
> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
>  
>  #define	rte_rmb() _mm_lfence()
>  
> +#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()
> +#endif
>  

I think this change can be dropped from the diff. "rte_compiler_barrier()"
is valid in MSVC because you defined it above.

>  /*
>   * 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
>  }
>  
>  #define rte_io_mb() rte_mb()
> -- 
> 1.8.3.1
> 

RE: [PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc

[Konstantin Ananyev]

> Inline assembly is not supported for msvc x64 instead use
> _mm_{s,l,m}fence() intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/generic/rte_atomic.h |  4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> 
>  /**
>   * Synchronization fence between threads based on the specified memory order.
> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> 
>  #define	rte_rmb() _mm_lfence()
> 
> +#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 older writes
(there are few exceptions for writes: NT stores, fast string ops, but I think it can be skipped here).
For more info pls refer to: IA Software Developer's Manual, 3.8.3 8.2 MEMORY ORDERING.
That's why DPDK uses compiler_barrier() as expansion of smp_wmb() and smp_rmb() for x86 platforms.
There is nothing wrong in using sfence and lfence here, except that it is probably an overkill. 

> +#endif
> 
>  /*
>   * 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
>  }
> 
>  #define rte_io_mb() rte_mb()
> --
> 1.8.3.1

Re: [PATCH v2 3/9] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 10:45:26AM +0000, Konstantin Ananyev wrote:
> 
> 
> > Inline assembly is not supported for msvc x64 instead use
> > _mm_{s,l,m}fence() intrinsics.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/generic/rte_atomic.h |  4 ++++
> >  lib/eal/x86/include/rte_atomic.h     | 10 +++++++++-
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> > 
> >  /**
> >   * Synchronization fence between threads based on the specified memory order.
> > diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.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 @@
> > 
> >  #define	rte_rmb() _mm_lfence()
> > 
> > +#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 older writes
> (there are few exceptions for writes: NT stores, fast string ops, but I think it can be skipped here).
> For more info pls refer to: IA Software Developer's Manual, 3.8.3 8.2 MEMORY ORDERING.
> That's why DPDK uses compiler_barrier() as expansion of smp_wmb() and smp_rmb() for x86 platforms.
> There is nothing wrong in using sfence and lfence here, except that it is probably an overkill. 

thank you and Bruce for the explanation. how it was documented confused
me. now i understand and i will drop this change.

thanks!

> 
> > +#endif
> > 
> >  /*
> >   * 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
> >  }
> > 
> >  #define rte_io_mb() rte_mb()
> > --
> > 1.8.3.1

[PATCH v2 4/9] eal: typedef cpu flag enum as int for msvc

[Tyler Retzlaff]

Forward declaration of a typedef is a non-standard extension and is not
supported by msvc. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

[PATCH v2 5/9] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with msvc don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v2 6/9] eal: expand most macros to empty when using msvc

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 ++++++++
 lib/eal/include/rte_common.h            | 33 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++++
 3 files changed, 61 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..3589c97 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(!!(x) == 1)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(!!(x) == 0)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..a724e22 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -88,8 +92,13 @@
 #define __rte_may_alias __attribute__((__may_alias__))
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -117,7 +126,11 @@
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +154,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +162,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +239,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +268,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +466,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

Re: [PATCH v2 6/9] eal: expand most macros to empty when using msvc

[Bruce Richardson]

On Tue, Apr 04, 2023 at 01:07:24PM -0700, Tyler Retzlaff wrote:
> For now expand a lot of common rte macros empty. The catch here is we
> need to test that most of the macros do what they should but at the same
> time they are blocking work needed to bootstrap of the unit tests.
> 
> Later we will return and provide (where possible) expansions that work
> correctly for msvc and where not possible provide some alternate macros
> to achieve the same outcome.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/rte_branch_prediction.h |  8 ++++++++
>  lib/eal/include/rte_common.h            | 33 +++++++++++++++++++++++++++++++++
>  lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++++
>  3 files changed, 61 insertions(+)
> 
> diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
> index 0256a9d..3589c97 100644
> --- a/lib/eal/include/rte_branch_prediction.h
> +++ b/lib/eal/include/rte_branch_prediction.h
> @@ -25,7 +25,11 @@
>   *
>   */
>  #ifndef likely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define likely(x)	__builtin_expect(!!(x), 1)
> +#else
> +#define likely(x)	(!!(x) == 1)
> +#endif

I think this should just be "#define likely(x) (x)", since the likely is
just a hint as to which way we expect the branch to go. It does not change
the logic in the expression.

>  #endif /* likely */
>  
>  /**
> @@ -39,7 +43,11 @@
>   *
>   */
>  #ifndef unlikely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define unlikely(x)	__builtin_expect(!!(x), 0)
> +#else
> +#define unlikely(x)	(!!(x) == 0)
> +#endif

This expansion is wrong, because it changes the logic of the expression,
rather than being a hint. As above with likely, I think this should just
expand as "(x)", making the unlikely ignored.

>  #endif /* unlikely */
>  
>  #ifdef __cplusplus
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 2f464e3..a724e22 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h

This file has a lot of ifdefs in it now for msvc. Couple of suggestions:

1. can we group these defines together so we can hit multiple entries with a
  single msvc block?

2. alternatively, for those we want to just permanently null, we could
   split the responsibility for them between the currnet headers and possibly
   the build system. Specifically, rather than doing macros based on MSVC,
   change each macro to the simpler:

   #ifndef MACRO
   #define MACRO  macro_definition
   #endif

    Then in the meson.build processing, we can have some separte MSVC
    processing to put null defines for these into rte_build_config.h, or put
    in null defines for them in some MSVC-specific header.

Just some thoughts.
/Bruce

Re: [PATCH v2 6/9] eal: expand most macros to empty when using msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 11:44:43AM +0100, Bruce Richardson wrote:
> On Tue, Apr 04, 2023 at 01:07:24PM -0700, Tyler Retzlaff wrote:
> > For now expand a lot of common rte macros empty. The catch here is we
> > need to test that most of the macros do what they should but at the same
> > time they are blocking work needed to bootstrap of the unit tests.
> > 
> > Later we will return and provide (where possible) expansions that work
> > correctly for msvc and where not possible provide some alternate macros
> > to achieve the same outcome.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/rte_branch_prediction.h |  8 ++++++++
> >  lib/eal/include/rte_common.h            | 33 +++++++++++++++++++++++++++++++++
> >  lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++++
> >  3 files changed, 61 insertions(+)
> > 
> > diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
> > index 0256a9d..3589c97 100644
> > --- a/lib/eal/include/rte_branch_prediction.h
> > +++ b/lib/eal/include/rte_branch_prediction.h
> > @@ -25,7 +25,11 @@
> >   *
> >   */
> >  #ifndef likely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define likely(x)	__builtin_expect(!!(x), 1)
> > +#else
> > +#define likely(x)	(!!(x) == 1)
> > +#endif
> 
> I think this should just be "#define likely(x) (x)", since the likely is
> just a hint as to which way we expect the branch to go. It does not change
> the logic in the expression.
> 
> >  #endif /* likely */
> >  
> >  /**
> > @@ -39,7 +43,11 @@
> >   *
> >   */
> >  #ifndef unlikely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define unlikely(x)	__builtin_expect(!!(x), 0)
> > +#else
> > +#define unlikely(x)	(!!(x) == 0)
> > +#endif
> 
> This expansion is wrong, because it changes the logic of the expression,
> rather than being a hint. As above with likely, I think this should just
> expand as "(x)", making the unlikely ignored.

ooh, obviously wrong will fix.

> 
> >  #endif /* unlikely */
> >  
> >  #ifdef __cplusplus
> > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > index 2f464e3..a724e22 100644
> > --- a/lib/eal/include/rte_common.h
> > +++ b/lib/eal/include/rte_common.h
> 
> This file has a lot of ifdefs in it now for msvc. Couple of suggestions:
> 
> 1. can we group these defines together so we can hit multiple entries with a
>   single msvc block?
> 
> 2. alternatively, for those we want to just permanently null, we could
>    split the responsibility for them between the currnet headers and possibly
>    the build system. Specifically, rather than doing macros based on MSVC,
>    change each macro to the simpler:
> 
>    #ifndef MACRO
>    #define MACRO  macro_definition
>    #endif


> 
>     Then in the meson.build processing, we can have some separte MSVC
>     processing to put null defines for these into rte_build_config.h, or put
>     in null defines for them in some MSVC-specific header.

yes, i'll do this for now. i won't go the route of rte_build_config.h
for now since some of the macros i will eventually try to find a way to
provide equivalent expansion.

> 
> Just some thoughts.
> /Bruce

[PATCH v2 7/9] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 7ae3a41..211a734 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -87,6 +87,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -283,6 +285,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v2 8/9] telemetry: disable json print formatting with msvc

[Tyler Retzlaff]

VLAs are unsafe and will never be implemented in MSVC. When compiling
with MSVC just return immediately indicating 0 output characters
formatted.

For now telemetry doesn't work on Windows, we will revisit support for
the telemetry library sometime after we establish the DPDK unit tests.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_json.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index 744bbfe..d847003 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -30,6 +30,7 @@
 static inline int
 __json_snprintf(char *buf, const int len, const char *format, ...)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	va_list ap;
 	int ret;
@@ -41,6 +42,7 @@
 		strcpy(buf, tmp);
 		return ret;
 	}
+#endif
 	return 0; /* nothing written or modified */
 }
 
@@ -60,6 +62,7 @@
 static inline int
 __json_format_str(char *buf, const int len, const char *prefix, const char *str, const char *suffix)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	int tmpidx = 0;
 
@@ -98,6 +101,9 @@
 
 	strcpy(buf, tmp);
 	return tmpidx;
+#else
+	return 0;
+#endif
 }
 
 /* Copies an empty array into the provided buffer. */
-- 
1.8.3.1

[PATCH v2 9/9] telemetry: avoid expanding versioned symbol macros on msvc

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

Re: [PATCH v2 9/9] telemetry: avoid expanding versioned symbol macros on msvc

[Bruce Richardson]

On Tue, Apr 04, 2023 at 01:07:27PM -0700, Tyler Retzlaff wrote:
> Windows does not support versioned symbols. Fortunately Windows also
> doesn't have an exported stable ABI.
> 
> Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> functions.
> 
> Windows does have a way to achieve similar versioning for symbols but it
> is not a simple #define so it will be done as a work package later.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Does this require a change in telemetry itself? Can it be done via the
header file with the versioning macros in it, so it would apply to any
other versioned functions we have in DPDK?

/Bruce

> ---
>  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 2bac2de..284c16e 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -82,8 +82,16 @@
>  /* mark the v23 function as the older version, and v24 as the default version */
>  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
>  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> +#ifndef RTE_TOOLCHAIN_MSVC
>  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
>  		int64_t x), rte_tel_data_add_array_int_v24);
> +#else
> +int
> +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> +{
> +	return rte_tel_data_add_array_int_v24(d, x);
> +}
> +#endif
>  
>  int
>  rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
> @@ -220,8 +228,16 @@
>  /* mark the v23 function as the older version, and v24 as the default version */
>  VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
>  BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
> +#ifndef RTE_TOOLCHAIN_MSVC
>  MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
>  		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
> +#else
> +int
> +rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
> +{
> +	return rte_tel_data_add_dict_int_v24(d, name, val);
> +}
> +#endif
>  
>  int
>  rte_tel_data_add_dict_uint(struct rte_tel_data *d,
> -- 
> 1.8.3.1
> 

Re: [PATCH v2 9/9] telemetry: avoid expanding versioned symbol macros on msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 11:56:05AM +0100, Bruce Richardson wrote:
> On Tue, Apr 04, 2023 at 01:07:27PM -0700, Tyler Retzlaff wrote:
> > Windows does not support versioned symbols. Fortunately Windows also
> > doesn't have an exported stable ABI.
> > 
> > Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> > and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> > functions.
> > 
> > Windows does have a way to achieve similar versioning for symbols but it
> > is not a simple #define so it will be done as a work package later.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> 
> Does this require a change in telemetry itself? Can it be done via the
> header file with the versioning macros in it, so it would apply to any
> other versioned functions we have in DPDK?

i didn't spend a lot of time thinking if the existing macros could be
made to expand in the way needed. there is a way of doing versioning on
windows but it is foreign to how this symbol versioning scheme works so
i plan to investigate it separately after i get unit tests running.

for now i know what i'm doing is ugly but i need to get protection of
unit tests so i'm doing minimal changes to get to that point. if you're
not comfortable with this going in on a temporary basis i can remove it
from this series and we can work on it as a separated patch set.

my bar is pretty low here, as long as it doesn't break any existing
linux/gcc/clang etc ok, if msvc is not right i'll take a second pass
and design each stop-gap properly. it already doesn't work so things
aren't made worse.

let me know if i need to carve this out of the series.

ty

> 
> /Bruce
> 
> > ---
> >  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> > index 2bac2de..284c16e 100644
> > --- a/lib/telemetry/telemetry_data.c
> > +++ b/lib/telemetry/telemetry_data.c
> > @@ -82,8 +82,16 @@
> >  /* mark the v23 function as the older version, and v24 as the default version */
> >  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
> >  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
> >  		int64_t x), rte_tel_data_add_array_int_v24);
> > +#else
> > +int
> > +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> > +{
> > +	return rte_tel_data_add_array_int_v24(d, x);
> > +}
> > +#endif
> >  
> >  int
> >  rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
> > @@ -220,8 +228,16 @@
> >  /* mark the v23 function as the older version, and v24 as the default version */
> >  VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
> >  BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
> >  		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
> > +#else
> > +int
> > +rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
> > +{
> > +	return rte_tel_data_add_dict_int_v24(d, name, val);
> > +}
> > +#endif
> >  
> >  int
> >  rte_tel_data_add_dict_uint(struct rte_tel_data *d,
> > -- 
> > 1.8.3.1
> > 

Re: [PATCH v2 9/9] telemetry: avoid expanding versioned symbol macros on msvc

[Bruce Richardson]

On Wed, Apr 05, 2023 at 09:02:10AM -0700, Tyler Retzlaff wrote:
> On Wed, Apr 05, 2023 at 11:56:05AM +0100, Bruce Richardson wrote:
> > On Tue, Apr 04, 2023 at 01:07:27PM -0700, Tyler Retzlaff wrote:
> > > Windows does not support versioned symbols. Fortunately Windows also
> > > doesn't have an exported stable ABI.
> > > 
> > > Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> > > and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> > > functions.
> > > 
> > > Windows does have a way to achieve similar versioning for symbols but it
> > > is not a simple #define so it will be done as a work package later.
> > > 
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > 
> > Does this require a change in telemetry itself? Can it be done via the
> > header file with the versioning macros in it, so it would apply to any
> > other versioned functions we have in DPDK?
> 
> i didn't spend a lot of time thinking if the existing macros could be
> made to expand in the way needed. there is a way of doing versioning on
> windows but it is foreign to how this symbol versioning scheme works so
> i plan to investigate it separately after i get unit tests running.
> 
> for now i know what i'm doing is ugly but i need to get protection of
> unit tests so i'm doing minimal changes to get to that point. if you're
> not comfortable with this going in on a temporary basis i can remove it
> from this series and we can work on it as a separated patch set.
> 
> my bar is pretty low here, as long as it doesn't break any existing
> linux/gcc/clang etc ok, if msvc is not right i'll take a second pass
> and design each stop-gap properly. it already doesn't work so things
> aren't made worse.
> 
> let me know if i need to carve this out of the series.
> 
It's not that ugly. :-) If no other clear solution is apparent, I can certainly
live with this.

/Bruce

[PATCH v3 00/11] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.


v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc
v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64.

Tyler Retzlaff (11):
  eal: use rdtsc intrinsic when compiling with msvc
  eal: use rtm and xtest intrinsics when compiling with msvc
  eal: use barrier intrinsics when compiling with msvc
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: typedef cpu flag enum as int for msvc
  eal: hide GCC extension based alignment markers
  eal: expand most macros to empty when using msvc
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: disable json print formatting with msvc
  telemetry: avoid expanding versioned symbol macros on msvc

 lib/eal/include/generic/rte_atomic.h    | 11 ++++++++++
 lib/eal/include/generic/rte_cpuflags.h  | 12 ++++++-----
 lib/eal/include/rte_branch_prediction.h |  8 +++++++
 lib/eal/include/rte_common.h            | 37 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++
 lib/eal/x86/include/rte_atomic.h        |  9 +++++++-
 lib/eal/x86/include/rte_cycles.h        |  8 +++++++
 lib/eal/x86/include/rte_rtm.h           | 19 +++++++++++++++++
 lib/eal/x86/rte_cpuflags.c              |  4 ++++
 lib/eal/x86/rte_cpuid.h                 |  7 +++++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 ++++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++++++
 lib/telemetry/telemetry_data.c          | 16 ++++++++++++++
 lib/telemetry/telemetry_json.h          |  6 ++++++
 15 files changed, 203 insertions(+), 6 deletions(-)

-- 
1.8.3.1

[PATCH v3 01/11] eal: use rdtsc intrinsic when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use __rdtsc
intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_cycles.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..0c142ce 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,10 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +27,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -47,6 +52,9 @@
 		     "=a" (tsc.lo_32),
 		     "=d" (tsc.hi_32));
 	return tsc.tsc_64;
+#else
+	return __rdtsc();
+#endif
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v3 02/11] eal: use rtm and xtest intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use _xbegin,
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_rtm.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..26672cb 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,9 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <immintrin.h>
+#endif
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +31,47 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned int ret = RTE_XBEGIN_STARTED;
 
 	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
 	return ret;
+#else
+	return _xbegin();
+#endif
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+#else
+	_xend();
+#endif
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define rte_xabort(status) do { \
 	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
 } while (0)
+#else
+#define rte_xabort(status) _xabort(status)
+#endif
 
 static __rte_always_inline
 int rte_xtest(void)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	unsigned char out;
 
 	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
 		"=r" (out) :: "memory");
 	return out;
+#else
+	return _xtest();
+#endif
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v3 03/11] eal: use barrier intrinsics when compiling with msvc

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..ca733c5 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -28,7 +28,6 @@
 #define	rte_rmb() _mm_lfence()
 
 #define rte_smp_wmb() rte_compiler_barrier()
-
 #define rte_smp_rmb() rte_compiler_barrier()
 
 /*
@@ -66,11 +65,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v3 04/11] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v3 05/11] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for msvc x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#else
+	_umonitor(pmc->addr);
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#else
+	_umwait(tsc_l, tsc_h);
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#else
+	_tpause(tsc_l, tsc_h);
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Tyler Retzlaff]

Forward declaration of a typedef is a non-standard extension and is not
supported by msvc. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Konstantin Ananyev]

06/04/2023 01:45, Tyler Retzlaff пишет:
> Forward declaration of a typedef is a non-standard extension and is not
> supported by msvc. Use an int instead.
> 
> Abstract the use of the int/enum rte_cpu_flag_t in function parameter
> lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
> identifier.
> 
> Remove the use of __extension__ on function prototypes where
> rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
> conditionally compiled __extension__ at the non-standard forward
> declaration site.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>   lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
> index d35551e..87ab03c 100644
> --- a/lib/eal/include/generic/rte_cpuflags.h
> +++ b/lib/eal/include/generic/rte_cpuflags.h
> @@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
>   /**
>    * Enumeration of all CPU features supported
>    */
> +#ifndef RTE_TOOLCHAIN_MSVC
>   __extension__
> -enum rte_cpu_flag_t;
> +typedef enum rte_cpu_flag_t rte_cpu_flag_t;
> +#else
> +typedef int rte_cpu_flag_t;
> +#endif


Just curious what exactly MSVC doesn't support here?
Is that construction like:
enum rte_cpu_flag_t {....};
enum rte_cpu_flag_t;
...
Or something else?


>   /**
>    * Get name of CPU flag
> @@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
>    *     flag name
>    *     NULL if flag ID is invalid
>    */
> -__extension__
>   const char *
> -rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
> +rte_cpu_get_flag_name(rte_cpu_flag_t feature);
>   
>   /**
>    * Function for checking a CPU flag availability
> @@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
>    *     0 if flag is not available
>    *     -ENOENT if flag is invalid
>    */
> -__extension__
>   int
> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
> +rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
>   
>   /**
>    * This function checks that the currently used CPU supports the CPU features

Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Tyler Retzlaff]

On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote:
> 06/04/2023 01:45, Tyler Retzlaff пишет:
> >Forward declaration of a typedef is a non-standard extension and is not
> >supported by msvc. Use an int instead.
> >
> >Abstract the use of the int/enum rte_cpu_flag_t in function parameter
> >lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
> >identifier.
> >
> >Remove the use of __extension__ on function prototypes where
> >rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
> >conditionally compiled __extension__ at the non-standard forward
> >declaration site.
> >
> >Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >---
> >  lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> >diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
> >index d35551e..87ab03c 100644
> >--- a/lib/eal/include/generic/rte_cpuflags.h
> >+++ b/lib/eal/include/generic/rte_cpuflags.h
> >@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
> >  /**
> >   * Enumeration of all CPU features supported
> >   */
> >+#ifndef RTE_TOOLCHAIN_MSVC
> >  __extension__
> >-enum rte_cpu_flag_t;
> >+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
> >+#else
> >+typedef int rte_cpu_flag_t;
> >+#endif
> 
> 
> Just curious what exactly MSVC doesn't support here?
> Is that construction like:
> enum rte_cpu_flag_t {....};
> enum rte_cpu_flag_t;
> ...
> Or something else?

Forward declaration of an enum is non standard. It's probably only
allowed by gcc as an extension because gcc will make some kind of
implementation specific promise for it always to be `int` size by
default (assuming no other -foptions).

If the enum was defined before reference it would probably be accepted
by msvc since it could 'see' the definition and know the integer width
in use.

> 
> 
> >  /**
> >   * Get name of CPU flag
> >@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
> >   *     flag name
> >   *     NULL if flag ID is invalid
> >   */
> >-__extension__
> >  const char *
> >-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
> >+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
> >  /**
> >   * Function for checking a CPU flag availability
> >@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
> >   *     0 if flag is not available
> >   *     -ENOENT if flag is invalid
> >   */
> >-__extension__
> >  int
> >-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
> >+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
> >  /**
> >   * This function checks that the currently used CPU supports the CPU features

Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Konstantin Ananyev]

10/04/2023 21:53, Tyler Retzlaff пишет:
> On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote:
>> 06/04/2023 01:45, Tyler Retzlaff пишет:
>>> Forward declaration of a typedef is a non-standard extension and is not
>>> supported by msvc. Use an int instead.
>>>
>>> Abstract the use of the int/enum rte_cpu_flag_t in function parameter
>>> lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
>>> identifier.
>>>
>>> Remove the use of __extension__ on function prototypes where
>>> rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
>>> conditionally compiled __extension__ at the non-standard forward
>>> declaration site.
>>>
>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>> ---
>>>   lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
>>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
>>> index d35551e..87ab03c 100644
>>> --- a/lib/eal/include/generic/rte_cpuflags.h
>>> +++ b/lib/eal/include/generic/rte_cpuflags.h
>>> @@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
>>>   /**
>>>    * Enumeration of all CPU features supported
>>>    */
>>> +#ifndef RTE_TOOLCHAIN_MSVC
>>>   __extension__
>>> -enum rte_cpu_flag_t;
>>> +typedef enum rte_cpu_flag_t rte_cpu_flag_t;
>>> +#else
>>> +typedef int rte_cpu_flag_t;
>>> +#endif
>>
>>
>> Just curious what exactly MSVC doesn't support here?
>> Is that construction like:
>> enum rte_cpu_flag_t {....};
>> enum rte_cpu_flag_t;
>> ...
>> Or something else?
> 
> Forward declaration of an enum is non standard. It's probably only
> allowed by gcc as an extension because gcc will make some kind of
> implementation specific promise for it always to be `int` size by
> default (assuming no other -foptions).

I understood that part, what is not clear to me from where we are 
getting forward declarations?
As I remember the usual organization of arch specific rte_cpuflags.h:

/* type definition */
enum rte_cpu_flag_t {...};

/some other stuff */

#include "generic/rte_cpuflags.h"

Which contains 'enum rte_cpu_flag_t' type declaration.
But it doesn't look like a forward declaration to me.
Is there a place where we do include "generic/rte_cpuflags.h" directly
(not from arch specific header)?
If so. might be we should change it to include arch specific header instead?

> 
> If the enum was defined before reference it would probably be accepted
> by msvc since it could 'see' the definition and know the integer width
> in use.
> 
>>
>>
>>>   /**
>>>    * Get name of CPU flag
>>> @@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
>>>    *     flag name
>>>    *     NULL if flag ID is invalid
>>>    */
>>> -__extension__
>>>   const char *
>>> -rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
>>> +rte_cpu_get_flag_name(rte_cpu_flag_t feature);
>>>   /**
>>>    * Function for checking a CPU flag availability
>>> @@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
>>>    *     0 if flag is not available
>>>    *     -ENOENT if flag is invalid
>>>    */
>>> -__extension__
>>>   int
>>> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
>>> +rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
>>>   /**
>>>    * This function checks that the currently used CPU supports the CPU features

Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Tyler Retzlaff]

On Sun, Apr 16, 2023 at 10:29:38PM +0100, Konstantin Ananyev wrote:
> 10/04/2023 21:53, Tyler Retzlaff пишет:
> >On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote:
> >>06/04/2023 01:45, Tyler Retzlaff пишет:
> >>>Forward declaration of a typedef is a non-standard extension and is not
> >>>supported by msvc. Use an int instead.
> >>>
> >>>Abstract the use of the int/enum rte_cpu_flag_t in function parameter
> >>>lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
> >>>identifier.
> >>>
> >>>Remove the use of __extension__ on function prototypes where
> >>>rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
> >>>conditionally compiled __extension__ at the non-standard forward
> >>>declaration site.
> >>>
> >>>Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >>>---
> >>>  lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
> >>>  1 file changed, 7 insertions(+), 5 deletions(-)
> >>>
> >>>diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
> >>>index d35551e..87ab03c 100644
> >>>--- a/lib/eal/include/generic/rte_cpuflags.h
> >>>+++ b/lib/eal/include/generic/rte_cpuflags.h
> >>>@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
> >>>  /**
> >>>   * Enumeration of all CPU features supported
> >>>   */
> >>>+#ifndef RTE_TOOLCHAIN_MSVC
> >>>  __extension__
> >>>-enum rte_cpu_flag_t;
> >>>+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
> >>>+#else
> >>>+typedef int rte_cpu_flag_t;
> >>>+#endif
> >>
> >>
> >>Just curious what exactly MSVC doesn't support here?
> >>Is that construction like:
> >>enum rte_cpu_flag_t {....};
> >>enum rte_cpu_flag_t;
> >>...
> >>Or something else?
> >
> >Forward declaration of an enum is non standard. It's probably only
> >allowed by gcc as an extension because gcc will make some kind of
> >implementation specific promise for it always to be `int` size by
> >default (assuming no other -foptions).
> 
> I understood that part, what is not clear to me from where we are
> getting forward declarations?

i investigated and expirmented with this further. i can see now there
were two things that were tripping things up portability wise.

* it's still a forward declaration even if the full enum definition is
  visible and thus generates a warning (but not an error).

* the use of __extension__ which is valid in this context because it is
  after all an extension (causes compilation error for msvc).

my testing shows i'm still getting correct sizes (because the definition
is visible) so what i'll do is update this patch to remove the use of
__extension__ and allow the warning to be emitted for now. i think this
is probably what you're preference would be.

in a future series i will either suppress the warning for msvc or remove
the declaration entirely which as you point out should not be needed due
to the include via arch/rte_cpuflags.h -> include generic/rte_cpuflags.h.

thanks!

> As I remember the usual organization of arch specific rte_cpuflags.h:
> 
> /* type definition */
> enum rte_cpu_flag_t {...};
> 
> /some other stuff */
> 
> #include "generic/rte_cpuflags.h"
> 
> Which contains 'enum rte_cpu_flag_t' type declaration.
> But it doesn't look like a forward declaration to me.
> Is there a place where we do include "generic/rte_cpuflags.h" directly
> (not from arch specific header)?
> If so. might be we should change it to include arch specific header instead?
> 
> >
> >If the enum was defined before reference it would probably be accepted
> >by msvc since it could 'see' the definition and know the integer width
> >in use.
> >
> >>
> >>
> >>>  /**
> >>>   * Get name of CPU flag
> >>>@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
> >>>   *     flag name
> >>>   *     NULL if flag ID is invalid
> >>>   */
> >>>-__extension__
> >>>  const char *
> >>>-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
> >>>+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
> >>>  /**
> >>>   * Function for checking a CPU flag availability
> >>>@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
> >>>   *     0 if flag is not available
> >>>   *     -ENOENT if flag is invalid
> >>>   */
> >>>-__extension__
> >>>  int
> >>>-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
> >>>+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
> >>>  /**
> >>>   * This function checks that the currently used CPU supports the CPU features

Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc

[Konstantin Ananyev]

17/04/2023 16:46, Tyler Retzlaff пишет:
> On Sun, Apr 16, 2023 at 10:29:38PM +0100, Konstantin Ananyev wrote:
>> 10/04/2023 21:53, Tyler Retzlaff пишет:
>>> On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote:
>>>> 06/04/2023 01:45, Tyler Retzlaff пишет:
>>>>> Forward declaration of a typedef is a non-standard extension and is not
>>>>> supported by msvc. Use an int instead.
>>>>>
>>>>> Abstract the use of the int/enum rte_cpu_flag_t in function parameter
>>>>> lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
>>>>> identifier.
>>>>>
>>>>> Remove the use of __extension__ on function prototypes where
>>>>> rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
>>>>> conditionally compiled __extension__ at the non-standard forward
>>>>> declaration site.
>>>>>
>>>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>>>> ---
>>>>>   lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
>>>>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
>>>>> index d35551e..87ab03c 100644
>>>>> --- a/lib/eal/include/generic/rte_cpuflags.h
>>>>> +++ b/lib/eal/include/generic/rte_cpuflags.h
>>>>> @@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
>>>>>   /**
>>>>>    * Enumeration of all CPU features supported
>>>>>    */
>>>>> +#ifndef RTE_TOOLCHAIN_MSVC
>>>>>   __extension__
>>>>> -enum rte_cpu_flag_t;
>>>>> +typedef enum rte_cpu_flag_t rte_cpu_flag_t;
>>>>> +#else
>>>>> +typedef int rte_cpu_flag_t;
>>>>> +#endif
>>>>
>>>>
>>>> Just curious what exactly MSVC doesn't support here?
>>>> Is that construction like:
>>>> enum rte_cpu_flag_t {....};
>>>> enum rte_cpu_flag_t;
>>>> ...
>>>> Or something else?
>>>
>>> Forward declaration of an enum is non standard. It's probably only
>>> allowed by gcc as an extension because gcc will make some kind of
>>> implementation specific promise for it always to be `int` size by
>>> default (assuming no other -foptions).
>>
>> I understood that part, what is not clear to me from where we are
>> getting forward declarations?
> 
> i investigated and expirmented with this further. i can see now there
> were two things that were tripping things up portability wise.
> 
> * it's still a forward declaration even if the full enum definition is
>    visible and thus generates a warning (but not an error).
> 
> * the use of __extension__ which is valid in this context because it is
>    after all an extension (causes compilation error for msvc).
> 
> my testing shows i'm still getting correct sizes (because the definition
> is visible) so what i'll do is update this patch to remove the use of
> __extension__ and allow the warning to be emitted for now. i think this
> is probably what you're preference would be.
> 
> in a future series i will either suppress the warning for msvc or remove
> the declaration entirely which as you point out should not be needed due
> to the include via arch/rte_cpuflags.h -> include generic/rte_cpuflags.h.

Agree, let's try to remove this declaration.
I don't see any point to have declaration straight after defintion.
Thanks
Konstantin

> 
> thanks!
> 
>> As I remember the usual organization of arch specific rte_cpuflags.h:
>>
>> /* type definition */
>> enum rte_cpu_flag_t {...};
>>
>> /some other stuff */
>>
>> #include "generic/rte_cpuflags.h"
>>
>> Which contains 'enum rte_cpu_flag_t' type declaration.
>> But it doesn't look like a forward declaration to me.
>> Is there a place where we do include "generic/rte_cpuflags.h" directly
>> (not from arch specific header)?
>> If so. might be we should change it to include arch specific header instead?
>>
>>>
>>> If the enum was defined before reference it would probably be accepted
>>> by msvc since it could 'see' the definition and know the integer width
>>> in use.
>>>
>>>>
>>>>
>>>>>   /**
>>>>>    * Get name of CPU flag
>>>>> @@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
>>>>>    *     flag name
>>>>>    *     NULL if flag ID is invalid
>>>>>    */
>>>>> -__extension__
>>>>>   const char *
>>>>> -rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
>>>>> +rte_cpu_get_flag_name(rte_cpu_flag_t feature);
>>>>>   /**
>>>>>    * Function for checking a CPU flag availability
>>>>> @@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
>>>>>    *     0 if flag is not available
>>>>>    *     -ENOENT if flag is invalid
>>>>>    */
>>>>> -__extension__
>>>>>   int
>>>>> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
>>>>> +rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
>>>>>   /**
>>>>>    * This function checks that the currently used CPU supports the CPU features

[PATCH v3 07/11] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with msvc don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v3 08/11] eal: expand most macros to empty when using msvc

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 ++++++++
 lib/eal/include/rte_common.h            | 33 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++++++
 3 files changed, 61 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..d9a0224 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(x)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(x)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..a724e22 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -88,8 +92,13 @@
 #define __rte_may_alias __attribute__((__may_alias__))
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -117,7 +126,11 @@
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +154,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +162,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +239,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +268,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +466,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

Re: [PATCH v3 08/11] eal: expand most macros to empty when using msvc

[Stephen Hemminger]

On Wed,  5 Apr 2023 17:45:16 -0700
Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:

> For now expand a lot of common rte macros empty. The catch here is we
> need to test that most of the macros do what they should but at the same
> time they are blocking work needed to bootstrap of the unit tests.
> 
> Later we will return and provide (where possible) expansions that work
> correctly for msvc and where not possible provide some alternate macros
> to achieve the same outcome.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Ok, but doesn't SAL have definitions for most of these?

Re: [PATCH v3 08/11] eal: expand most macros to empty when using msvc

[Tyler Retzlaff]

On Wed, Apr 05, 2023 at 07:25:45PM -0700, Stephen Hemminger wrote:
> On Wed,  5 Apr 2023 17:45:16 -0700
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> 
> > For now expand a lot of common rte macros empty. The catch here is we
> > need to test that most of the macros do what they should but at the same
> > time they are blocking work needed to bootstrap of the unit tests.
> > 
> > Later we will return and provide (where possible) expansions that work
> > correctly for msvc and where not possible provide some alternate macros
> > to achieve the same outcome.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> 
> Ok, but doesn't SAL have definitions for most of these?

SAL could be used too, but i was considering that more as an integration
with David's recent clang annotation additions. SAL is a broader topic
since to be useful it would need to leverage tooling.

depending on the macros some will come from existing msvc e.g. __declspec
some will come from standard C e.g. _Noreturn

many may not be critical for correct behavior but when used can decrease
misuse or increase performance through better codegen. once we have
things functioning correctly there will naturally be improvements in
both areas that follow.

[PATCH v3 09/11] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index ca733c5..b45ab28 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -82,6 +82,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -278,6 +280,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v3 10/11] telemetry: disable json print formatting with msvc

[Tyler Retzlaff]

VLAs are unsafe and will never be implemented in MSVC. When compiling
with MSVC just return immediately indicating 0 output characters
formatted.

For now telemetry doesn't work on Windows, we will revisit support for
the telemetry library sometime after we establish the DPDK unit tests.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_json.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index 744bbfe..d847003 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -30,6 +30,7 @@
 static inline int
 __json_snprintf(char *buf, const int len, const char *format, ...)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	va_list ap;
 	int ret;
@@ -41,6 +42,7 @@
 		strcpy(buf, tmp);
 		return ret;
 	}
+#endif
 	return 0; /* nothing written or modified */
 }
 
@@ -60,6 +62,7 @@
 static inline int
 __json_format_str(char *buf, const int len, const char *prefix, const char *str, const char *suffix)
 {
+#ifndef RTE_TOOLCHAIN_MSVC
 	char tmp[len];
 	int tmpidx = 0;
 
@@ -98,6 +101,9 @@
 
 	strcpy(buf, tmp);
 	return tmpidx;
+#else
+	return 0;
+#endif
 }
 
 /* Copies an empty array into the provided buffer. */
-- 
1.8.3.1

Re: [PATCH v3 10/11] telemetry: disable json print formatting with msvc

[Bruce Richardson]

On Wed, Apr 05, 2023 at 05:45:18PM -0700, Tyler Retzlaff wrote:
> VLAs are unsafe and will never be implemented in MSVC. When compiling
> with MSVC just return immediately indicating 0 output characters
> formatted.
> 
> For now telemetry doesn't work on Windows, we will revisit support for
> the telemetry library sometime after we establish the DPDK unit tests.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/telemetry/telemetry_json.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
I'm guessing this patch can be dropped if patchset [1] is merged, right?

/Bruce

[1] http://patches.dpdk.org/project/dpdk/list/?series=27629

Re: [PATCH v3 10/11] telemetry: disable json print formatting with msvc

[Tyler Retzlaff]

On Thu, Apr 06, 2023 at 10:25:07AM +0100, Bruce Richardson wrote:
> On Wed, Apr 05, 2023 at 05:45:18PM -0700, Tyler Retzlaff wrote:
> > VLAs are unsafe and will never be implemented in MSVC. When compiling
> > with MSVC just return immediately indicating 0 output characters
> > formatted.
> > 
> > For now telemetry doesn't work on Windows, we will revisit support for
> > the telemetry library sometime after we establish the DPDK unit tests.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/telemetry/telemetry_json.h | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> I'm guessing this patch can be dropped if patchset [1] is merged, right?

Absolutely. I'll take a look at the referenced series soon.

> 
> /Bruce
> 
> [1] http://patches.dpdk.org/project/dpdk/list/?series=27629

[PATCH v3 11/11] telemetry: avoid expanding versioned symbol macros on msvc

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

Re: [PATCH v3 11/11] telemetry: avoid expanding versioned symbol macros on msvc

[Bruce Richardson]

On Wed, Apr 05, 2023 at 05:45:19PM -0700, Tyler Retzlaff wrote:
> Windows does not support versioned symbols. Fortunately Windows also
> doesn't have an exported stable ABI.
> 
> Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> functions.
> 
> Windows does have a way to achieve similar versioning for symbols but it
> is not a simple #define so it will be done as a work package later.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 2bac2de..284c16e 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -82,8 +82,16 @@
>  /* mark the v23 function as the older version, and v24 as the default version */
>  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
>  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> +#ifndef RTE_TOOLCHAIN_MSVC
>  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
>  		int64_t x), rte_tel_data_add_array_int_v24);
> +#else
> +int
> +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> +{
> +	return rte_tel_data_add_array_int_v24(d, x);
> +}
> +#endif
>  

Can't see any general way to do this from the versioning header file, so
agree that we need some changes here. Rather than defining a public
funcion, we could keep the diff reduced by just using a macro alias here,
right? For example:

#ifdef RTE_TOOLCHAIN_MSVC
#define rte_tel_data_add_array_int rte_tel_data_add_array_int_v24
#else
MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
		int64_t x), rte_tel_data_add_array_int_v24);
#endif

If this is a temporary measure, I'd tend towards the shortest solution that
can work. However, no strong opinions, so, either using functions as you
have it, or macros:

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [PATCH v3 11/11] telemetry: avoid expanding versioned symbol macros on msvc

[Tyler Retzlaff]

On Tue, Apr 11, 2023 at 11:24:07AM +0100, Bruce Richardson wrote:
> On Wed, Apr 05, 2023 at 05:45:19PM -0700, Tyler Retzlaff wrote:
> > Windows does not support versioned symbols. Fortunately Windows also
> > doesn't have an exported stable ABI.
> > 
> > Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> > and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> > functions.
> > 
> > Windows does have a way to achieve similar versioning for symbols but it
> > is not a simple #define so it will be done as a work package later.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> > index 2bac2de..284c16e 100644
> > --- a/lib/telemetry/telemetry_data.c
> > +++ b/lib/telemetry/telemetry_data.c
> > @@ -82,8 +82,16 @@
> >  /* mark the v23 function as the older version, and v24 as the default version */
> >  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
> >  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
> >  		int64_t x), rte_tel_data_add_array_int_v24);
> > +#else
> > +int
> > +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> > +{
> > +	return rte_tel_data_add_array_int_v24(d, x);
> > +}
> > +#endif
> >  
> 
> Can't see any general way to do this from the versioning header file, so
> agree that we need some changes here. Rather than defining a public
> funcion, we could keep the diff reduced by just using a macro alias here,
> right? For example:
> 
> #ifdef RTE_TOOLCHAIN_MSVC
> #define rte_tel_data_add_array_int rte_tel_data_add_array_int_v24
> #else
> MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
> 		int64_t x), rte_tel_data_add_array_int_v24);
> #endif
> 
> If this is a temporary measure, I'd tend towards the shortest solution that
> can work. However, no strong opinions, so, either using functions as you
> have it, or macros:

so i have to leave it as it is the reason being the version.map ->
exports.def generation does not handle this. the .def only contains the
rte_tel_data_add_array_int symbol. if we expand it away to the _v24 name
the link will fail.

let's consume the change as-is for now and i will work on the
generalized solution when changes are integrated that actually make the
windows dso/dll functional.

> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [PATCH v3 11/11] telemetry: avoid expanding versioned symbol macros on msvc

[Bruce Richardson]

On Tue, Apr 11, 2023 at 01:34:14PM -0700, Tyler Retzlaff wrote:
> On Tue, Apr 11, 2023 at 11:24:07AM +0100, Bruce Richardson wrote:
> > On Wed, Apr 05, 2023 at 05:45:19PM -0700, Tyler Retzlaff wrote:
> > > Windows does not support versioned symbols. Fortunately Windows also
> > > doesn't have an exported stable ABI.
> > > 
> > > Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
> > > and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
> > > functions.
> > > 
> > > Windows does have a way to achieve similar versioning for symbols but it
> > > is not a simple #define so it will be done as a work package later.
> > > 
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > >  lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> > > index 2bac2de..284c16e 100644
> > > --- a/lib/telemetry/telemetry_data.c
> > > +++ b/lib/telemetry/telemetry_data.c
> > > @@ -82,8 +82,16 @@
> > >  /* mark the v23 function as the older version, and v24 as the default version */
> > >  VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
> > >  BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
> > >  		int64_t x), rte_tel_data_add_array_int_v24);
> > > +#else
> > > +int
> > > +rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
> > > +{
> > > +	return rte_tel_data_add_array_int_v24(d, x);
> > > +}
> > > +#endif
> > >  
> > 
> > Can't see any general way to do this from the versioning header file, so
> > agree that we need some changes here. Rather than defining a public
> > funcion, we could keep the diff reduced by just using a macro alias here,
> > right? For example:
> > 
> > #ifdef RTE_TOOLCHAIN_MSVC
> > #define rte_tel_data_add_array_int rte_tel_data_add_array_int_v24
> > #else
> > MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
> > 		int64_t x), rte_tel_data_add_array_int_v24);
> > #endif
> > 
> > If this is a temporary measure, I'd tend towards the shortest solution that
> > can work. However, no strong opinions, so, either using functions as you
> > have it, or macros:
> 
> so i have to leave it as it is the reason being the version.map ->
> exports.def generation does not handle this. the .def only contains the
> rte_tel_data_add_array_int symbol. if we expand it away to the _v24 name
> the link will fail.
> 

Ah, thanks for clarifying

> let's consume the change as-is for now and i will work on the
> generalized solution when changes are integrated that actually make the
> windows dso/dll functional.
> 

Sure, good for now. Keep my ack on any future versions.
> > 
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>

[PATCH v4 00/14] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: typedef cpu flag enum as int
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian

 config/x86/meson.build                  |  6 +++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++++
 lib/eal/include/generic/rte_byteorder.h |  2 ++
 lib/eal/include/generic/rte_cpuflags.h  | 12 +++++----
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 ++++++
 lib/eal/include/rte_common.h            | 45 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++++++
 lib/eal/x86/include/rte_atomic.h        |  9 ++++++-
 lib/eal/x86/include/rte_byteorder.h     | 27 ++++++++++++++++++++
 lib/eal/x86/include/rte_cycles.h        | 14 +++++-----
 lib/eal/x86/include/rte_prefetch.h      | 29 +++++++++++++++++++++
 lib/eal/x86/include/rte_rtm.h           | 18 ++++---------
 lib/eal/x86/rte_cpuflags.c              |  4 +++
 lib/eal/x86/rte_cpuid.h                 |  7 +++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++++
 lib/telemetry/telemetry_data.c          | 16 ++++++++++++
 19 files changed, 259 insertions(+), 25 deletions(-)

-- 
1.8.3.1

[PATCH v4 01/14] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include <x86intrin.h>
+#else
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

RE: [PATCH v4 01/14] eal: use rdtsc intrinsic

[Konstantin Ananyev]

> Inline assembly is not supported for MSVC x64. Convert code to use
> __rdtsc intrinsic.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
> index a461a4d..cca5122 100644
> --- a/lib/eal/x86/include/rte_cycles.h
> +++ b/lib/eal/x86/include/rte_cycles.h
> @@ -6,6 +6,12 @@
>  #ifndef _RTE_CYCLES_X86_64_H_
>  #define _RTE_CYCLES_X86_64_H_
> 
> +#ifndef RTE_TOOLCHAIN_MSVC
> +#include <x86intrin.h>
> +#else
> +#include <intrin.h>
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> @@ -23,6 +29,7 @@
>  static inline uint64_t
>  rte_rdtsc(void)
>  {
> +#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
>  	union {
>  		uint64_t tsc_64;
>  		RTE_STD_C11
> @@ -32,7 +39,6 @@
>  		};
>  	} tsc;
> 
> -#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
>  	if (unlikely(rte_cycles_vmware_tsc_map)) {
>  		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
>  		asm volatile("rdpmc" :
> @@ -42,11 +48,7 @@
>  		return tsc.tsc_64;
>  	}
>  #endif
> -
> -	asm volatile("rdtsc" :
> -		     "=a" (tsc.lo_32),
> -		     "=d" (tsc.hi_32));
> -	return tsc.tsc_64;
> +	return __rdtsc();
>  }
> 
>  static inline uint64_t
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
 

> 1.8.3.1

[PATCH v4 02/14] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

Re: [PATCH v4 02/14] eal: use rtm and xtest intrinsics

[Bruce Richardson]

On Tue, Apr 11, 2023 at 02:12:16PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for MSVC x64. Convert code to use
> _xend, _xabort and _xtest intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---

Subject to the CI not reporting any errors:

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

>  config/x86/meson.build        |  6 ++++++
>  lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
>  2 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/config/x86/meson.build b/config/x86/meson.build
> index 54345c4..4c0b06c 100644
> --- a/config/x86/meson.build
> +++ b/config/x86/meson.build
> @@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
>      machine_args += '-msse4'
>  endif
>  
> +# enable restricted transactional memory intrinsics
> +# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
> +if cc.get_id() != 'msvc'
> +    machine_args += '-mrtm'
> +endif
> +
>  base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
>  foreach f:base_flags
>      compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
> diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
> index 36bf498..b84e58e 100644
> --- a/lib/eal/x86/include/rte_rtm.h
> +++ b/lib/eal/x86/include/rte_rtm.h
> @@ -5,6 +5,7 @@
>  #ifndef _RTE_RTM_H_
>  #define _RTE_RTM_H_ 1
>  
> +#include <immintrin.h>
>  
>  /* Official RTM intrinsics interface matching gcc/icc, but works
>     on older gcc compatible compilers and binutils. */
> @@ -28,31 +29,22 @@
>  static __rte_always_inline
>  unsigned int rte_xbegin(void)
>  {
> -	unsigned int ret = RTE_XBEGIN_STARTED;
> -
> -	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
> -	return ret;
> +	return _xbegin();
>  }
>  
>  static __rte_always_inline
>  void rte_xend(void)
>  {
> -	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
> +	_xend();
>  }
>  
>  /* not an inline function to workaround a clang bug with -O0 */
> -#define rte_xabort(status) do { \
> -	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
> -} while (0)
> +#define rte_xabort(status) _xabort(status)
>  
>  static __rte_always_inline
>  int rte_xtest(void)
>  {
> -	unsigned char out;
> -
> -	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
> -		"=r" (out) :: "memory");
> -	return out;
> +	return _xtest();
>  }
>  
>  #ifdef __cplusplus
> -- 
> 1.8.3.1
> 

RE: [PATCH v4 02/14] eal: use rtm and xtest intrinsics

[Konstantin Ananyev]

> Inline assembly is not supported for MSVC x64. Convert code to use
> _xend, _xabort and _xtest intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  config/x86/meson.build        |  6 ++++++
>  lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
>  2 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/config/x86/meson.build b/config/x86/meson.build
> index 54345c4..4c0b06c 100644
> --- a/config/x86/meson.build
> +++ b/config/x86/meson.build
> @@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
>      machine_args += '-msse4'
>  endif
> 
> +# enable restricted transactional memory intrinsics
> +# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
> +if cc.get_id() != 'msvc'
> +    machine_args += '-mrtm'
> +endif
> +
>  base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
>  foreach f:base_flags
>      compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
> diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
> index 36bf498..b84e58e 100644
> --- a/lib/eal/x86/include/rte_rtm.h
> +++ b/lib/eal/x86/include/rte_rtm.h
> @@ -5,6 +5,7 @@
>  #ifndef _RTE_RTM_H_
>  #define _RTE_RTM_H_ 1
> 
> +#include <immintrin.h>
> 
>  /* Official RTM intrinsics interface matching gcc/icc, but works
>     on older gcc compatible compilers and binutils. */
> @@ -28,31 +29,22 @@
>  static __rte_always_inline
>  unsigned int rte_xbegin(void)
>  {
> -	unsigned int ret = RTE_XBEGIN_STARTED;
> -
> -	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
> -	return ret;
> +	return _xbegin();
>  }
> 
>  static __rte_always_inline
>  void rte_xend(void)
>  {
> -	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
> +	_xend();
>  }
> 
>  /* not an inline function to workaround a clang bug with -O0 */
> -#define rte_xabort(status) do { \
> -	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
> -} while (0)
> +#define rte_xabort(status) _xabort(status)
> 
>  static __rte_always_inline
>  int rte_xtest(void)
>  {
> -	unsigned char out;
> -
> -	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
> -		"=r" (out) :: "memory");
> -	return out;
> +	return _xtest();
>  }
> 
>  #ifdef __cplusplus
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
 

> 1.8.3.1

[PATCH v4 03/14] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..ca733c5 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -28,7 +28,6 @@
 #define	rte_rmb() _mm_lfence()
 
 #define rte_smp_wmb() rte_compiler_barrier()
-
 #define rte_smp_rmb() rte_compiler_barrier()
 
 /*
@@ -66,11 +65,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

Re: [PATCH v4 03/14] eal: use barrier intrinsics

[Bruce Richardson]

On Tue, Apr 11, 2023 at 02:12:17PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for MSVC x64 instead expand
> rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
> _m_mfence intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

One whitespace line deletion below which can be dropped from diff if doing
a new revision.
> ---
>  lib/eal/include/generic/rte_atomic.h | 4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 5 ++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
>  
>  /**
>   * Synchronization fence between threads based on the specified memory order.
> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
> index f2ee1a9..ca733c5 100644
> --- a/lib/eal/x86/include/rte_atomic.h
> +++ b/lib/eal/x86/include/rte_atomic.h
> @@ -28,7 +28,6 @@
>  #define	rte_rmb() _mm_lfence()
>  
>  #define rte_smp_wmb() rte_compiler_barrier()
> -

  ^^ unnecessary drop

>  #define rte_smp_rmb() rte_compiler_barrier()
>  
>  /*
> @@ -66,11 +65,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
>  }
>  
>  #define rte_io_mb() rte_mb()
> -- 
> 1.8.3.1
> 

RE: [PATCH v4 03/14] eal: use barrier intrinsics

[Konstantin Ananyev]

> Inline assembly is not supported for MSVC x64 instead expand
> rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
> _m_mfence intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/generic/rte_atomic.h | 4 ++++
>  lib/eal/x86/include/rte_atomic.h     | 5 ++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
> 
>  /**
>   * Synchronization fence between threads based on the specified memory order.
> diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
> index f2ee1a9..ca733c5 100644
> --- a/lib/eal/x86/include/rte_atomic.h
> +++ b/lib/eal/x86/include/rte_atomic.h
> @@ -28,7 +28,6 @@
>  #define	rte_rmb() _mm_lfence()
> 
>  #define rte_smp_wmb() rte_compiler_barrier()
> -
>  #define rte_smp_rmb() rte_compiler_barrier()
> 
>  /*
> @@ -66,11 +65,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
>  }
> 
>  #define rte_io_mb() rte_mb()
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
 

> 1.8.3.1

[PATCH v4 04/14] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v4 05/14] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#else
+	_umonitor(pmc->addr);
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#else
+	_umwait(tsc_l, tsc_h);
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#else
+	_tpause(tsc_l, tsc_h);
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v4 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_prefetch.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..1391af0 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -13,6 +13,7 @@
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#ifndef RTE_TOOLCHAIN_MSVC
 static inline void rte_prefetch0(const volatile void *p)
 {
 	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
@@ -43,6 +44,34 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+static inline void rte_prefetch0(const volatile void *p)
+{
+	_mm_prefetch(p, 1);
+}
+
+static inline void rte_prefetch1(const volatile void *p)
+{
+	_mm_prefetch(p, 2);
+}
+
+static inline void rte_prefetch2(const volatile void *p)
+{
+	_mm_prefetch(p, 3);
+}
+
+static inline void rte_prefetch_non_temporal(const volatile void *p)
+{
+	_mm_prefetch(p, 0);
+}
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+	_mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

Re: [PATCH v4 06/14] eal: use prefetch intrinsics

[Bruce Richardson]

On Tue, Apr 11, 2023 at 02:12:20PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> and _mm_cldemote intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

One comment inline below for future consideration.

>  lib/eal/x86/include/rte_prefetch.h | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
> index 7fd01c4..1391af0 100644
> --- a/lib/eal/x86/include/rte_prefetch.h
> +++ b/lib/eal/x86/include/rte_prefetch.h
> @@ -13,6 +13,7 @@
>  #include <rte_common.h>
>  #include "generic/rte_prefetch.h"
>  
> +#ifndef RTE_TOOLCHAIN_MSVC
>  static inline void rte_prefetch0(const volatile void *p)
>  {
>  	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
> @@ -43,6 +44,34 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
>  {
>  	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
>  }
> +#else
> +static inline void rte_prefetch0(const volatile void *p)
> +{
> +	_mm_prefetch(p, 1);
> +}
> +
> +static inline void rte_prefetch1(const volatile void *p)
> +{
> +	_mm_prefetch(p, 2);
> +}
> +
> +static inline void rte_prefetch2(const volatile void *p)
> +{
> +	_mm_prefetch(p, 3);
> +}
> +
> +static inline void rte_prefetch_non_temporal(const volatile void *p)
> +{
> +	_mm_prefetch(p, 0);
> +}

For these prefetch instructions, I'm not sure there is any reason why we
can't drop the inline assembly versions. The instructions are very old at
this point and should be widely supported by all compilers we use.

Rather than using hard-coded 1, 2, 3 values in the prefetch calls, I
believe there should be defines for the levels: "_MM_HINT_T0",
"_MM_HINT_T1" etc.

> +__rte_experimental
> +static inline void
> +rte_cldemote(const volatile void *p)
> +{
> +	_mm_cldemote(p);
> +}
> +#endif
> +
>  
>  #ifdef __cplusplus
>  }
> -- 
> 1.8.3.1
> 

RE: [PATCH v4 06/14] eal: use prefetch intrinsics

[Konstantin Ananyev]

> On Tue, Apr 11, 2023 at 02:12:20PM -0700, Tyler Retzlaff wrote:
> > Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> > and _mm_cldemote intrinsics.
> >
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> One comment inline below for future consideration.
> 
> >  lib/eal/x86/include/rte_prefetch.h | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
> > index 7fd01c4..1391af0 100644
> > --- a/lib/eal/x86/include/rte_prefetch.h
> > +++ b/lib/eal/x86/include/rte_prefetch.h
> > @@ -13,6 +13,7 @@
> >  #include <rte_common.h>
> >  #include "generic/rte_prefetch.h"
> >
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  static inline void rte_prefetch0(const volatile void *p)
> >  {
> >  	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
> > @@ -43,6 +44,34 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
> >  {
> >  	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
> >  }
> > +#else
> > +static inline void rte_prefetch0(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 1);
> > +}
> > +
> > +static inline void rte_prefetch1(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 2);
> > +}
> > +
> > +static inline void rte_prefetch2(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 3);
> > +}
> > +
> > +static inline void rte_prefetch_non_temporal(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 0);
> > +}
> 
> For these prefetch instructions, I'm not sure there is any reason why we
> can't drop the inline assembly versions. The instructions are very old at
> this point and should be widely supported by all compilers we use.
> 
> Rather than using hard-coded 1, 2, 3 values in the prefetch calls, I
> believe there should be defines for the levels: "_MM_HINT_T0",
> "_MM_HINT_T1" etc.

+1
 

> 
> > +__rte_experimental
> > +static inline void
> > +rte_cldemote(const volatile void *p)
> > +{
> > +	_mm_cldemote(p);
> > +}
> > +#endif
> > +
> >
> >  #ifdef __cplusplus
> >  }
> > --
> > 1.8.3.1
> >

Re: [PATCH v4 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

On Wed, Apr 12, 2023 at 10:05:57AM +0100, Bruce Richardson wrote:
> On Tue, Apr 11, 2023 at 02:12:20PM -0700, Tyler Retzlaff wrote:
> > Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> > and _mm_cldemote intrinsics.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> One comment inline below for future consideration.
> 
> >  lib/eal/x86/include/rte_prefetch.h | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
> > index 7fd01c4..1391af0 100644
> > --- a/lib/eal/x86/include/rte_prefetch.h
> > +++ b/lib/eal/x86/include/rte_prefetch.h
> > @@ -13,6 +13,7 @@
> >  #include <rte_common.h>
> >  #include "generic/rte_prefetch.h"
> >  
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  static inline void rte_prefetch0(const volatile void *p)
> >  {
> >  	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
> > @@ -43,6 +44,34 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
> >  {
> >  	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
> >  }
> > +#else
> > +static inline void rte_prefetch0(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 1);
> > +}
> > +
> > +static inline void rte_prefetch1(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 2);
> > +}
> > +
> > +static inline void rte_prefetch2(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 3);
> > +}
> > +
> > +static inline void rte_prefetch_non_temporal(const volatile void *p)
> > +{
> > +	_mm_prefetch(p, 0);
> > +}
> 
> For these prefetch instructions, I'm not sure there is any reason why we
> can't drop the inline assembly versions. The instructions are very old at
> this point and should be widely supported by all compilers we use.
> 
> Rather than using hard-coded 1, 2, 3 values in the prefetch calls, I
> believe there should be defines for the levels: "_MM_HINT_T0",
> "_MM_HINT_T1" etc.

hm, i did not know about these and i bet they fix the problem i had.
i.e. if i use e.g. bare '1' i would not get the same prefetch codegen on
gcc/msvc but these defines probably resolve that problem.

let me take another look at this one.

> 
> > +__rte_experimental
> > +static inline void
> > +rte_cldemote(const volatile void *p)
> > +{
> > +	_mm_cldemote(p);
> > +}
> > +#endif
> > +
> >  
> >  #ifdef __cplusplus
> >  }
> > -- 
> > 1.8.3.1
> > 

[PATCH v4 07/14] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{short,long} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_byteorder.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..8ddfea7 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -9,6 +9,7 @@
 extern "C" {
 #endif
 
+#include <stdlib.h>
 #include <stdint.h>
 #include <rte_common.h>
 #include <rte_config.h>
@@ -18,6 +19,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -46,6 +48,31 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 		      );
 	return x;
 }
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long})
+ */
+
+/*
+ * An architecture-optimized byte swap for a 16-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap16().
+ */
+static inline uint16_t rte_arch_bswap16(uint16_t _x)
+{
+	return _byteswap_ushort(_x);
+}
+
+/*
+ * An architecture-optimized byte swap for a 32-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap32().
+ */
+static inline uint32_t rte_arch_bswap32(uint32_t _x)
+{
+	return _byteswap_ulong(_x);
+}
+#endif
 
 #ifndef RTE_FORCE_INTRINSICS
 #define rte_bswap16(x) ((uint16_t)(__builtin_constant_p(x) ?		\
-- 
1.8.3.1

[PATCH v4 08/14] eal: typedef cpu flag enum as int

[Tyler Retzlaff]

Forward declaration of a enum is a non-standard extension and is not
supported by MSVC. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

[PATCH v4 09/14] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v4 10/14] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v4 11/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++++
 lib/eal/include/rte_common.h            | 41 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++++
 3 files changed, 69 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..d9a0224 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(x)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(x)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..dd41315 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -85,11 +89,20 @@
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +123,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +162,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +170,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +247,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +276,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +474,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v4 12/14] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index ca733c5..b45ab28 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -82,6 +82,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -278,6 +280,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v4 13/14] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v4 14/14] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..7c00a75 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v5 00/14] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: typedef cpu flag enum as int
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++++
 lib/eal/include/generic/rte_cpuflags.h  | 12 ++++----
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 ++++++
 lib/eal/include/rte_common.h            | 49 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 ++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 ++++++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 ++++--------
 lib/eal/x86/rte_cpuflags.c              |  4 +++
 lib/eal/x86/rte_cpuid.h                 |  7 +++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 ++++++++
 lib/telemetry/telemetry_data.c          | 16 +++++++++++
 19 files changed, 243 insertions(+), 28 deletions(-)

-- 
1.8.3.1

[PATCH v5 01/14] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include <x86intrin.h>
+#else
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v5 02/14] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v5 03/14] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v5 04/14] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v5 05/14] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#else
+	_umonitor(pmc->addr);
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#else
+	_umwait(tsc_l, tsc_h);
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#else
+	_tpause(tsc_l, tsc_h);
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v5 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+	_mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

Re: [PATCH v5 06/14] eal: use prefetch intrinsics

[Bruce Richardson]

On Thu, Apr 13, 2023 at 02:25:55PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> and _mm_cldemote intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

[PATCH v5 07/14] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v5 08/14] eal: typedef cpu flag enum as int

[Tyler Retzlaff]

Forward declaration of a enum is a non-standard extension and is not
supported by MSVC. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

[PATCH v5 09/14] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v5 10/14] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 ++++++
 lib/eal/include/rte_common.h            | 45 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++++++
 3 files changed, 73 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..d9a0224 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(x)
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(x)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..1bdaa2d 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -65,7 +65,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +84,29 @@
 /**
  * Force a structure to be packed
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_packed __attribute__((__packed__))
+#else
+#define __rte_packed
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +127,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +166,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +174,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +251,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +280,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +478,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Thursday, 13 April 2023 23.26
> 
> For now expand a lot of common rte macros empty. The catch here is we
> need to test that most of the macros do what they should but at the same
> time they are blocking work needed to bootstrap of the unit tests.
> 
> Later we will return and provide (where possible) expansions that work
> correctly for msvc and where not possible provide some alternate macros
> to achieve the same outcome.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/include/rte_branch_prediction.h |  8 ++++++
>  lib/eal/include/rte_common.h            | 45
> +++++++++++++++++++++++++++++++++
>  lib/eal/include/rte_compat.h            | 20 +++++++++++++++
>  3 files changed, 73 insertions(+)
> 
> diff --git a/lib/eal/include/rte_branch_prediction.h
> b/lib/eal/include/rte_branch_prediction.h
> index 0256a9d..d9a0224 100644
> --- a/lib/eal/include/rte_branch_prediction.h
> +++ b/lib/eal/include/rte_branch_prediction.h
> @@ -25,7 +25,11 @@
>   *
>   */
>  #ifndef likely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define likely(x)	__builtin_expect(!!(x), 1)
> +#else
> +#define likely(x)	(x)

This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), and likely() must return Boolean (0 or 1).

> +#endif
>  #endif /* likely */
> 
>  /**
> @@ -39,7 +43,11 @@
>   *
>   */
>  #ifndef unlikely
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define unlikely(x)	__builtin_expect(!!(x), 0)
> +#else
> +#define unlikely(x)	(x)

This must also be (!!(x)), for the same reason as above.

> +#endif
>  #endif /* unlikely */
> 
>  #ifdef __cplusplus
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 2f464e3..1bdaa2d 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -65,7 +65,11 @@
>  /**
>   * Force alignment
>   */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> +#else
> +#define __rte_aligned(a)
> +#endif

It should be reviewed that __rte_aligned() is only used for optimization purposes, and is not required for DPDK to function properly.

> 
>  #ifdef RTE_ARCH_STRICT_ALIGN
>  typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> @@ -80,16 +84,29 @@
>  /**
>   * Force a structure to be packed
>   */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  #define __rte_packed __attribute__((__packed__))
> +#else
> +#define __rte_packed
> +#endif

Similar comment as for __rte_aligned(); however, I consider it more likely that structure packing is a functional requirement, and not just used for optimization. Based on my experience, it may be used for packing network structures; perhaps not in DPDK itself but maybe in DPDK applications.

The same risk applies to __rte_aligned(), but with lower probability.

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Bruce Richardson]

On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Thursday, 13 April 2023 23.26
> > 
> > For now expand a lot of common rte macros empty. The catch here is we
> > need to test that most of the macros do what they should but at the same
> > time they are blocking work needed to bootstrap of the unit tests.
> > 
> > Later we will return and provide (where possible) expansions that work
> > correctly for msvc and where not possible provide some alternate macros
> > to achieve the same outcome.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/rte_branch_prediction.h |  8 ++++++
> >  lib/eal/include/rte_common.h            | 45
> > +++++++++++++++++++++++++++++++++
> >  lib/eal/include/rte_compat.h            | 20 +++++++++++++++
> >  3 files changed, 73 insertions(+)
> > 
> > diff --git a/lib/eal/include/rte_branch_prediction.h
> > b/lib/eal/include/rte_branch_prediction.h
> > index 0256a9d..d9a0224 100644
> > --- a/lib/eal/include/rte_branch_prediction.h
> > +++ b/lib/eal/include/rte_branch_prediction.h
> > @@ -25,7 +25,11 @@
> >   *
> >   */
> >  #ifndef likely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define likely(x)	__builtin_expect(!!(x), 1)
> > +#else
> > +#define likely(x)	(x)
> 
> This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), and likely() must return Boolean (0 or 1).
> 

Will this really make a difference? Is there somewhere likely/unlikely
would be used where we would not get the same conversion to boolean than we
get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just
wondering if there are actual cases where it affects the output?]

> > +#endif
> >  #endif /* likely */
> > 
> >  /**
> > @@ -39,7 +43,11 @@
> >   *
> >   */
> >  #ifndef unlikely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define unlikely(x)	__builtin_expect(!!(x), 0)
> > +#else
> > +#define unlikely(x)	(x)
> 
> This must also be (!!(x)), for the same reason as above.
> 
> > +#endif
> >  #endif /* unlikely */
> > 
> >  #ifdef __cplusplus
> > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > index 2f464e3..1bdaa2d 100644
> > --- a/lib/eal/include/rte_common.h
> > +++ b/lib/eal/include/rte_common.h
> > @@ -65,7 +65,11 @@
> >  /**
> >   * Force alignment
> >   */
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > +#else
> > +#define __rte_aligned(a)
> > +#endif
> 
> It should be reviewed that __rte_aligned() is only used for optimization purposes, and is not required for DPDK to function properly.
> 

Good point.

If we look across all of DPDK, things will likely break, as we are relying
on alignment in various places to use the aligned versions of instructions.
For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86
vectorized driver code. A "git grep _load_si" shows quite a few aligned
vector load instructions used in our codebase. These will fault and cause a
crash if the data is not properly aligned. [I suspect that there are similar
restrictions on other architectures too, just not familiar with their
intrinsics to check.]

However, it may be that none of the code paths where these are used is
in code currently compiled on windows, so this may be safe for now. The
occurances are mostly in drivers.

$ git grep -l _load_si
drivers/common/idpf/idpf_common_rxtx_avx512.c
drivers/event/dlb2/dlb2.c
drivers/net/bnxt/bnxt_rxtx_vec_avx2.c
drivers/net/bnxt/bnxt_rxtx_vec_sse.c
drivers/net/enic/enic_rxtx_vec_avx2.c
drivers/net/i40e/i40e_rxtx_vec_avx2.c
drivers/net/i40e/i40e_rxtx_vec_avx512.c
drivers/net/iavf/iavf_rxtx_vec_avx2.c
drivers/net/iavf/iavf_rxtx_vec_avx512.c
drivers/net/iavf/iavf_rxtx_vec_sse.c
drivers/net/ice/ice_rxtx_vec_avx2.c
drivers/net/ice/ice_rxtx_vec_avx512.c
drivers/net/ice/ice_rxtx_vec_sse.c
drivers/net/mlx5/mlx5_rxtx_vec_sse.h
lib/acl/acl_bld.c
lib/distributor/rte_distributor_match_sse.c
lib/efd/rte_efd_x86.h
lib/hash/rte_cuckoo_hash.c
lib/member/rte_member_x86.h
lib/net/net_crc_avx512.c
lib/net/net_crc_sse.c


> > 
> >  #ifdef RTE_ARCH_STRICT_ALIGN
> >  typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> > @@ -80,16 +84,29 @@
> >  /**
> >   * Force a structure to be packed
> >   */
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define __rte_packed __attribute__((__packed__))
> > +#else
> > +#define __rte_packed
> > +#endif
> 
> Similar comment as for __rte_aligned(); however, I consider it more likely that structure packing is a functional requirement, and not just used for optimization. Based on my experience, it may be used for packing network structures; perhaps not in DPDK itself but maybe in DPDK applications.
> 

+1
Once libraries such as the net library in DPDK will form part of the
windows build this will need to be addressed or things will break.

> The same risk applies to __rte_aligned(), but with lower probability.
> 

/Bruce

RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 14 April 2023 11.22
> 
> On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Thursday, 13 April 2023 23.26
> > >
> > > For now expand a lot of common rte macros empty. The catch here is we
> > > need to test that most of the macros do what they should but at the same
> > > time they are blocking work needed to bootstrap of the unit tests.
> > >
> > > Later we will return and provide (where possible) expansions that work
> > > correctly for msvc and where not possible provide some alternate macros
> > > to achieve the same outcome.
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > >  lib/eal/include/rte_branch_prediction.h |  8 ++++++
> > >  lib/eal/include/rte_common.h            | 45
> > > +++++++++++++++++++++++++++++++++
> > >  lib/eal/include/rte_compat.h            | 20 +++++++++++++++
> > >  3 files changed, 73 insertions(+)
> > >
> > > diff --git a/lib/eal/include/rte_branch_prediction.h
> > > b/lib/eal/include/rte_branch_prediction.h
> > > index 0256a9d..d9a0224 100644
> > > --- a/lib/eal/include/rte_branch_prediction.h
> > > +++ b/lib/eal/include/rte_branch_prediction.h
> > > @@ -25,7 +25,11 @@
> > >   *
> > >   */
> > >  #ifndef likely
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define likely(x)	__builtin_expect(!!(x), 1)
> > > +#else
> > > +#define likely(x)	(x)
> >
> > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10),
> and likely() must return Boolean (0 or 1).
> >
> 
> Will this really make a difference? Is there somewhere likely/unlikely
> would be used where we would not get the same conversion to boolean than we
> get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just
> wondering if there are actual cases where it affects the output?]

I agree that it makes no difference the way it is typically used.

But there are creative developers out there, so these macros definitely need the "!!" conversion to Boolean.

> 
> > > +#endif
> > >  #endif /* likely */
> > >
> > >  /**
> > > @@ -39,7 +43,11 @@
> > >   *
> > >   */
> > >  #ifndef unlikely
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define unlikely(x)	__builtin_expect(!!(x), 0)
> > > +#else
> > > +#define unlikely(x)	(x)
> >
> > This must also be (!!(x)), for the same reason as above.
> >
> > > +#endif
> > >  #endif /* unlikely */
> > >
> > >  #ifdef __cplusplus
> > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > > index 2f464e3..1bdaa2d 100644
> > > --- a/lib/eal/include/rte_common.h
> > > +++ b/lib/eal/include/rte_common.h
> > > @@ -65,7 +65,11 @@
> > >  /**
> > >   * Force alignment
> > >   */
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > > +#else
> > > +#define __rte_aligned(a)
> > > +#endif
> >
> > It should be reviewed that __rte_aligned() is only used for optimization
> purposes, and is not required for DPDK to function properly.
> >
> 
> Good point.
> 
> If we look across all of DPDK, things will likely break, as we are relying
> on alignment in various places to use the aligned versions of instructions.
> For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86
> vectorized driver code. A "git grep _load_si" shows quite a few aligned
> vector load instructions used in our codebase. These will fault and cause a
> crash if the data is not properly aligned. [I suspect that there are similar
> restrictions on other architectures too, just not familiar with their
> intrinsics to check.]

Another thing that has been annoying me with the use of vector instructions:

Vector instructions are often used in a way where they cast away the type they are working on, so if that type is modified (e.g. a field is moved), the code will happily build, but fail at runtime.

When casting away the type for vector instructions, _Static_assert or BUILD_BUG_ON should be used to verify the assumptions about the cast away type. Such a practice might catch some of the places where the missing alignment (and missing structure packing) would fail.

> 
> However, it may be that none of the code paths where these are used is
> in code currently compiled on windows, so this may be safe for now. The
> occurances are mostly in drivers.
> 
> $ git grep -l _load_si
> drivers/common/idpf/idpf_common_rxtx_avx512.c
> drivers/event/dlb2/dlb2.c
> drivers/net/bnxt/bnxt_rxtx_vec_avx2.c
> drivers/net/bnxt/bnxt_rxtx_vec_sse.c
> drivers/net/enic/enic_rxtx_vec_avx2.c
> drivers/net/i40e/i40e_rxtx_vec_avx2.c
> drivers/net/i40e/i40e_rxtx_vec_avx512.c
> drivers/net/iavf/iavf_rxtx_vec_avx2.c
> drivers/net/iavf/iavf_rxtx_vec_avx512.c
> drivers/net/iavf/iavf_rxtx_vec_sse.c
> drivers/net/ice/ice_rxtx_vec_avx2.c
> drivers/net/ice/ice_rxtx_vec_avx512.c
> drivers/net/ice/ice_rxtx_vec_sse.c
> drivers/net/mlx5/mlx5_rxtx_vec_sse.h
> lib/acl/acl_bld.c
> lib/distributor/rte_distributor_match_sse.c
> lib/efd/rte_efd_x86.h
> lib/hash/rte_cuckoo_hash.c
> lib/member/rte_member_x86.h
> lib/net/net_crc_avx512.c
> lib/net/net_crc_sse.c
> 
> 
> > >
> > >  #ifdef RTE_ARCH_STRICT_ALIGN
> > >  typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> > > @@ -80,16 +84,29 @@
> > >  /**
> > >   * Force a structure to be packed
> > >   */
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define __rte_packed __attribute__((__packed__))
> > > +#else
> > > +#define __rte_packed
> > > +#endif
> >
> > Similar comment as for __rte_aligned(); however, I consider it more likely
> that structure packing is a functional requirement, and not just used for
> optimization. Based on my experience, it may be used for packing network
> structures; perhaps not in DPDK itself but maybe in DPDK applications.
> >
> 
> +1
> Once libraries such as the net library in DPDK will form part of the
> windows build this will need to be addressed or things will break.

Yes. And for application developers, we should deprecate and replace the __rte_packed macro with something that works on both MSVC and GCC/CLANG. The same probably goes for __rte_aligned().

But, let's not hold back Tyler's work. Just put it on the long term TODO list for MSVC support.

> 
> > The same risk applies to __rte_aligned(), but with lower probability.
> >
> 
> /Bruce

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Bruce Richardson]

On Fri, Apr 14, 2023 at 02:39:03PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 14 April 2023 11.22
> > 
> > On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > Sent: Thursday, 13 April 2023 23.26
> > > >
> > > > For now expand a lot of common rte macros empty. The catch here is we
> > > > need to test that most of the macros do what they should but at the same
> > > > time they are blocking work needed to bootstrap of the unit tests.
> > > >
> > > > Later we will return and provide (where possible) expansions that work
> > > > correctly for msvc and where not possible provide some alternate macros
> > > > to achieve the same outcome.
> > > >
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > ---
> > > >  lib/eal/include/rte_branch_prediction.h |  8 ++++++
> > > >  lib/eal/include/rte_common.h            | 45
> > > > +++++++++++++++++++++++++++++++++
> > > >  lib/eal/include/rte_compat.h            | 20 +++++++++++++++
> > > >  3 files changed, 73 insertions(+)
> > > >
> > > > diff --git a/lib/eal/include/rte_branch_prediction.h
> > > > b/lib/eal/include/rte_branch_prediction.h
> > > > index 0256a9d..d9a0224 100644
> > > > --- a/lib/eal/include/rte_branch_prediction.h
> > > > +++ b/lib/eal/include/rte_branch_prediction.h
> > > > @@ -25,7 +25,11 @@
> > > >   *
> > > >   */
> > > >  #ifndef likely
> > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > >  #define likely(x)	__builtin_expect(!!(x), 1)
> > > > +#else
> > > > +#define likely(x)	(x)
> > >
> > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10),
> > and likely() must return Boolean (0 or 1).
> > >
> > 
> > Will this really make a difference? Is there somewhere likely/unlikely
> > would be used where we would not get the same conversion to boolean than we
> > get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just
> > wondering if there are actual cases where it affects the output?]
> 
> I agree that it makes no difference the way it is typically used.
> 
> But there are creative developers out there, so these macros definitely need the "!!" conversion to Boolean.
> 

Sure.

> > 
> > > > +#endif
> > > >  #endif /* likely */
> > > >
> > > >  /**
> > > > @@ -39,7 +43,11 @@
> > > >   *
> > > >   */
> > > >  #ifndef unlikely
> > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > >  #define unlikely(x)	__builtin_expect(!!(x), 0)
> > > > +#else
> > > > +#define unlikely(x)	(x)
> > >
> > > This must also be (!!(x)), for the same reason as above.
> > >
> > > > +#endif
> > > >  #endif /* unlikely */
> > > >
> > > >  #ifdef __cplusplus
> > > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > > > index 2f464e3..1bdaa2d 100644
> > > > --- a/lib/eal/include/rte_common.h
> > > > +++ b/lib/eal/include/rte_common.h
> > > > @@ -65,7 +65,11 @@
> > > >  /**
> > > >   * Force alignment
> > > >   */
> > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > > > +#else
> > > > +#define __rte_aligned(a)
> > > > +#endif
> > >
> > > It should be reviewed that __rte_aligned() is only used for optimization
> > purposes, and is not required for DPDK to function properly.
> > >
> > 
> > Good point.
> > 
> > If we look across all of DPDK, things will likely break, as we are relying
> > on alignment in various places to use the aligned versions of instructions.
> > For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86
> > vectorized driver code. A "git grep _load_si" shows quite a few aligned
> > vector load instructions used in our codebase. These will fault and cause a
> > crash if the data is not properly aligned. [I suspect that there are similar
> > restrictions on other architectures too, just not familiar with their
> > intrinsics to check.]
> 
> Another thing that has been annoying me with the use of vector instructions:
> 
> Vector instructions are often used in a way where they cast away the type they are working on, so if that type is modified (e.g. a field is moved), the code will happily build, but fail at runtime.
> 
> When casting away the type for vector instructions, _Static_assert or BUILD_BUG_ON should be used to verify the assumptions about the cast away type. Such a practice might catch some of the places where the missing alignment (and missing structure packing) would fail.
> 

Agreed. And, in fairness, this is sometimes done in our code, e.g. [1], but
should probably be more widely done. It's something we should try and catch
in reviews of vector code, as it also helps document what exactly we are
doing and why.

/Bruce

[1] http://git.dpdk.org/dpdk/tree/drivers/net/i40e/i40e_rxtx_vec_avx2.c#n183

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Thursday, 13 April 2023 23.26
> > 
> > For now expand a lot of common rte macros empty. The catch here is we
> > need to test that most of the macros do what they should but at the same
> > time they are blocking work needed to bootstrap of the unit tests.
> > 
> > Later we will return and provide (where possible) expansions that work
> > correctly for msvc and where not possible provide some alternate macros
> > to achieve the same outcome.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
> >  lib/eal/include/rte_branch_prediction.h |  8 ++++++
> >  lib/eal/include/rte_common.h            | 45
> > +++++++++++++++++++++++++++++++++
> >  lib/eal/include/rte_compat.h            | 20 +++++++++++++++
> >  3 files changed, 73 insertions(+)
> > 
> > diff --git a/lib/eal/include/rte_branch_prediction.h
> > b/lib/eal/include/rte_branch_prediction.h
> > index 0256a9d..d9a0224 100644
> > --- a/lib/eal/include/rte_branch_prediction.h
> > +++ b/lib/eal/include/rte_branch_prediction.h
> > @@ -25,7 +25,11 @@
> >   *
> >   */
> >  #ifndef likely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define likely(x)	__builtin_expect(!!(x), 1)
> > +#else
> > +#define likely(x)	(x)
> 
> This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), and likely() must return Boolean (0 or 1).

yes, you're right. will fix.

> 
> > +#endif
> >  #endif /* likely */
> > 
> >  /**
> > @@ -39,7 +43,11 @@
> >   *
> >   */
> >  #ifndef unlikely
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define unlikely(x)	__builtin_expect(!!(x), 0)
> > +#else
> > +#define unlikely(x)	(x)
> 
> This must also be (!!(x)), for the same reason as above.

ack

> 
> > +#endif
> >  #endif /* unlikely */
> > 
> >  #ifdef __cplusplus
> > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > index 2f464e3..1bdaa2d 100644
> > --- a/lib/eal/include/rte_common.h
> > +++ b/lib/eal/include/rte_common.h
> > @@ -65,7 +65,11 @@
> >  /**
> >   * Force alignment
> >   */
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > +#else
> > +#define __rte_aligned(a)
> > +#endif
> 
> It should be reviewed that __rte_aligned() is only used for optimization purposes, and is not required for DPDK to function properly.

so to expand on what i have in mind (and explain why i leave it expanded
empty for now)

while msvc has a __declspec for align there is a mismatch between
where gcc and msvc want it placed to control alignment of objects.

msvc support won't be functional in 23.07 because of atomics. so once
we reach the 23.11 cycle (where we can merge c11 changes) it means we
can also use standard _Alignas which can accomplish the same thing
but portably.

full disclosure the catch is i still have to properly locate the <thing>
that does the alignment and some small questions about the expansion and
use of the existing macro.

on the subject of DPDK requiring proper alignment, you're right it
is generally for performance but also for pre-c11 atomics.

one question i have been asking myself is would the community see value
in more compile time assertions / testing of the size and alignment of
structures and offset of structure fields? we have a few key
RTE_BUILD_BUG_ON() assertions but i've discovered they don't offer
comprehensive protection.

> 
> > 
> >  #ifdef RTE_ARCH_STRICT_ALIGN
> >  typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> > @@ -80,16 +84,29 @@
> >  /**
> >   * Force a structure to be packed
> >   */
> > +#ifndef RTE_TOOLCHAIN_MSVC
> >  #define __rte_packed __attribute__((__packed__))
> > +#else
> > +#define __rte_packed
> > +#endif
> 
> Similar comment as for __rte_aligned(); however, I consider it more likely that structure packing is a functional requirement, and not just used for optimization. Based on my experience, it may be used for packing network structures; perhaps not in DPDK itself but maybe in DPDK applications.

so interestingly i've discovered this is kind of a mess and as you note
some places we can't just "fix" it for abi compatibility reasons.

in some instances the packing is being applied to structures where it is
essentially a noop. i.e. natural alignment gets you the same thing so it
is superfluous.

in some instances the packing is being applied to structures that are
private and it appears to be completely unnecessary e.g. some structure
that isn't nested into something else and sizeof() or offsetof() fields
don't matter in the context of their use.

in some instances it is completely necessary usually when type punning
buffers containing network framing etc...

unfortunately the standard doesn't offer me an out here as there is an
issue of placement of the pragma/attributes that do the packing.

for places it isn't needed it, whatever i just expand empty. for places
it is superfluous again because msvc has no stable abi (we're not
established yet) again i just expand empty. finally for the places where
it is needed i'll probably need to expand conditionally but i think the
instances are far fewer than current use.

> 
> The same risk applies to __rte_aligned(), but with lower probability.

so that's the long winded story of why they are both expanded empty for
now for msvc. but when the time comes i want to submit patch series that
focus on each specifically to generate robust discussion.

ty

RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 14 April 2023 19.02
> 
> On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Thursday, 13 April 2023 23.26
> > >
> > > For now expand a lot of common rte macros empty. The catch here is
> we
> > > need to test that most of the macros do what they should but at the
> same
> > > time they are blocking work needed to bootstrap of the unit tests.
> > >
> > > Later we will return and provide (where possible) expansions that
> work
> > > correctly for msvc and where not possible provide some alternate
> macros
> > > to achieve the same outcome.
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

[...]

> > >  /**
> > >   * Force alignment
> > >   */
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > > +#else
> > > +#define __rte_aligned(a)
> > > +#endif
> >
> > It should be reviewed that __rte_aligned() is only used for
> optimization purposes, and is not required for DPDK to function
> properly.
> 
> so to expand on what i have in mind (and explain why i leave it expanded
> empty for now)
> 
> while msvc has a __declspec for align there is a mismatch between
> where gcc and msvc want it placed to control alignment of objects.
> 
> msvc support won't be functional in 23.07 because of atomics. so once
> we reach the 23.11 cycle (where we can merge c11 changes) it means we
> can also use standard _Alignas which can accomplish the same thing
> but portably.

That (C11 standard _Alignas) should be the roadmap for solving the alignment requirements.

This should be a general principle for DPDK... if the C standard offers something, don't reinvent our own. And as a consequence of the upgrade to C11, we should deprecate all our own now-obsolete substitutes for these.

> 
> full disclosure the catch is i still have to properly locate the <thing>
> that does the alignment and some small questions about the expansion and
> use of the existing macro.
> 
> on the subject of DPDK requiring proper alignment, you're right it
> is generally for performance but also for pre-c11 atomics.
> 
> one question i have been asking myself is would the community see value
> in more compile time assertions / testing of the size and alignment of
> structures and offset of structure fields? we have a few key
> RTE_BUILD_BUG_ON() assertions but i've discovered they don't offer
> comprehensive protection.

Absolutely. Catching bugs at build time is much better than any alternative!

> > >  /**
> > >   * Force a structure to be packed
> > >   */
> > > +#ifndef RTE_TOOLCHAIN_MSVC
> > >  #define __rte_packed __attribute__((__packed__))
> > > +#else
> > > +#define __rte_packed
> > > +#endif
> >
> > Similar comment as for __rte_aligned(); however, I consider it more
> likely that structure packing is a functional requirement, and not just
> used for optimization. Based on my experience, it may be used for
> packing network structures; perhaps not in DPDK itself but maybe in DPDK
> applications.
> 
> so interestingly i've discovered this is kind of a mess and as you note
> some places we can't just "fix" it for abi compatibility reasons.
> 
> in some instances the packing is being applied to structures where it is
> essentially a noop. i.e. natural alignment gets you the same thing so it
> is superfluous.
> 
> in some instances the packing is being applied to structures that are
> private and it appears to be completely unnecessary e.g. some structure
> that isn't nested into something else and sizeof() or offsetof() fields
> don't matter in the context of their use.
> 
> in some instances it is completely necessary usually when type punning
> buffers containing network framing etc...
> 
> unfortunately the standard doesn't offer me an out here as there is an
> issue of placement of the pragma/attributes that do the packing.
> 
> for places it isn't needed it, whatever i just expand empty. for places
> it is superfluous again because msvc has no stable abi (we're not
> established yet) again i just expand empty. finally for the places where
> it is needed i'll probably need to expand conditionally but i think the
> instances are far fewer than current use.

Optimally, we will have a common macro (or other solution) to support both GCC/CLANG and MSVC to replace or supplement __rte_packed. However, the cost of this may be an API break if we replace __rte_packed.

> 
> >
> > The same risk applies to __rte_aligned(), but with lower probability.
> 
> so that's the long winded story of why they are both expanded empty for
> now for msvc. but when the time comes i want to submit patch series that
> focus on each specifically to generate robust discussion.

Sounds like the right path to take.

Now, I'm thinking ahead here...

We should be prepared to accept a major ABI/API break at one point in time, to replace our home-grown macros with C11 standard solutions and to fully support MSVC. This is not happening anytime soon, but the Techboard should acknowledge that this is going to happen (with an unspecified release), so it can be formally announced. The sooner it is announced, the more time developers will have to prepare for it.

All the details do not need to be known at the time of the announcement; they can be added along the way, based on the discussions from your future patches.

> 
> ty

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

On Sat, Apr 15, 2023 at 09:16:21AM +0200, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Friday, 14 April 2023 19.02
> > 
> > On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > Sent: Thursday, 13 April 2023 23.26
> > > >
> > > > For now expand a lot of common rte macros empty. The catch here is
> > we
> > > > need to test that most of the macros do what they should but at the
> > same
> > > > time they are blocking work needed to bootstrap of the unit tests.
> > > >
> > > > Later we will return and provide (where possible) expansions that
> > work
> > > > correctly for msvc and where not possible provide some alternate
> > macros
> > > > to achieve the same outcome.
> > > >
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> 
> [...]
> 
> > > >  /**
> > > >   * Force alignment
> > > >   */
> > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > > > +#else
> > > > +#define __rte_aligned(a)
> > > > +#endif
> > >
> > > It should be reviewed that __rte_aligned() is only used for
> > optimization purposes, and is not required for DPDK to function
> > properly.
> > 
> > so to expand on what i have in mind (and explain why i leave it expanded
> > empty for now)
> > 
> > while msvc has a __declspec for align there is a mismatch between
> > where gcc and msvc want it placed to control alignment of objects.
> > 
> > msvc support won't be functional in 23.07 because of atomics. so once
> > we reach the 23.11 cycle (where we can merge c11 changes) it means we
> > can also use standard _Alignas which can accomplish the same thing
> > but portably.
> 
> That (C11 standard _Alignas) should be the roadmap for solving the alignment requirements.
> 
> This should be a general principle for DPDK... if the C standard offers something, don't reinvent our own. And as a consequence of the upgrade to C11, we should deprecate all our own now-obsolete substitutes for these.
> 
> > 
> > full disclosure the catch is i still have to properly locate the <thing>
> > that does the alignment and some small questions about the expansion and
> > use of the existing macro.
> > 
> > on the subject of DPDK requiring proper alignment, you're right it
> > is generally for performance but also for pre-c11 atomics.
> > 
> > one question i have been asking myself is would the community see value
> > in more compile time assertions / testing of the size and alignment of
> > structures and offset of structure fields? we have a few key
> > RTE_BUILD_BUG_ON() assertions but i've discovered they don't offer
> > comprehensive protection.
> 
> Absolutely. Catching bugs at build time is much better than any alternative!

that's handy feedback. i am now encouraged to include more compile time
checks in advance of or along with changes related to structure abi.
follow on question, once we do get to use c11 would something like
_Static_assert be preferable over RTE_BUILD_BUG_ON? structures sensitive
to layout could be co-located with the asserts right at the point of
definition. or is there something extra RTE_BUILD_BUG_ON gives us?

> 
> > > >  /**
> > > >   * Force a structure to be packed
> > > >   */
> > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > >  #define __rte_packed __attribute__((__packed__))
> > > > +#else
> > > > +#define __rte_packed
> > > > +#endif
> > >
> > > Similar comment as for __rte_aligned(); however, I consider it more
> > likely that structure packing is a functional requirement, and not just
> > used for optimization. Based on my experience, it may be used for
> > packing network structures; perhaps not in DPDK itself but maybe in DPDK
> > applications.
> > 
> > so interestingly i've discovered this is kind of a mess and as you note
> > some places we can't just "fix" it for abi compatibility reasons.
> > 
> > in some instances the packing is being applied to structures where it is
> > essentially a noop. i.e. natural alignment gets you the same thing so it
> > is superfluous.
> > 
> > in some instances the packing is being applied to structures that are
> > private and it appears to be completely unnecessary e.g. some structure
> > that isn't nested into something else and sizeof() or offsetof() fields
> > don't matter in the context of their use.
> > 
> > in some instances it is completely necessary usually when type punning
> > buffers containing network framing etc...
> > 
> > unfortunately the standard doesn't offer me an out here as there is an
> > issue of placement of the pragma/attributes that do the packing.
> > 
> > for places it isn't needed it, whatever i just expand empty. for places
> > it is superfluous again because msvc has no stable abi (we're not
> > established yet) again i just expand empty. finally for the places where
> > it is needed i'll probably need to expand conditionally but i think the
> > instances are far fewer than current use.
> 
> Optimally, we will have a common macro (or other solution) to support both GCC/CLANG and MSVC to replace or supplement __rte_packed. However, the cost of this may be an API break if we replace __rte_packed.
> 
> > 
> > >
> > > The same risk applies to __rte_aligned(), but with lower probability.
> > 
> > so that's the long winded story of why they are both expanded empty for
> > now for msvc. but when the time comes i want to submit patch series that
> > focus on each specifically to generate robust discussion.
> 
> Sounds like the right path to take.
> 
> Now, I'm thinking ahead here...
> 
> We should be prepared to accept a major ABI/API break at one point in time, to replace our home-grown macros with C11 standard solutions and to fully support MSVC. This is not happening anytime soon, but the Techboard should acknowledge that this is going to happen (with an unspecified release), so it can be formally announced. The sooner it is announced, the more time developers will have to prepare for it.

so, just to avoid any confusion i want to make it clear that i am not
planning to submit changes that would change abi as a part of supporting
msvc (aside from changing to standard atomics which we agreed on).

in general there are some cleanups we could make in the area of code
maintainability and portability and we may want to discuss the
advantages or disadvantages of making those changes. but i think those
changes are a topic unrelated to windows or msvc specifically.

> 
> All the details do not need to be known at the time of the announcement; they can be added along the way, based on the discussions from your future patches.

> 
> > 
> > ty

RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Saturday, 15 April 2023 22.52
> 
> On Sat, Apr 15, 2023 at 09:16:21AM +0200, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Friday, 14 April 2023 19.02
> > >
> > > On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote:
> > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > > Sent: Thursday, 13 April 2023 23.26
> > > > >
> > > > > For now expand a lot of common rte macros empty. The catch here
> is
> > > we
> > > > > need to test that most of the macros do what they should but at
> the
> > > same
> > > > > time they are blocking work needed to bootstrap of the unit
> tests.
> > > > >
> > > > > Later we will return and provide (where possible) expansions
> that
> > > work
> > > > > correctly for msvc and where not possible provide some alternate
> > > macros
> > > > > to achieve the same outcome.
> > > > >
> > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >
> > [...]
> >
> > > > >  /**
> > > > >   * Force alignment
> > > > >   */
> > > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > > >  #define __rte_aligned(a) __attribute__((__aligned__(a)))
> > > > > +#else
> > > > > +#define __rte_aligned(a)
> > > > > +#endif
> > > >
> > > > It should be reviewed that __rte_aligned() is only used for
> > > optimization purposes, and is not required for DPDK to function
> > > properly.
> > >
> > > so to expand on what i have in mind (and explain why i leave it
> expanded
> > > empty for now)
> > >
> > > while msvc has a __declspec for align there is a mismatch between
> > > where gcc and msvc want it placed to control alignment of objects.
> > >
> > > msvc support won't be functional in 23.07 because of atomics. so
> once
> > > we reach the 23.11 cycle (where we can merge c11 changes) it means
> we
> > > can also use standard _Alignas which can accomplish the same thing
> > > but portably.
> >
> > That (C11 standard _Alignas) should be the roadmap for solving the
> alignment requirements.
> >
> > This should be a general principle for DPDK... if the C standard
> offers something, don't reinvent our own. And as a consequence of the
> upgrade to C11, we should deprecate all our own now-obsolete substitutes
> for these.
> >
> > >
> > > full disclosure the catch is i still have to properly locate the
> <thing>
> > > that does the alignment and some small questions about the expansion
> and
> > > use of the existing macro.
> > >
> > > on the subject of DPDK requiring proper alignment, you're right it
> > > is generally for performance but also for pre-c11 atomics.
> > >
> > > one question i have been asking myself is would the community see
> value
> > > in more compile time assertions / testing of the size and alignment
> of
> > > structures and offset of structure fields? we have a few key
> > > RTE_BUILD_BUG_ON() assertions but i've discovered they don't offer
> > > comprehensive protection.
> >
> > Absolutely. Catching bugs at build time is much better than any
> alternative!
> 
> that's handy feedback. i am now encouraged to include more compile time
> checks in advance of or along with changes related to structure abi.

Sounds good.

Disclaimer: "Absolutely" was my personal response. But I seriously doubt that anyone in the DPDK community would object to more build time checks. Stability and code quality carries a lot of weight in DPDK community discussions.

With that said, please expect that maintainers might want you to split your patches, so the additional checks are separated from the MSVC changes.

> follow on question, once we do get to use c11 would something like
> _Static_assert be preferable over RTE_BUILD_BUG_ON? structures sensitive
> to layout could be co-located with the asserts right at the point of
> definition. or is there something extra RTE_BUILD_BUG_ON gives us?

People may have different opinions on RTE_BUILD_BUG_ON vs. _Static_assert or static_assert.

Personally, I prefer static_assert/_Static_assert. It also has the advantage that it can be used in the global scope, directly following the structure definitions (like you mention), whereas RTE_BUILD_BUG_ON must be inside a code block (which can probably be worked around by making a dummy static inline function only containing the RTE_BUILD_BUG_ON).

And in the spirit of my proposal of not using home-grown macros as alternatives to what the C standard provides, I think we should deprecate and get rid of RTE_BUILD_BUG_ON in favor of static_assert/_Static_assert introduced by the C11 standard. (My personal opinion, no such principle decision has been made!)

If we want to keep RTE_BUILD_BUG_ON for some reason, we could change its implementation to use static_assert/_Static_assert instead of creating an invalid pointer to make the compilation fail.

> 
> >
> > > > >  /**
> > > > >   * Force a structure to be packed
> > > > >   */
> > > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > > >  #define __rte_packed __attribute__((__packed__))
> > > > > +#else
> > > > > +#define __rte_packed
> > > > > +#endif
> > > >
> > > > Similar comment as for __rte_aligned(); however, I consider it
> more
> > > likely that structure packing is a functional requirement, and not
> just
> > > used for optimization. Based on my experience, it may be used for
> > > packing network structures; perhaps not in DPDK itself but maybe in
> DPDK
> > > applications.
> > >
> > > so interestingly i've discovered this is kind of a mess and as you
> note
> > > some places we can't just "fix" it for abi compatibility reasons.
> > >
> > > in some instances the packing is being applied to structures where
> it is
> > > essentially a noop. i.e. natural alignment gets you the same thing
> so it
> > > is superfluous.
> > >
> > > in some instances the packing is being applied to structures that
> are
> > > private and it appears to be completely unnecessary e.g. some
> structure
> > > that isn't nested into something else and sizeof() or offsetof()
> fields
> > > don't matter in the context of their use.
> > >
> > > in some instances it is completely necessary usually when type
> punning
> > > buffers containing network framing etc...
> > >
> > > unfortunately the standard doesn't offer me an out here as there is
> an
> > > issue of placement of the pragma/attributes that do the packing.
> > >
> > > for places it isn't needed it, whatever i just expand empty. for
> places
> > > it is superfluous again because msvc has no stable abi (we're not
> > > established yet) again i just expand empty. finally for the places
> where
> > > it is needed i'll probably need to expand conditionally but i think
> the
> > > instances are far fewer than current use.
> >
> > Optimally, we will have a common macro (or other solution) to support
> both GCC/CLANG and MSVC to replace or supplement __rte_packed. However,
> the cost of this may be an API break if we replace __rte_packed.
> >
> > >
> > > >
> > > > The same risk applies to __rte_aligned(), but with lower
> probability.
> > >
> > > so that's the long winded story of why they are both expanded empty
> for
> > > now for msvc. but when the time comes i want to submit patch series
> that
> > > focus on each specifically to generate robust discussion.
> >
> > Sounds like the right path to take.
> >
> > Now, I'm thinking ahead here...
> >
> > We should be prepared to accept a major ABI/API break at one point in
> time, to replace our home-grown macros with C11 standard solutions and
> to fully support MSVC. This is not happening anytime soon, but the
> Techboard should acknowledge that this is going to happen (with an
> unspecified release), so it can be formally announced. The sooner it is
> announced, the more time developers will have to prepare for it.
> 
> so, just to avoid any confusion i want to make it clear that i am not
> planning to submit changes that would change abi as a part of supporting
> msvc (aside from changing to standard atomics which we agreed on).

Thank you for clarifying.

> 
> in general there are some cleanups we could make in the area of code
> maintainability and portability and we may want to discuss the
> advantages or disadvantages of making those changes. but i think those
> changes are a topic unrelated to windows or msvc specifically.

This was the point I was trying to make, when I proposed accepting a major ABI/API break. Sorry about my unclear wording.

If we collect a wish list of breaking changes, I would personally prefer a "big bang" major ABI/API break, rather than a series of incremental API/ABI breaks over multiple DPDK release. In this regard, we could mix both changes driven by the migration to pure C11 (e.g. getting rid of now-obsolete macros, such as RTE_BUILD_BUG_ON, and compiler intrinsics, such as __rte_aligned) and MSVC portability changes (e.g. an improved macro to support structure packing).

> 
> >
> > All the details do not need to be known at the time of the
> announcement; they can be added along the way, based on the discussions
> from your future patches.
> 
> >
> > >
> > > ty

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Stephen Hemminger]

On Sun, 16 Apr 2023 00:41:54 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > > > > >  /**
> > > > > >   * Force a structure to be packed
> > > > > >   */
> > > > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > > > >  #define __rte_packed __attribute__((__packed__))
> > > > > > +#else
> > > > > > +#define __rte_packed
> > > > > > +#endif  

Could there be cases this gets used for protocol headers or interacting with
HW memory map, And if not packed then the code will not function correctly?

Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

On Sat, Apr 15, 2023 at 03:52:27PM -0700, Stephen Hemminger wrote:
> On Sun, 16 Apr 2023 00:41:54 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > > > > >  /**
> > > > > > >   * Force a structure to be packed
> > > > > > >   */
> > > > > > > +#ifndef RTE_TOOLCHAIN_MSVC
> > > > > > >  #define __rte_packed __attribute__((__packed__))
> > > > > > > +#else
> > > > > > > +#define __rte_packed
> > > > > > > +#endif  
> 
> Could there be cases this gets used for protocol headers or interacting with
> HW memory map, And if not packed then the code will not function correctly?

yes, that's one of the valid / correct use cases and it can't be avoided
if the structs are nested in recursively composed layout.

there are a few instances where we don't need compiler generated
static-stride. that is we don't need to force packing to get sizeof(T)
== offsetof(T.lastfield) + sizeof(T.lastfield).

anyway, this is more of an evaluate on a case by case basis for
candidates that aren't needed.

ty

[PATCH v5 12/14] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v5 13/14] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v5 14/14] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v6 00/15] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (15):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: typedef cpu flag enum as int
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++
 lib/eal/include/generic/rte_cpuflags.h  | 12 ++++---
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 60 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 +++-------
 lib/eal/x86/rte_cpuflags.c              |  4 +++
 lib/eal/x86/rte_cpuid.h                 |  7 ++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++
 lib/telemetry/telemetry_data.c          | 16 +++++++++
 19 files changed, 254 insertions(+), 28 deletions(-)

-- 
1.8.3.1

[PATCH v6 01/15] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include <x86intrin.h>
+#else
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v6 02/15] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v6 03/15] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v6 04/15] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v6 05/15] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#else
+	_umonitor(pmc->addr);
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#else
+	_umwait(tsc_l, tsc_h);
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#else
+	_tpause(tsc_l, tsc_h);
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v6 06/15] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+	_mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v6 07/15] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v6 08/15] eal: typedef cpu flag enum as int

[Tyler Retzlaff]

Forward declaration of a enum is a non-standard extension and is not
supported by MSVC. Use an int instead.

Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.

Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_cpuflags.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
 /**
  * Enumeration of all CPU features supported
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 __extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
 
 /**
  * Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
  *     flag name
  *     NULL if flag ID is invalid
  */
-__extension__
 const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
 
 /**
  * Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
  *     0 if flag is not available
  *     -ENOENT if flag is invalid
  */
-__extension__
 int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
 
 /**
  * This function checks that the currently used CPU supports the CPU features
-- 
1.8.3.1

[PATCH v6 09/15] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v6 10/15] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v6 11/15] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..1eff9f6 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(!!(x))
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(!!(x))
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..5417f68 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -62,10 +62,18 @@
 		__GNUC_PATCHLEVEL__)
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_packed __attribute__((__packed__))
+#else
+#define __rte_packed
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +178,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,12 +861,17 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifndef RTE_TOOLCHAIN_MSVC
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
 				(type *)(ptr);				\
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
+#else
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#endif
 #endif
 
 /** Swap two variables. */
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v6 12/15] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v6 13/15] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v6 14/15] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v6 15/15] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 5417f68..fffb0fa 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

RE: [PATCH v6 00/15] msvc integration changes

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Saturday, 15 April 2023 03.16
> 
> In accordance with draft plan
> http://mails.dpdk.org/archives/web/2023-February/002023.html
> introduces conditionally compiled code to enable building with MSVC that
> _does not_ require C99/C11 meaning it can be integrated now.
> 
> This series covers minimal changes for item #2 in draft plan for EAL
> dependencies kvargs, telemetry and consumed EAL public headers.
> 
> Note if any patch in the series requires in-depth discussion I'll
> detach it from this series for separate submission & more focused
> discussion so it doesn't block the entire series.
> 
> Note other "common" intrinsics were investigated for viability but
> were not adopted either because they were not available on older
> versions of gcc or because they generate different code for msvc
> vs gcc.

Series-acked-by: Morten Brørup <mb@smartsharesystems.com>

[PATCH v7 00/14] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v7:
  * remove patch typedef of rte_cpuflags_t as an int. for now we
    will just allow warning to be emitted to avoid adding conditional
    compilation

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 60 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 +++-------
 lib/eal/x86/rte_cpuflags.c              |  4 +++
 lib/eal/x86/rte_cpuid.h                 |  7 ++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++
 lib/telemetry/telemetry_data.c          | 16 +++++++++
 18 files changed, 247 insertions(+), 23 deletions(-)

-- 
1.8.3.1

[PATCH v7 01/14] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include <x86intrin.h>
+#else
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v7 02/14] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v7 03/14] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v7 04/14] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v7 05/14] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#else
+	_umonitor(pmc->addr);
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#else
+	_umwait(tsc_l, tsc_h);
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#else
+	_tpause(tsc_l, tsc_h);
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

Re: [PATCH v7 05/14] eal: use umonitor umwait and tpause intrinsics

[Konstantin Ananyev]

> Inline assembly is not supported for MSVC x64 instead use _umonitor,
> _umwait and _tpause intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
> index f749da9..7d83c24 100644
> --- a/lib/eal/x86/rte_power_intrinsics.c
> +++ b/lib/eal/x86/rte_power_intrinsics.c
> @@ -109,9 +109,13 @@
>  	 */
>  
>  	/* set address for UMONITOR */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
>  			:
>  			: "D"(pmc->addr));
> +#else
> +	_umonitor(pmc->addr);
> +#endif
>  
>  	/* now that we've put this address into monitor, we can unlock */
>  	rte_spinlock_unlock(&s->lock);
> @@ -123,10 +127,14 @@
>  		goto end;
>  
>  	/* execute UMWAIT */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
>  			: /* ignore rflags */
>  			: "D"(0), /* enter C0.2 */
>  			  "a"(tsc_l), "d"(tsc_h));
> +#else
> +	_umwait(tsc_l, tsc_h);
> +#endif
>  
>  end:
>  	/* erase sleep address */
> @@ -153,10 +161,14 @@
>  		return -ENOTSUP;
>  
>  	/* execute TPAUSE */
> +#ifndef RTE_TOOLCHAIN_MSVC
>  	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
>  			: /* ignore rflags */
>  			: "D"(0), /* enter C0.2 */
>  			"a"(tsc_l), "d"(tsc_h));
> +#else
> +	_tpause(tsc_l, tsc_h);
> +#endif
>  
>  	return 0;
>  }
> -- 
> 1.8.3.1

AFAIK, with GCC (and CLANG?) these instrincts are controlled
by __WAITPKG__ macro.
So might be it is possible to have sort of 'unite' code:
#if defined (RTE_TOOLCHAIN_MSVC) || defined (__WAITPKG__)
	<use insrinct>
#else
	<use inline asm>
#endif
Apart from that, LGTM
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>

[PATCH v7 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+	_mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

Re: [PATCH v7 06/14] eal: use prefetch intrinsics

[Konstantin Ananyev]

> nline assembly is not supported for MSVC x64 instead use _mm_prefetch
> and _mm_cldemote intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
> index 7fd01c4..239e611 100644
> --- a/lib/eal/x86/include/rte_prefetch.h
> +++ b/lib/eal/x86/include/rte_prefetch.h
> @@ -9,30 +9,38 @@
>  extern "C" {
>  #endif
>  
> +#include <emmintrin.h>
> +
>  #include <rte_compat.h>
>  #include <rte_common.h>
>  #include "generic/rte_prefetch.h"
>  
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wcast-qual"
> +
>  static inline void rte_prefetch0(const volatile void *p)
>  {
> -	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
> +	_mm_prefetch((const void *)p, _MM_HINT_T0);
>  }
>  
>  static inline void rte_prefetch1(const volatile void *p)
>  {
> -	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
> +	_mm_prefetch((const void *)p, _MM_HINT_T1);
>  }
>  
>  static inline void rte_prefetch2(const volatile void *p)
>  {
> -	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
> +	_mm_prefetch((const void *)p, _MM_HINT_T2);
>  }
>  
>  static inline void rte_prefetch_non_temporal(const volatile void *p)
>  {
> -	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
> +	_mm_prefetch((const void *)p, _MM_HINT_NTA);
>  }
>  
> +#pragma GCC diagnostic pop
> +
> +#ifndef RTE_TOOLCHAIN_MSVC
>  /*
>   * We use raw byte codes for now as only the newest compiler
>   * versions support this instruction natively.
> @@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
>  {
>  	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
>  }
> +#else
> +__rte_experimental
> +static inline void
> +rte_cldemote(const volatile void *p)
> +{
> +	_mm_cldemote(p);
> +}
> +#endif
> +
>  
>  #ifdef __cplusplus
>  }
> -- 

Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>

> 1.8.3.1

[PATCH v7 07/14] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v7 08/14] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v7 09/14] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v7 10/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..1eff9f6 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(!!(x))
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(!!(x))
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..0c55a23 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -41,6 +41,10 @@
 #define RTE_STD_C11
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /*
  * RTE_TOOLCHAIN_GCC is defined if the target is built with GCC,
  * while a host application (like pmdinfogen) may have another compiler.
@@ -65,7 +69,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_packed __attribute__((__packed__))
+#else
+#define __rte_packed
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +178,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,12 +861,17 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifndef RTE_TOOLCHAIN_MSVC
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
 				(type *)(ptr);				\
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
+#else
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#endif
 #endif
 
 /** Swap two variables. */
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v7 11/14] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v7 12/14] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v7 13/14] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v7 14/14] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 0c55a23..ce66287 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

[PATCH v8 00/14] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v8:
  * use waitpkg intrinsics if __WAITPKG__ is defined by the
    compiler

v7:
  * remove patch typedef of rte_cpuflags_t as an int. for now we
    will just allow warning to be emitted to avoid adding conditional
    compilation

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 60 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 +++-------
 lib/eal/x86/rte_cpuflags.c              |  4 +++
 lib/eal/x86/rte_cpuid.h                 |  7 ++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++
 lib/telemetry/telemetry_data.c          | 16 +++++++++
 18 files changed, 247 insertions(+), 23 deletions(-)

-- 
1.8.3.1

[PATCH v8 01/14] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifndef RTE_TOOLCHAIN_MSVC
+#include <x86intrin.h>
+#else
+#include <intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v8 02/14] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v8 03/14] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/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
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,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
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v8 04/14] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_cpuflags.c   |  4 ++++
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 51 insertions(+)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	 __cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#else
+#define bit_AVX (1 << 28)
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
 		__cpuid(0x15, a, b, c, d);
+#else
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(0x1, a, b, c, d);
+#else
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifndef RTE_TOOLCHAIN_MSVC
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v8 05/14] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..4066d13 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umonitor(pmc->addr);
+#else
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umwait(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_tpause(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v8 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+	_mm_cldemote(p);
+}
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v8 07/14] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v8 08/14] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v8 09/14] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v8 10/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 0256a9d..1eff9f6 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -25,7 +25,11 @@
  *
  */
 #ifndef likely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define likely(x)	__builtin_expect(!!(x), 1)
+#else
+#define likely(x)	(!!(x))
+#endif
 #endif /* likely */
 
 /**
@@ -39,7 +43,11 @@
  *
  */
 #ifndef unlikely
+#ifndef RTE_TOOLCHAIN_MSVC
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#else
+#define unlikely(x)	(!!(x))
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..0c55a23 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -41,6 +41,10 @@
 #define RTE_STD_C11
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /*
  * RTE_TOOLCHAIN_GCC is defined if the target is built with GCC,
  * while a host application (like pmdinfogen) may have another compiler.
@@ -65,7 +69,11 @@
 /**
  * Force alignment
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#else
+#define __rte_aligned(a)
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_packed __attribute__((__packed__))
+#else
+#define __rte_packed
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_may_alias __attribute__((__may_alias__))
+#else
+#define __rte_may_alias
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#else
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_used __attribute__((used))
+#else
+#define __rte_used
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_unused __attribute__((__unused__))
+#else
+#define __rte_unused
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,7 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +178,9 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#else
+#define __rte_format_printf(format_index, first_arg)
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_noreturn __attribute__((noreturn))
+#else
+#define __rte_noreturn
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define __rte_warn_unused_result
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_always_inline inline __attribute__((always_inline))
+#else
+#define __rte_always_inline
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#else
+#define __rte_cache_aligned
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,12 +861,17 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifndef RTE_TOOLCHAIN_MSVC
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
 				(type *)(ptr);				\
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
+#else
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#endif
 #endif
 
 /** Swap two variables. */
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..6a4b5ee 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#else
+#define __rte_experimental
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#else
+#define __rte_internal
+#endif
 
 #else
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#else
+#define __rte_internal
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v8 11/14] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v8 12/14] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v8 13/14] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v8 14/14] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 0c55a23..ce66287 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

[PATCH v9 00/14] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v9:
  * invert macro conditional evaluation and use to be
    #ifdef RTE_TOOLCHAIN_MSVC instead of #ifndef RTE_TOOLCHAIN_MSVC
    wherever it doesn't make evaluation more complex than
    it already is

v8:
  * use waitpkg intrinsics if __WAITPKG__ is defined by the
    compiler

v7:
  * remove patch typedef of rte_cpuflags_t as an int. for now we
    will just allow warning to be emitted to avoid adding conditional
    compilation

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64


Tyler Retzlaff (14):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  telemetry: avoid expanding versioned symbol macros on MSVC
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 60 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 +++-------
 lib/eal/x86/rte_cpuflags.c              |  6 +++-
 lib/eal/x86/rte_cpuid.h                 |  7 ++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++
 lib/telemetry/telemetry_data.c          | 16 +++++++++
 18 files changed, 248 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v9 01/14] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..ca0fb10 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#else
+#include <x86intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v9 02/14] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v9 03/14] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index 58df843..6a6c394 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.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define rte_compiler_barrier() _ReadWriteBarrier()
+#else
 #define	rte_compiler_barrier() do {		\
 	asm volatile ("" : : : "memory");	\
 } while(0)
+#endif
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..7aba1c3 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,15 @@
 static __rte_always_inline void
 rte_smp_mb(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	_mm_mfence();
+#else
 #ifdef RTE_ARCH_I686
 	asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
 #else
 	asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
 #endif
+#endif
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v9 04/14] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_cpuflags.c   |  6 +++++-
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..8a30f79 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
-	 __cpuid_count(feat->leaf, feat->subleaf,
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#else
+	__cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..69ed59b 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifdef RTE_TOOLCHAIN_MSVC
+#define bit_AVX (1 << 28)
+#else
 #include <cpuid.h>
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifdef RTE_TOOLCHAIN_MSVC
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#else
 		__cpuid(0x15, a, b, c, d);
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#else
 	__cpuid(0x1, a, b, c, d);
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..04fe767 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#else
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v9 05/14] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..4066d13 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umonitor(pmc->addr);
+#else
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umwait(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_tpause(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v9 06/14] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..7a6988e 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifdef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -41,8 +49,17 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 static inline void
 rte_cldemote(const volatile void *p)
 {
+	_mm_cldemote(p);
+}
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v9 07/14] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v9 08/14] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v9 09/14] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v9 10/14] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 414cd92..c0356ca 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -24,7 +24,11 @@
  *      do_stuff();
  */
 #ifndef likely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define likely(x)	(!!(x))
+#else
 #define likely(x)	__builtin_expect(!!(x), 1)
+#endif
 #endif /* likely */
 
 /**
@@ -37,7 +41,11 @@
  *      do_stuff();
  */
 #ifndef unlikely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define unlikely(x)	(!!(x))
+#else
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..b087532 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -41,6 +41,10 @@
 #define RTE_STD_C11
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /*
  * RTE_TOOLCHAIN_GCC is defined if the target is built with GCC,
  * while a host application (like pmdinfogen) may have another compiler.
@@ -65,7 +69,11 @@
 /**
  * Force alignment
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_aligned(a)
+#else
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_packed
+#else
 #define __rte_packed __attribute__((__packed__))
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_may_alias
+#else
 #define __rte_may_alias __attribute__((__may_alias__))
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#else
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_used
+#else
 #define __rte_used __attribute__((used))
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_unused
+#else
 #define __rte_unused __attribute__((__unused__))
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,9 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_format_printf(format_index, first_arg)
+#else
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +180,7 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_noreturn
+#else
 #define __rte_noreturn __attribute__((noreturn))
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_warn_unused_result
+#else
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_always_inline
+#else
 #define __rte_always_inline inline __attribute__((always_inline))
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_cache_aligned
+#else
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,6 +861,10 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifdef RTE_TOOLCHAIN_MSVC
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#else
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
@@ -819,6 +872,7 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
 #endif
+#endif
 
 /** Swap two variables. */
 #define RTE_SWAP(a, b) \
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..716bc03 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v9 11/14] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index 6a6c394..0112208 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 7aba1c3..9ba61f8 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v9 12/14] telemetry: avoid expanding versioned symbol macros on MSVC

[Tyler Retzlaff]

Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.

Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.

Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/telemetry/telemetry_data.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 0c7187b..523287b 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -83,8 +83,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+#else
 MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
 		int64_t x), rte_tel_data_add_array_int_v24);
+#endif
 
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -218,8 +226,16 @@
 /* mark the v23 function as the older version, and v24 as the default version */
 VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
 BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#else
 MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
 		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#endif
 
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
-- 
1.8.3.1

[PATCH v9 13/14] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v9 14/14] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index b087532..cf7d8d8 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

[PATCH v10 00/13] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.

v10:
  * rebase series post 23.07 release. no changes except
    telemetry: avoid expanding versioned symbol macros on MSVC
    has been dropped from the series as 23.11 has removed the
    versioned symbols

v9:
  * invert macro conditional evaluation and use to be
    #ifdef RTE_TOOLCHAIN_MSVC instead of #ifndef RTE_TOOLCHAIN_MSVC
    wherever it doesn't make evaluation more complex than
    it already is

v8:
  * use waitpkg intrinsics if __WAITPKG__ is defined by the
    compiler

v7:
  * remove patch typedef of rte_cpuflags_t as an int. for now we
    will just allow warning to be emitted to avoid adding conditional
    compilation

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64


Tyler Retzlaff (13):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC

 config/x86/meson.build                  |  6 ++++
 lib/eal/include/generic/rte_atomic.h    | 11 ++++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++++
 lib/eal/include/generic/rte_vect.h      |  4 +++
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 60 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++++
 lib/eal/x86/include/rte_byteorder.h     |  4 +++
 lib/eal/x86/include/rte_cycles.h        | 14 ++++----
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++++++---
 lib/eal/x86/include/rte_rtm.h           | 18 +++-------
 lib/eal/x86/rte_cpuflags.c              |  6 +++-
 lib/eal/x86/rte_cpuid.h                 |  7 ++++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 +++
 lib/eal/x86/rte_power_intrinsics.c      | 12 +++++++
 17 files changed, 232 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v10 01/13] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..ca0fb10 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#else
+#include <x86intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

[PATCH v10 02/13] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v10 03/13] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index aef44e2..2d36eb0 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -146,9 +146,13 @@
  * Guarantees that operation reordering does not occur at compile time
  * for operations directly before and after the barrier.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define rte_compiler_barrier() _ReadWriteBarrier()
+#else
 #define	rte_compiler_barrier() do {		\
 	asm volatile ("" : : : "memory");	\
 } while(0)
+#endif
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..7aba1c3 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,15 @@
 static __rte_always_inline void
 rte_smp_mb(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	_mm_mfence();
+#else
 #ifdef RTE_ARCH_I686
 	asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
 #else
 	asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
 #endif
+#endif
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v10 04/13] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_cpuflags.c   |  6 +++++-
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..8a30f79 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
-	 __cpuid_count(feat->leaf, feat->subleaf,
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#else
+	__cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..69ed59b 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifdef RTE_TOOLCHAIN_MSVC
+#define bit_AVX (1 << 28)
+#else
 #include <cpuid.h>
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifdef RTE_TOOLCHAIN_MSVC
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#else
 		__cpuid(0x15, a, b, c, d);
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#else
 	__cpuid(0x1, a, b, c, d);
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..04fe767 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#else
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v10 05/13] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..4066d13 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umonitor(pmc->addr);
+#else
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umwait(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_tpause(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

[PATCH v10 06/13] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..7a6988e 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifdef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -41,8 +49,17 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 static inline void
 rte_cldemote(const volatile void *p)
 {
+	_mm_cldemote(p);
+}
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v10 07/13] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

[PATCH v10 08/13] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v10 09/13] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v10 10/13] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 414cd92..c0356ca 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -24,7 +24,11 @@
  *      do_stuff();
  */
 #ifndef likely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define likely(x)	(!!(x))
+#else
 #define likely(x)	__builtin_expect(!!(x), 1)
+#endif
 #endif /* likely */
 
 /**
@@ -37,7 +41,11 @@
  *      do_stuff();
  */
 #ifndef unlikely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define unlikely(x)	(!!(x))
+#else
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..b087532 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -41,6 +41,10 @@
 #define RTE_STD_C11
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /*
  * RTE_TOOLCHAIN_GCC is defined if the target is built with GCC,
  * while a host application (like pmdinfogen) may have another compiler.
@@ -65,7 +69,11 @@
 /**
  * Force alignment
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_aligned(a)
+#else
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_packed
+#else
 #define __rte_packed __attribute__((__packed__))
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_may_alias
+#else
 #define __rte_may_alias __attribute__((__may_alias__))
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#else
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_used
+#else
 #define __rte_used __attribute__((used))
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_unused
+#else
 #define __rte_unused __attribute__((__unused__))
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,9 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_format_printf(format_index, first_arg)
+#else
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +180,7 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_noreturn
+#else
 #define __rte_noreturn __attribute__((noreturn))
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_warn_unused_result
+#else
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_always_inline
+#else
 #define __rte_always_inline inline __attribute__((always_inline))
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_cache_aligned
+#else
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,6 +861,10 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifdef RTE_TOOLCHAIN_MSVC
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#else
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
@@ -819,6 +872,7 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
 #endif
+#endif
 
 /** Swap two variables. */
 #define RTE_SWAP(a, b) \
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..716bc03 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v10 11/13] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index 2d36eb0..b14e9fe 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -161,6 +161,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1068,8 +1070,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1079,8 +1084,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 7aba1c3..9ba61f8 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v10 12/13] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v10 13/13] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index b087532..cf7d8d8 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

[PATCH v11 00/16] msvc integration changes

[Tyler Retzlaff]

In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.

This series covers minimal changes for item #2 in draft plan for EAL
dependencies log, kvargs, telemetry and consumed EAL public headers.

Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.

Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of GCC or because they generate different code for msvc
vs GCC.

v11:
  * rebase for log lib split: introduces 2 patches to convert to
    portable use of ternary operator
  * rebase for log lib split: introduce MSVC versions of
    RTE_INIT_PRIO and RTE_FINI_PRIO since it is needed by log

v10:
  * rebase series post 23.07 release. no changes except
    telemetry: avoid expanding versioned symbol macros on MSVC
    has been dropped from the series as 23.11 has removed the
    versioned symbols

v9:
  * invert macro conditional evaluation and use to be
    #ifdef RTE_TOOLCHAIN_MSVC instead of #ifndef RTE_TOOLCHAIN_MSVC
    wherever it doesn't make evaluation more complex than
    it already is

v8:
  * use waitpkg intrinsics if __WAITPKG__ is defined by the
    compiler

v7:
  * remove patch typedef of rte_cpuflags_t as an int. for now we
    will just allow warning to be emitted to avoid adding conditional
    compilation

v6:
  * convert / expand likely/unlikely macros to _Bool type
  * expand __extension__ empty it's cleaner to do this for now
    instead of modifying the whole tree
  * provide msvc container_of not based on gcc expression
    statement extension
  * add patch that stops defining typeof (C23 keyword) when
    building with msvc

v5:
  * remove accidental line removal in barrier patch
  * update prefetch patch to use intrinsics for all toolchains
  * remove x86 specific changes for byte swap patch since
    msvc intrinsics are processor agnostic always use
    intrinsics from generic include
  * expand __rte_packed empty for msvc packing will be addressed
    in a separate series

v4:
  * update rdtsc patch to use gcc intrinsics
  * update rtm patch to use gcc intrinsics
  * drop patch disable json print formatting, we will utilize
    series removing VLAs from Bruce
  * added patch using prefetch intrinsics for msvc
  * added patch using byte swap intrinsics for msvc
  * added patch hiding typdefs for msvc using gcc vector
    extension
  * added patch defining MSVC as little endian always

v3:
  * v3 does not group together conditional blocks when experimented
    with it didn't reduce conditionals enough to make it worth
    while. once msvc tests are at a running point i suggest
    a narrow targeted discussion about code organization without
    blocking this series
  * v3 does not attempt to refactor to use intrinsics for non-msvc
    compilers. again this should be done as a separate follow-up
    series later if desired
  * fix expansion of likely and unlikely macros
  * remove unnecessary define for rte_smp_{r,w}mb it is sufficient
    for these to be compiler barriers on x86
  * add a new patch to use __cpuid and __cpuidex intrinsics when
    building with msvc
  * add a new patch to use _umonitor, _umwait and _tpause intrinsics
    when building with msvc

v2:
  * use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
    are intended to be memory barriers not compiler barriers on
    x86_64

Tyler Retzlaff (16):
  eal: use rdtsc intrinsic
  eal: use rtm and xtest intrinsics
  eal: use barrier intrinsics
  eal: use cpuid and cpuidex intrinsics
  eal: use umonitor umwait and tpause intrinsics
  eal: use prefetch intrinsics
  eal: use byte swap intrinsics
  eal: hide GCC extension based alignment markers
  eal: hide typedefs based on GCC vector extensions
  eal: expand most macros to empty when using MSVC
  eal: exclude exposure of rte atomic APIs for MSVC builds
  eal: always define MSVC as little endian
  eal: do not define typeof macro when building with MSVC
  log: use standard ternary operator instead of GCC extension
  eal: use standard ternary operator instead of GCC extension
  eal: define priority based ctor dtor for MSVC

 config/x86/meson.build                  |  6 ++
 lib/eal/common/eal_common_hexdump.c     |  2 +-
 lib/eal/include/generic/rte_atomic.h    | 11 ++++
 lib/eal/include/generic/rte_byteorder.h | 13 +++++
 lib/eal/include/generic/rte_vect.h      |  4 ++
 lib/eal/include/rte_branch_prediction.h |  8 +++
 lib/eal/include/rte_common.h            | 97 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 +++++++
 lib/eal/x86/include/rte_atomic.h        |  8 +++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++
 lib/eal/x86/include/rte_cycles.h        | 14 +++--
 lib/eal/x86/include/rte_prefetch.h      | 25 +++++++--
 lib/eal/x86/include/rte_rtm.h           | 18 ++----
 lib/eal/x86/rte_cpuflags.c              |  6 +-
 lib/eal/x86/rte_cpuid.h                 |  7 +++
 lib/eal/x86/rte_cycles.c                | 36 ++++++++++++
 lib/eal/x86/rte_hypervisor.c            |  4 ++
 lib/eal/x86/rte_power_intrinsics.c      | 12 ++++
 lib/log/log.c                           |  2 +-
 19 files changed, 271 insertions(+), 26 deletions(-)

-- 
1.8.3.1

[PATCH v11 01/16] eal: use rdtsc intrinsic

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/include/rte_cycles.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..ca0fb10 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
 #ifndef _RTE_CYCLES_X86_64_H_
 #define _RTE_CYCLES_X86_64_H_
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#include <intrin.h>
+#else
+#include <x86intrin.h>
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -23,6 +29,7 @@
 static inline uint64_t
 rte_rdtsc(void)
 {
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	union {
 		uint64_t tsc_64;
 		RTE_STD_C11
@@ -32,7 +39,6 @@
 		};
 	} tsc;
 
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
 	if (unlikely(rte_cycles_vmware_tsc_map)) {
 		/* ecx = 0x10000 corresponds to the physical TSC for VMware */
 		asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
 		return tsc.tsc_64;
 	}
 #endif
-
-	asm volatile("rdtsc" :
-		     "=a" (tsc.lo_32),
-		     "=d" (tsc.hi_32));
-	return tsc.tsc_64;
+	return __rdtsc();
 }
 
 static inline uint64_t
-- 
1.8.3.1

RE: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Ali Alnubani]

> -----Original Message-----
> From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Sent: Friday, August 11, 2023 10:21 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> david.marchand@redhat.com; mb@smartsharesystems.com; Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> 
> Inline assembly is not supported for MSVC x64. Convert code to use
> __rdtsc intrinsic.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---

Hello,

This patch is causing a build failure in Windows with Clang 11:

"""
[72/803] Compiling C object drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj
FAILED: drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj
clang @drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj.rsp
In file included from ../drivers/common/idpf/idpf_common_rxtx_avx512.c:6:
In file included from ..\drivers\common\idpf/idpf_common_device.h:9:
In file included from ..\drivers\common\idpf/base/idpf_prototype.h:9:
In file included from ..\drivers\common\idpf/base/idpf_osdep.h:18:
In file included from ..\lib\eal\include\rte_malloc.h:16:
In file included from ..\lib\eal\include\rte_memory.h:25:
In file included from ..\lib\eal\include\rte_fbarray.h:39:
In file included from ..\lib\eal\x86\include\rte_rwlock.h:13:
In file included from ..\lib\eal\x86\include/rte_spinlock.h:18:
In file included from ..\lib\eal\x86\include/rte_cycles.h:12:
In file included from C:\Tools\LLVM\lib\clang\11.0.0\include\x86intrin.h:24:
C:\Tools\LLVM\lib\clang\11.0.0\include\prfchwintrin.h:50:1: error: conflicting types for '__m_prefetchw'
_m_prefetchw(void *__P)
^
..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw'
#define _m_prefetchw __m_prefetchw
                     ^
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\winnt.h:3324:1: note: previous declaration is here
_m_prefetchw (
^
..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw'
#define _m_prefetchw __m_prefetchw
                     ^
1 error generated.
[73/803] Generating rte_bus_auxiliary_def with a custom command
[74/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_controlq.c.obj
[75/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_idpf_common_rxtx.c.obj
[76/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_controlq_setup.c.obj
[77/803] Generating rte_bus_vdev.pmd.c with a custom command
[78/803] Compiling C object drivers/a715181@@tmp_rte_bus_pci@sta/bus_pci_pci_params.c.obj
[79/803] Compiling C object drivers/a715181@@tmp_rte_bus_pci@sta/bus_pci_pci_common.c.obj
[80/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_common.c.obj
[81/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_idpf_common_virtchnl.c.obj
ninja: build stopped: subcommand failed.
"""

Cross build with x86_64-w64-mingw32-gcc 12.2.1 on Fedora Linux doesn't reproduce.

Regards,
Ali

Re: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Tyler Retzlaff]

On Sat, Aug 26, 2023 at 02:38:26PM +0000, Ali Alnubani wrote:
> > -----Original Message-----
> > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Sent: Friday, August 11, 2023 10:21 PM
> > To: dev@dpdk.org
> > Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > david.marchand@redhat.com; mb@smartsharesystems.com; Tyler Retzlaff
> > <roretzla@linux.microsoft.com>
> > Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > 
> > Inline assembly is not supported for MSVC x64. Convert code to use
> > __rdtsc intrinsic.
> > 
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> 
> Hello,
> 
> This patch is causing a build failure in Windows with Clang 11:

Hi Ali,

while we don't currently document a minimum clang version required to
build the windows port i'm starting to consider establishing policy that
in effect says we may bump the required compiler version on any dpdk
release (not just long term servicing releases). but before doing that
it would be nice to understand if that would cause undue pain on the
port users.

So is there a reason you can't use LLVM 16?

Not that this information helps you but this is the background to what
is breaking here.

The failure here is due to a mistmatch in cv-qualification of the prototype
for __m_prefetchw that comes from clang VS the prototype that comes from the
Windows SDK.

The Windows SDK will not be changed to remove the volatile qualification
and even if it were removed it would be a breaking API change. The LLVM
version of the prototype could be volatile qualified without a breaking
change causing no harm.

Thanks

> 
> """
> [72/803] Compiling C object drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj
> FAILED: drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj
> clang @drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj.rsp
> In file included from ../drivers/common/idpf/idpf_common_rxtx_avx512.c:6:
> In file included from ..\drivers\common\idpf/idpf_common_device.h:9:
> In file included from ..\drivers\common\idpf/base/idpf_prototype.h:9:
> In file included from ..\drivers\common\idpf/base/idpf_osdep.h:18:
> In file included from ..\lib\eal\include\rte_malloc.h:16:
> In file included from ..\lib\eal\include\rte_memory.h:25:
> In file included from ..\lib\eal\include\rte_fbarray.h:39:
> In file included from ..\lib\eal\x86\include\rte_rwlock.h:13:
> In file included from ..\lib\eal\x86\include/rte_spinlock.h:18:
> In file included from ..\lib\eal\x86\include/rte_cycles.h:12:
> In file included from C:\Tools\LLVM\lib\clang\11.0.0\include\x86intrin.h:24:
> C:\Tools\LLVM\lib\clang\11.0.0\include\prfchwintrin.h:50:1: error: conflicting types for '__m_prefetchw'
> _m_prefetchw(void *__P)
> ^
> ..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw'
> #define _m_prefetchw __m_prefetchw
>                      ^
> C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\winnt.h:3324:1: note: previous declaration is here
> _m_prefetchw (
> ^
> ..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw'
> #define _m_prefetchw __m_prefetchw
>                      ^
> 1 error generated.
> [73/803] Generating rte_bus_auxiliary_def with a custom command
> [74/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_controlq.c.obj
> [75/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_idpf_common_rxtx.c.obj
> [76/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_controlq_setup.c.obj
> [77/803] Generating rte_bus_vdev.pmd.c with a custom command
> [78/803] Compiling C object drivers/a715181@@tmp_rte_bus_pci@sta/bus_pci_pci_params.c.obj
> [79/803] Compiling C object drivers/a715181@@tmp_rte_bus_pci@sta/bus_pci_pci_common.c.obj
> [80/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_base_idpf_common.c.obj
> [81/803] Compiling C object drivers/a715181@@tmp_rte_common_idpf@sta/common_idpf_idpf_common_virtchnl.c.obj
> ninja: build stopped: subcommand failed.
> """
> 
> Cross build with x86_64-w64-mingw32-gcc 12.2.1 on Fedora Linux doesn't reproduce.
> 
> Regards,
> Ali

RE: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Ali Alnubani]

> -----Original Message-----
> From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Sent: Tuesday, August 29, 2023 7:16 PM
> To: Ali Alnubani <alialnu@nvidia.com>
> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; Bruce
> Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> mb@smartsharesystems.com
> Subject: Re: [PATCH v11 01/16] eal: use rdtsc intrinsic
> 
> On Sat, Aug 26, 2023 at 02:38:26PM +0000, Ali Alnubani wrote:
> > > -----Original Message-----
> > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Sent: Friday, August 11, 2023 10:21 PM
> > > To: dev@dpdk.org
> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> <ciara.power@intel.com>;
> > > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > david.marchand@redhat.com; mb@smartsharesystems.com; Tyler
> Retzlaff
> > > <roretzla@linux.microsoft.com>
> > > Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > >
> > > Inline assembly is not supported for MSVC x64. Convert code to use
> > > __rdtsc intrinsic.
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > ---
> >
> > Hello,
> >
> > This patch is causing a build failure in Windows with Clang 11:
> 
> Hi Ali,
> 
> while we don't currently document a minimum clang version required to
> build the windows port i'm starting to consider establishing policy that
> in effect says we may bump the required compiler version on any dpdk
> release (not just long term servicing releases). but before doing that
> it would be nice to understand if that would cause undue pain on the
> port users.
> 
> So is there a reason you can't use LLVM 16?

No specific reason. I reported this because compilation was passing with Clang 11 prior to this patch.

Regards,
Ali

RE: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Ali Alnubani]

> -----Original Message-----
> From: Ali Alnubani <alialnu@nvidia.com>
> Sent: Wednesday, August 30, 2023 4:38 PM
> To: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; Bruce
> Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> mb@smartsharesystems.com
> Subject: RE: [PATCH v11 01/16] eal: use rdtsc intrinsic
> 
> > -----Original Message-----
> > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Sent: Tuesday, August 29, 2023 7:16 PM
> > To: Ali Alnubani <alialnu@nvidia.com>
> > Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; Bruce
> > Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > mb@smartsharesystems.com
> > Subject: Re: [PATCH v11 01/16] eal: use rdtsc intrinsic
> >
> > On Sat, Aug 26, 2023 at 02:38:26PM +0000, Ali Alnubani wrote:
> > > > -----Original Message-----
> > > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > Sent: Friday, August 11, 2023 10:21 PM
> > > > To: dev@dpdk.org
> > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin
> Ananyev
> > > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> > <ciara.power@intel.com>;
> > > > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > david.marchand@redhat.com; mb@smartsharesystems.com; Tyler
> > Retzlaff
> > > > <roretzla@linux.microsoft.com>
> > > > Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > > >
> > > > Inline assembly is not supported for MSVC x64. Convert code to use
> > > > __rdtsc intrinsic.
> > > >
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > ---
> > >
> > > Hello,
> > >
> > > This patch is causing a build failure in Windows with Clang 11:
> >
> > Hi Ali,
> >
> > while we don't currently document a minimum clang version required to
> > build the windows port i'm starting to consider establishing policy that
> > in effect says we may bump the required compiler version on any dpdk
> > release (not just long term servicing releases). but before doing that
> > it would be nice to understand if that would cause undue pain on the
> > port users.
> >
> > So is there a reason you can't use LLVM 16?
> 
> No specific reason. I reported this because compilation was passing with Clang
> 11 prior to this patch.
> 

Building with clang version 16.0.6 fails for me with:

[..]
[405/803] Linking target lib/rte_eal-24.dll
FAILED: lib/rte_eal-24.dll 
"clang" @lib/rte_eal-24.dll.rsp
clang: error: no such file or directory: 'librte_log.lib'
clang: error: no such file or directory: 'librte_kvargs.lib'
[406/803] Compiling C object lib/librte_mempool.a.p/mempool_rte_mempool_ops_default.c.obj
[..]

RE: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Ali Alnubani]

> -----Original Message-----
> From: Ali Alnubani
> Sent: Wednesday, August 30, 2023 6:49 PM
> To: 'Tyler Retzlaff' <roretzla@linux.microsoft.com>
> Cc: 'David Marchand' <david.marchand@redhat.com>; 'dev@dpdk.org'
> <dev@dpdk.org>; 'Bruce Richardson' <bruce.richardson@intel.com>;
> 'Konstantin Ananyev' <konstantin.v.ananyev@yandex.ru>; 'Ciara Power'
> <ciara.power@intel.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; 'mb@smartsharesystems.com'
> <mb@smartsharesystems.com>
> Subject: RE: [PATCH v11 01/16] eal: use rdtsc intrinsic
> 
> > -----Original Message-----
> > From: Ali Alnubani <alialnu@nvidia.com>
> > Sent: Wednesday, August 30, 2023 4:38 PM
> > To: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; Bruce
> > Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > mb@smartsharesystems.com
> > Subject: RE: [PATCH v11 01/16] eal: use rdtsc intrinsic
> >
> > > -----Original Message-----
> > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Sent: Tuesday, August 29, 2023 7:16 PM
> > > To: Ali Alnubani <alialnu@nvidia.com>
> > > Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org;
> Bruce
> > > Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> <ciara.power@intel.com>;
> > > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > mb@smartsharesystems.com
> > > Subject: Re: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > >
> > > On Sat, Aug 26, 2023 at 02:38:26PM +0000, Ali Alnubani wrote:
> > > > > -----Original Message-----
> > > > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > Sent: Friday, August 11, 2023 10:21 PM
> > > > > To: dev@dpdk.org
> > > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin
> > Ananyev
> > > > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> > > <ciara.power@intel.com>;
> > > > > NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>;
> > > > > david.marchand@redhat.com; mb@smartsharesystems.com; Tyler
> > > Retzlaff
> > > > > <roretzla@linux.microsoft.com>
> > > > > Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > > > >
> > > > > Inline assembly is not supported for MSVC x64. Convert code to use
> > > > > __rdtsc intrinsic.
> > > > >
> > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > ---
> > > >
> > > > Hello,
> > > >
> > > > This patch is causing a build failure in Windows with Clang 11:
> > >
> > > Hi Ali,
> > >
> > > while we don't currently document a minimum clang version required to
> > > build the windows port i'm starting to consider establishing policy that
> > > in effect says we may bump the required compiler version on any dpdk
> > > release (not just long term servicing releases). but before doing that
> > > it would be nice to understand if that would cause undue pain on the
> > > port users.
> > >
> > > So is there a reason you can't use LLVM 16?
> >
> > No specific reason. I reported this because compilation was passing with
> Clang
> > 11 prior to this patch.
> >
> 
> Building with clang version 16.0.6 fails for me with:
> 
> [..]
> [405/803] Linking target lib/rte_eal-24.dll
> FAILED: lib/rte_eal-24.dll
> "clang" @lib/rte_eal-24.dll.rsp
> clang: error: no such file or directory: 'librte_log.lib'
> clang: error: no such file or directory: 'librte_kvargs.lib'
> [406/803] Compiling C object
> lib/librte_mempool.a.p/mempool_rte_mempool_ops_default.c.obj
> [..]

This build failure was actually caused by upgrading Meson from 0.54.3 to 1.2.1 earlier on the environment.
The build passes with Meson 0.54.3 and Clang 16.0.6.

Re: [PATCH v11 01/16] eal: use rdtsc intrinsic

[Tyler Retzlaff]

On Wed, Aug 30, 2023 at 04:29:07PM +0000, Ali Alnubani wrote:
> > -----Original Message-----
> > From: Ali Alnubani
> > Sent: Wednesday, August 30, 2023 6:49 PM
> > To: 'Tyler Retzlaff' <roretzla@linux.microsoft.com>
> > Cc: 'David Marchand' <david.marchand@redhat.com>; 'dev@dpdk.org'
> > <dev@dpdk.org>; 'Bruce Richardson' <bruce.richardson@intel.com>;
> > 'Konstantin Ananyev' <konstantin.v.ananyev@yandex.ru>; 'Ciara Power'
> > <ciara.power@intel.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>; 'mb@smartsharesystems.com'
> > <mb@smartsharesystems.com>
> > Subject: RE: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > 
> > > -----Original Message-----
> > > From: Ali Alnubani <alialnu@nvidia.com>
> > > Sent: Wednesday, August 30, 2023 4:38 PM
> > > To: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; Bruce
> > > Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > > <konstantin.v.ananyev@yandex.ru>; Ciara Power <ciara.power@intel.com>;
> > > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > mb@smartsharesystems.com
> > > Subject: RE: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > >
> > > > -----Original Message-----
> > > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > Sent: Tuesday, August 29, 2023 7:16 PM
> > > > To: Ali Alnubani <alialnu@nvidia.com>
> > > > Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org;
> > Bruce
> > > > Richardson <bruce.richardson@intel.com>; Konstantin Ananyev
> > > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> > <ciara.power@intel.com>;
> > > > NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > mb@smartsharesystems.com
> > > > Subject: Re: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > > >
> > > > On Sat, Aug 26, 2023 at 02:38:26PM +0000, Ali Alnubani wrote:
> > > > > > -----Original Message-----
> > > > > > From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > Sent: Friday, August 11, 2023 10:21 PM
> > > > > > To: dev@dpdk.org
> > > > > > Cc: Bruce Richardson <bruce.richardson@intel.com>; Konstantin
> > > Ananyev
> > > > > > <konstantin.v.ananyev@yandex.ru>; Ciara Power
> > > > <ciara.power@intel.com>;
> > > > > > NBU-Contact-Thomas Monjalon (EXTERNAL)
> > <thomas@monjalon.net>;
> > > > > > david.marchand@redhat.com; mb@smartsharesystems.com; Tyler
> > > > Retzlaff
> > > > > > <roretzla@linux.microsoft.com>
> > > > > > Subject: [PATCH v11 01/16] eal: use rdtsc intrinsic
> > > > > >
> > > > > > Inline assembly is not supported for MSVC x64. Convert code to use
> > > > > > __rdtsc intrinsic.
> > > > > >
> > > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > ---
> > > > >
> > > > > Hello,
> > > > >
> > > > > This patch is causing a build failure in Windows with Clang 11:
> > > >
> > > > Hi Ali,
> > > >
> > > > while we don't currently document a minimum clang version required to
> > > > build the windows port i'm starting to consider establishing policy that
> > > > in effect says we may bump the required compiler version on any dpdk
> > > > release (not just long term servicing releases). but before doing that
> > > > it would be nice to understand if that would cause undue pain on the
> > > > port users.
> > > >
> > > > So is there a reason you can't use LLVM 16?
> > >
> > > No specific reason. I reported this because compilation was passing with
> > Clang
> > > 11 prior to this patch.
> > >
> > 
> > Building with clang version 16.0.6 fails for me with:
> > 
> > [..]
> > [405/803] Linking target lib/rte_eal-24.dll
> > FAILED: lib/rte_eal-24.dll
> > "clang" @lib/rte_eal-24.dll.rsp
> > clang: error: no such file or directory: 'librte_log.lib'
> > clang: error: no such file or directory: 'librte_kvargs.lib'
> > [406/803] Compiling C object
> > lib/librte_mempool.a.p/mempool_rte_mempool_ops_default.c.obj
> > [..]
> 
> This build failure was actually caused by upgrading Meson from 0.54.3 to 1.2.1 earlier on the environment.
> The build passes with Meson 0.54.3 and Clang 16.0.6.

yes, the windows build is very sensitive to meson version. i only test
with 0.57.0 i have not had time to investigate why newer versions do not
work.

[PATCH v11 02/16] eal: use rtm and xtest intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 config/x86/meson.build        |  6 ++++++
 lib/eal/x86/include/rte_rtm.h | 18 +++++-------------
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
     machine_args += '-msse4'
 endif
 
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+    machine_args += '-mrtm'
+endif
+
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
     compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
 #ifndef _RTE_RTM_H_
 #define _RTE_RTM_H_ 1
 
+#include <immintrin.h>
 
 /* Official RTM intrinsics interface matching gcc/icc, but works
    on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
 static __rte_always_inline
 unsigned int rte_xbegin(void)
 {
-	unsigned int ret = RTE_XBEGIN_STARTED;
-
-	asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
-	return ret;
+	return _xbegin();
 }
 
 static __rte_always_inline
 void rte_xend(void)
 {
-	 asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+	_xend();
 }
 
 /* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
-	asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
 
 static __rte_always_inline
 int rte_xtest(void)
 {
-	unsigned char out;
-
-	asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
-		"=r" (out) :: "memory");
-	return out;
+	return _xtest();
 }
 
 #ifdef __cplusplus
-- 
1.8.3.1

[PATCH v11 03/16] eal: use barrier intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 4 ++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index aef44e2..2d36eb0 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -146,9 +146,13 @@
  * Guarantees that operation reordering does not occur at compile time
  * for operations directly before and after the barrier.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define rte_compiler_barrier() _ReadWriteBarrier()
+#else
 #define	rte_compiler_barrier() do {		\
 	asm volatile ("" : : : "memory");	\
 } while(0)
+#endif
 
 /**
  * Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..7aba1c3 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,15 @@
 static __rte_always_inline void
 rte_smp_mb(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	_mm_mfence();
+#else
 #ifdef RTE_ARCH_I686
 	asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
 #else
 	asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
 #endif
+#endif
 }
 
 #define rte_io_mb() rte_mb()
-- 
1.8.3.1

[PATCH v11 04/16] eal: use cpuid and cpuidex intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/x86/rte_cpuflags.c   |  6 +++++-
 lib/eal/x86/rte_cpuid.h      |  7 +++++++
 lib/eal/x86/rte_cycles.c     | 36 ++++++++++++++++++++++++++++++++++++
 lib/eal/x86/rte_hypervisor.c |  4 ++++
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..8a30f79 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
 	if (maxleaf < feat->leaf)
 		return 0;
 
-	 __cpuid_count(feat->leaf, feat->subleaf,
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuidex(regs, feat->leaf, feat->subleaf);
+#else
+	__cpuid_count(feat->leaf, feat->subleaf,
 			 regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			 regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 
 	/* check if the feature is enabled */
 	return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
 #ifndef RTE_CPUID_H
 #define RTE_CPUID_H
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #include <cpuid.h>
+#endif
 
 enum cpu_register_t {
 	RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
 
 typedef uint32_t cpuid_registers_t[4];
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
 #endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..69ed59b 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
 
 #include <fcntl.h>
 #include <unistd.h>
+#ifdef RTE_TOOLCHAIN_MSVC
+#define bit_AVX (1 << 28)
+#else
 #include <cpuid.h>
+#endif
 
 
 #include "eal_private.h"
@@ -82,9 +86,25 @@
 	return 0;
 }
 
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+	uint32_t cpuinfo[4];
+
+	__cpuid(cpuinfo, e);
+	if (s)
+		*s = cpuinfo[1];
+	return cpuinfo[0];
+}
+#endif
+
 uint64_t
 get_tsc_freq_arch(void)
 {
+#ifdef RTE_TOOLCHAIN_MSVC
+	int cpuinfo[4];
+#endif
 	uint64_t tsc_hz = 0;
 	uint32_t a, b, c, d, maxleaf;
 	uint8_t mult, model;
@@ -97,14 +117,30 @@
 	maxleaf = __get_cpuid_max(0, NULL);
 
 	if (maxleaf >= 0x15) {
+#ifdef RTE_TOOLCHAIN_MSVC
+		__cpuid(cpuinfo, 0x15);
+		a = cpuinfo[0];
+		b = cpuinfo[1];
+		c = cpuinfo[2];
+		d = cpuinfo[3];
+#else
 		__cpuid(0x15, a, b, c, d);
+#endif
 
 		/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
 		if (b && c)
 			return c * (b / a);
 	}
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(cpuinfo, 0x1);
+	a = cpuinfo[0];
+	b = cpuinfo[1];
+	c = cpuinfo[2];
+	d = cpuinfo[3];
+#else
 	__cpuid(0x1, a, b, c, d);
+#endif
 	model = rte_cpu_get_model(a);
 
 	if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..04fe767 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
 	if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
 		return RTE_HYPERVISOR_NONE;
 
+#ifdef RTE_TOOLCHAIN_MSVC
+	__cpuid(regs, HYPERVISOR_INFO_LEAF);
+#else
 	__cpuid(HYPERVISOR_INFO_LEAF,
 			regs[RTE_REG_EAX], regs[RTE_REG_EBX],
 			regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#endif
 	for (reg = 1; reg < 4; reg++)
 		memcpy(name + (reg - 1) * 4, &regs[reg], 4);
 	name[12] = '\0';
-- 
1.8.3.1

[PATCH v11 05/16] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..4066d13 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
 	 */
 
 	/* set address for UMONITOR */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umonitor(pmc->addr);
+#else
 	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
 			:
 			: "D"(pmc->addr));
+#endif
 
 	/* now that we've put this address into monitor, we can unlock */
 	rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
 		goto end;
 
 	/* execute UMWAIT */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_umwait(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			  "a"(tsc_l), "d"(tsc_h));
+#endif
 
 end:
 	/* erase sleep address */
@@ -153,10 +161,14 @@
 		return -ENOTSUP;
 
 	/* execute TPAUSE */
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+	_tpause(tsc_l, tsc_h);
+#else
 	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
 			: /* ignore rflags */
 			: "D"(0), /* enter C0.2 */
 			"a"(tsc_l), "d"(tsc_h));
+#endif
 
 	return 0;
 }
-- 
1.8.3.1

Re: [PATCH v11 05/16] eal: use umonitor umwait and tpause intrinsics

[Bruce Richardson]

On Fri, Aug 11, 2023 at 12:20:47PM -0700, Tyler Retzlaff wrote:
> Inline assembly is not supported for MSVC x64 instead use _umonitor,
> _umwait and _tpause intrinsics.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> ---
>  lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/lib/eal/x86/rte_power_intrinsics.c b/lib/eal/x86/rte_power_intrinsics.c
> index f749da9..4066d13 100644
> --- a/lib/eal/x86/rte_power_intrinsics.c
> +++ b/lib/eal/x86/rte_power_intrinsics.c
> @@ -109,9 +109,13 @@
>  	 */
>  
>  	/* set address for UMONITOR */
> +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> +	_umonitor(pmc->addr);
> +#else

This change is unfortunately giving build errors on system with WAITPKG,
since the intrinsics do not take volatile parameters, unlike the inline ASM
which works fine with both volatile and non-volatile variables. This is the
error I see:

../lib/eal/x86/rte_power_intrinsics.c: In function 'rte_power_monitor':
../lib/eal/x86/rte_power_intrinsics.c:113:22: error: passing argument 1 of '_umonitor' discards 'volatile' qualifier from pointer target type [-Werror=discarded-qualifiers]
  113 |         _umonitor(pmc->addr);
      |                   ~~~^~~~~~

The easy fix for now seems to be just dropping the "||
defined(__WAITPKG__)" part of the #ifdef, and leave the intrinsic for MSVC
only.
Any objections?

/Bruce

RE: [PATCH v11 05/16] eal: use umonitor umwait and tpause intrinsics

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 25 August 2023 16.13
> 
> On Fri, Aug 11, 2023 at 12:20:47PM -0700, Tyler Retzlaff wrote:
> > Inline assembly is not supported for MSVC x64 instead use _umonitor,
> > _umwait and _tpause intrinsics.
> >
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > ---
> >  lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/lib/eal/x86/rte_power_intrinsics.c
> b/lib/eal/x86/rte_power_intrinsics.c
> > index f749da9..4066d13 100644
> > --- a/lib/eal/x86/rte_power_intrinsics.c
> > +++ b/lib/eal/x86/rte_power_intrinsics.c
> > @@ -109,9 +109,13 @@
> >  	 */
> >
> >  	/* set address for UMONITOR */
> > +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> > +	_umonitor(pmc->addr);
> > +#else
> 
> This change is unfortunately giving build errors on system with WAITPKG,
> since the intrinsics do not take volatile parameters, unlike the inline
> ASM
> which works fine with both volatile and non-volatile variables. This is
> the
> error I see:
> 
> ../lib/eal/x86/rte_power_intrinsics.c: In function 'rte_power_monitor':
> ../lib/eal/x86/rte_power_intrinsics.c:113:22: error: passing argument 1
> of '_umonitor' discards 'volatile' qualifier from pointer target type [-
> Werror=discarded-qualifiers]
>   113 |         _umonitor(pmc->addr);
>       |                   ~~~^~~~~~
> 
> The easy fix for now seems to be just dropping the "||
> defined(__WAITPKG__)" part of the #ifdef, and leave the intrinsic for
> MSVC
> only.
> Any objections?

I wonder if omitting the "volatile" qualifier is correct for this parameter. Although the authors of _umonitor() apparently think so, I have seen built-ins with questionable qualifiers before, so I wouldn't trust it to be correct.

Replacing inline assembly with built-ins is generally preferable. So I would prefer if you typecast it away, or temporarily disable that warning.

But I don't object to the quick fix. :-)

-Morten

Re: [PATCH v11 05/16] eal: use umonitor umwait and tpause intrinsics

[Bruce Richardson]

On Fri, Aug 25, 2023 at 04:56:51PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 25 August 2023 16.13
> > 
> > On Fri, Aug 11, 2023 at 12:20:47PM -0700, Tyler Retzlaff wrote:
> > > Inline assembly is not supported for MSVC x64 instead use _umonitor,
> > > _umwait and _tpause intrinsics.
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > ---
> > >  lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/lib/eal/x86/rte_power_intrinsics.c
> > b/lib/eal/x86/rte_power_intrinsics.c
> > > index f749da9..4066d13 100644
> > > --- a/lib/eal/x86/rte_power_intrinsics.c
> > > +++ b/lib/eal/x86/rte_power_intrinsics.c
> > > @@ -109,9 +109,13 @@
> > >  	 */
> > >
> > >  	/* set address for UMONITOR */
> > > +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> > > +	_umonitor(pmc->addr);
> > > +#else
> > 
> > This change is unfortunately giving build errors on system with WAITPKG,
> > since the intrinsics do not take volatile parameters, unlike the inline
> > ASM
> > which works fine with both volatile and non-volatile variables. This is
> > the
> > error I see:
> > 
> > ../lib/eal/x86/rte_power_intrinsics.c: In function 'rte_power_monitor':
> > ../lib/eal/x86/rte_power_intrinsics.c:113:22: error: passing argument 1
> > of '_umonitor' discards 'volatile' qualifier from pointer target type [-
> > Werror=discarded-qualifiers]
> >   113 |         _umonitor(pmc->addr);
> >       |                   ~~~^~~~~~
> > 
> > The easy fix for now seems to be just dropping the "||
> > defined(__WAITPKG__)" part of the #ifdef, and leave the intrinsic for
> > MSVC
> > only.
> > Any objections?
> 
> I wonder if omitting the "volatile" qualifier is correct for this parameter. Although the authors of _umonitor() apparently think so, I have seen built-ins with questionable qualifiers before, so I wouldn't trust it to be correct.
> 
> Replacing inline assembly with built-ins is generally preferable. So I would prefer if you typecast it away, or temporarily disable that warning.
> 
Simple typecasting doesn't work to remove the warning. However, if we
typecast via "uintptr_t" it does seem to work.

 #if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
-       _umonitor(pmc->addr);
+       uintptr_t addr_val = (uintptr_t)pmc->addr;
+       _umonitor((void *)addr_val);
 #else

Seems bit clunky to me. If we want a one-line workaround, we can probably
use RTE_PTR_ADD to do the typecasting via uintptr_t for us.

/Bruce

Re: [PATCH v11 05/16] eal: use umonitor umwait and tpause intrinsics

[Tyler Retzlaff]

On Fri, Aug 25, 2023 at 04:12:59PM +0100, Bruce Richardson wrote:
> On Fri, Aug 25, 2023 at 04:56:51PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Friday, 25 August 2023 16.13
> > > 
> > > On Fri, Aug 11, 2023 at 12:20:47PM -0700, Tyler Retzlaff wrote:
> > > > Inline assembly is not supported for MSVC x64 instead use _umonitor,
> > > > _umwait and _tpause intrinsics.
> > > >
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > > > ---
> > > >  lib/eal/x86/rte_power_intrinsics.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/lib/eal/x86/rte_power_intrinsics.c
> > > b/lib/eal/x86/rte_power_intrinsics.c
> > > > index f749da9..4066d13 100644
> > > > --- a/lib/eal/x86/rte_power_intrinsics.c
> > > > +++ b/lib/eal/x86/rte_power_intrinsics.c
> > > > @@ -109,9 +109,13 @@
> > > >  	 */
> > > >
> > > >  	/* set address for UMONITOR */
> > > > +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> > > > +	_umonitor(pmc->addr);
> > > > +#else
> > > 
> > > This change is unfortunately giving build errors on system with WAITPKG,
> > > since the intrinsics do not take volatile parameters, unlike the inline
> > > ASM
> > > which works fine with both volatile and non-volatile variables. This is
> > > the
> > > error I see:
> > > 
> > > ../lib/eal/x86/rte_power_intrinsics.c: In function 'rte_power_monitor':
> > > ../lib/eal/x86/rte_power_intrinsics.c:113:22: error: passing argument 1
> > > of '_umonitor' discards 'volatile' qualifier from pointer target type [-
> > > Werror=discarded-qualifiers]
> > >   113 |         _umonitor(pmc->addr);
> > >       |                   ~~~^~~~~~
> > > 
> > > The easy fix for now seems to be just dropping the "||
> > > defined(__WAITPKG__)" part of the #ifdef, and leave the intrinsic for
> > > MSVC
> > > only.
> > > Any objections?
> > 
> > I wonder if omitting the "volatile" qualifier is correct for this parameter. Although the authors of _umonitor() apparently think so, I have seen built-ins with questionable qualifiers before, so I wouldn't trust it to be correct.

omitting the volatile qualifier is okay. often the reason why parameters
are qualified is as a convenience so that you may pass a volatile
qualified argument (and not force removal of the qualification).

> > 
> > Replacing inline assembly with built-ins is generally preferable. So I would prefer if you typecast it away, or temporarily disable that warning.
> > 
> Simple typecasting doesn't work to remove the warning. However, if we
> typecast via "uintptr_t" it does seem to work.

yes, this is canonical way to remove the qualification.

> 
>  #if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> -       _umonitor(pmc->addr);
> +       uintptr_t addr_val = (uintptr_t)pmc->addr;
> +       _umonitor((void *)addr_val);
>  #else
> 
> Seems bit clunky to me. If we want a one-line workaround, we can probably
> use RTE_PTR_ADD to do the typecasting via uintptr_t for us.
> 
> /Bruce

[PATCH v11 06/16] eal: use prefetch intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
---
 lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..7a6988e 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
 extern "C" {
 #endif
 
+#include <emmintrin.h>
+
 #include <rte_compat.h>
 #include <rte_common.h>
 #include "generic/rte_prefetch.h"
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
 static inline void rte_prefetch0(const volatile void *p)
 {
-	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T0);
 }
 
 static inline void rte_prefetch1(const volatile void *p)
 {
-	asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T1);
 }
 
 static inline void rte_prefetch2(const volatile void *p)
 {
-	asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_T2);
 }
 
 static inline void rte_prefetch_non_temporal(const volatile void *p)
 {
-	asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char *)p));
+	_mm_prefetch((const void *)p, _MM_HINT_NTA);
 }
 
+#pragma GCC diagnostic pop
+
+#ifdef RTE_TOOLCHAIN_MSVC
 /*
  * We use raw byte codes for now as only the newest compiler
  * versions support this instruction natively.
@@ -41,8 +49,17 @@ static inline void rte_prefetch_non_temporal(const volatile void *p)
 static inline void
 rte_cldemote(const volatile void *p)
 {
+	_mm_cldemote(p);
+}
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
 	asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
 }
+#endif
+
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[David Marchand]

On Fri, Aug 11, 2023 at 9:21 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> and _mm_cldemote intrinsics.
>
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> ---
>  lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/lib/eal/x86/include/rte_prefetch.h b/lib/eal/x86/include/rte_prefetch.h
> index 7fd01c4..7a6988e 100644
> --- a/lib/eal/x86/include/rte_prefetch.h
> +++ b/lib/eal/x86/include/rte_prefetch.h
> @@ -9,30 +9,38 @@
>  extern "C" {
>  #endif
>
> +#include <emmintrin.h>
> +
>  #include <rte_compat.h>
>  #include <rte_common.h>
>  #include "generic/rte_prefetch.h"
>
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wcast-qual"
> +
>  static inline void rte_prefetch0(const volatile void *p)
>  {
> -       asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
> +       _mm_prefetch((const void *)p, _MM_HINT_T0);
>  }
>

Quite surprisingly, this part (exactly) breaks 32bits build in the
vhost library:

ccache cc -Ilib/librte_vhost.a.p -Ilib
-I../../../git/pub/dpdk.org/main/lib -Ilib/vhost
-I../../../git/pub/dpdk.org/main/lib/vhost -I.
-I../../../git/pub/dpdk.org/main -Iconfig
-I../../../git/pub/dpdk.org/main/config -Ilib/eal/include
-I../../../git/pub/dpdk.org/main/lib/eal/include
-Ilib/eal/linux/include
-I../../../git/pub/dpdk.org/main/lib/eal/linux/include
-Ilib/eal/x86/include
-I../../../git/pub/dpdk.org/main/lib/eal/x86/include -Ilib/eal/common
-I../../../git/pub/dpdk.org/main/lib/eal/common -Ilib/eal
-I../../../git/pub/dpdk.org/main/lib/eal -Ilib/kvargs
-I../../../git/pub/dpdk.org/main/lib/kvargs -Ilib/log
-I../../../git/pub/dpdk.org/main/lib/log -Ilib/metrics
-I../../../git/pub/dpdk.org/main/lib/metrics -Ilib/telemetry
-I../../../git/pub/dpdk.org/main/lib/telemetry -Ilib/ethdev
-I../../../git/pub/dpdk.org/main/lib/ethdev -Ilib/net
-I../../../git/pub/dpdk.org/main/lib/net -Ilib/mbuf
-I../../../git/pub/dpdk.org/main/lib/mbuf -Ilib/mempool
-I../../../git/pub/dpdk.org/main/lib/mempool -Ilib/ring
-I../../../git/pub/dpdk.org/main/lib/ring -Ilib/meter
-I../../../git/pub/dpdk.org/main/lib/meter -Ilib/cryptodev
-I../../../git/pub/dpdk.org/main/lib/cryptodev -Ilib/rcu
-I../../../git/pub/dpdk.org/main/lib/rcu -Ilib/hash
-I../../../git/pub/dpdk.org/main/lib/hash -Ilib/pci
-I../../../git/pub/dpdk.org/main/lib/pci -Ilib/dmadev
-I../../../git/pub/dpdk.org/main/lib/dmadev -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11
-O2 -g -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
-Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds
-Wno-pointer-to-int-cast -D_GNU_SOURCE -m32 -fPIC -march=native -mrtm
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-DVHOST_GCC_UNROLL_PRAGMA -fno-strict-aliasing -DVHOST_HAS_VDUSE
-DRTE_LOG_DEFAULT_LOGTYPE=lib.vhost -MD -MQ
lib/librte_vhost.a.p/vhost_virtio_net.c.o -MF
lib/librte_vhost.a.p/vhost_virtio_net.c.o.d -o
lib/librte_vhost.a.p/vhost_virtio_net.c.o -c
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c
In function ‘mbuf_to_desc’,
    inlined from ‘vhost_enqueue_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
    inlined from ‘virtio_dev_rx_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
    inlined from ‘virtio_dev_rx_async_submit_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1230:18: error:
‘buf_vec[0].buf_addr’ may be used uninitialized
[-Werror=maybe-uninitialized]
 1230 |         buf_addr = buf_vec[vec_idx].buf_addr;
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
‘virtio_dev_rx_async_submit_packed’:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
‘buf_vec’ declared here
 1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
      |                           ^~~~~~~
In function ‘mbuf_to_desc’,
    inlined from ‘vhost_enqueue_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
    inlined from ‘virtio_dev_rx_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
    inlined from ‘virtio_dev_rx_async_submit_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1231:18: error:
‘buf_vec[0].buf_iova’ may be used uninitialized
[-Werror=maybe-uninitialized]
 1231 |         buf_iova = buf_vec[vec_idx].buf_iova;
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
‘virtio_dev_rx_async_submit_packed’:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
‘buf_vec’ declared here
 1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
      |                           ^~~~~~~
In function ‘mbuf_to_desc’,
    inlined from ‘vhost_enqueue_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
    inlined from ‘virtio_dev_rx_async_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
    inlined from ‘virtio_dev_rx_async_submit_packed’ at
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1232:35: error:
‘buf_vec[0].buf_len’ may be used uninitialized
[-Werror=maybe-uninitialized]
 1232 |         buf_len = buf_vec[vec_idx].buf_len;
      |                   ~~~~~~~~~~~~~~~~^~~~~~~~
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
‘virtio_dev_rx_async_submit_packed’:
../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
‘buf_vec’ declared here
 1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
      |                           ^~~~~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.

I had a look at the vhost library and I think the compiler thinks size may be 0.
Changing the loop on size with a do { } while (size > 0); resolves the warning.
I can post a change for this, as we hit a similar issue in the past
and the code does not make sense comparing size on the first iteration
of this loop.

However, I am a bit puzzled why the prefetch change makes the compiler
consider this loop differently.
We have the same constructs everywhere in this library and x86_64
builds are fine...



-- 
David Marchand

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[David Marchand]

On Thu, Aug 24, 2023 at 2:06 PM David Marchand
<david.marchand@redhat.com> wrote:
> I had a look at the vhost library and I think the compiler thinks size may be 0.
> Changing the loop on size with a do { } while (size > 0); resolves the warning.
> I can post a change for this, as we hit a similar issue in the past
> and the code does not make sense comparing size on the first iteration
> of this loop.

This sounds like a commit 4226aa9caca9 ("vhost: fix build with GCC
12") we had on LoongArch.

And the 32bits build warning goes away with this:

diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
index d7624d18c8..41328b7530 100644
--- a/lib/vhost/virtio_net.c
+++ b/lib/vhost/virtio_net.c
@@ -1906,7 +1906,7 @@ vhost_enqueue_async_packed(struct virtio_net *dev,
        uint16_t buf_id = 0;
        uint32_t len = 0;
        uint16_t desc_count = 0;
-       uint64_t size = pkt->pkt_len + sizeof(struct virtio_net_hdr_mrg_rxbuf);
+       uint64_t size = (uint64_t)pkt->pkt_len + sizeof(struct
virtio_net_hdr_mrg_rxbuf);
        uint32_t buffer_len[vq->size];
        uint16_t buffer_buf_id[vq->size];
        uint16_t buffer_desc_count[vq->size];


>
> However, I am a bit puzzled why the prefetch change makes the compiler
> consider this loop differently.
> We have the same constructs everywhere in this library and x86_64
> builds are fine...


-- 
David Marchand

RE: [PATCH v11 06/16] eal: use prefetch intrinsics

[Morten Brørup]

Regarding the vhost lib...

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Thursday, 24 August 2023 14.26
> 
> On Thu, Aug 24, 2023 at 2:06 PM David Marchand
> <david.marchand@redhat.com> wrote:
> > I had a look at the vhost library and I think the compiler thinks size may
> be 0.
> > Changing the loop on size with a do { } while (size > 0); resolves the
> warning.
> > I can post a change for this, as we hit a similar issue in the past
> > and the code does not make sense comparing size on the first iteration
> > of this loop.
> 
> This sounds like a commit 4226aa9caca9 ("vhost: fix build with GCC
> 12") we had on LoongArch.

If we know that size > 0 initially, then "do { } while (size > 0);" is more appropriate than "while (size > 0) { }", not only for the benefit of the compiler/optimizer, but also for the benefit of human reviewers.

> 
> And the 32bits build warning goes away with this:
> 
> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> index d7624d18c8..41328b7530 100644
> --- a/lib/vhost/virtio_net.c
> +++ b/lib/vhost/virtio_net.c
> @@ -1906,7 +1906,7 @@ vhost_enqueue_async_packed(struct virtio_net *dev,
>         uint16_t buf_id = 0;
>         uint32_t len = 0;
>         uint16_t desc_count = 0;
> -       uint64_t size = pkt->pkt_len + sizeof(struct
> virtio_net_hdr_mrg_rxbuf);
> +       uint64_t size = (uint64_t)pkt->pkt_len + sizeof(struct
> virtio_net_hdr_mrg_rxbuf);

Yes, but performing a 64 bit addition instead of a 32 bit addition has a (very small) cost for 32 bit arch.

And regardless of this cost for 32 bit arch; if we know that size cannot exceed UINT32_MAX, it should be changed to uint32_t.

>         uint32_t buffer_len[vq->size];
>         uint16_t buffer_buf_id[vq->size];
>         uint16_t buffer_desc_count[vq->size];

RE: [PATCH v11 06/16] eal: use prefetch intrinsics

[Morten Brørup]

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Thursday, 24 August 2023 14.06
> 
> On Fri, Aug 11, 2023 at 9:21 PM Tyler Retzlaff
> <roretzla@linux.microsoft.com> wrote:
> >
> > Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
> > and _mm_cldemote intrinsics.
> >
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> > ---
> >  lib/eal/x86/include/rte_prefetch.h | 25 +++++++++++++++++++++----
> >  1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/eal/x86/include/rte_prefetch.h
> b/lib/eal/x86/include/rte_prefetch.h
> > index 7fd01c4..7a6988e 100644
> > --- a/lib/eal/x86/include/rte_prefetch.h
> > +++ b/lib/eal/x86/include/rte_prefetch.h
> > @@ -9,30 +9,38 @@
> >  extern "C" {
> >  #endif
> >
> > +#include <emmintrin.h>
> > +
> >  #include <rte_compat.h>
> >  #include <rte_common.h>
> >  #include "generic/rte_prefetch.h"
> >
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wcast-qual"
> > +
> >  static inline void rte_prefetch0(const volatile void *p)
> >  {
> > -       asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char
> *)p));
> > +       _mm_prefetch((const void *)p, _MM_HINT_T0);
> >  }
> >
> 
> Quite surprisingly, this part (exactly) breaks 32bits build in the
> vhost library:
> 
> ccache cc -Ilib/librte_vhost.a.p -Ilib
> -I../../../git/pub/dpdk.org/main/lib -Ilib/vhost
> -I../../../git/pub/dpdk.org/main/lib/vhost -I.
> -I../../../git/pub/dpdk.org/main -Iconfig
> -I../../../git/pub/dpdk.org/main/config -Ilib/eal/include
> -I../../../git/pub/dpdk.org/main/lib/eal/include
> -Ilib/eal/linux/include
> -I../../../git/pub/dpdk.org/main/lib/eal/linux/include
> -Ilib/eal/x86/include
> -I../../../git/pub/dpdk.org/main/lib/eal/x86/include -Ilib/eal/common
> -I../../../git/pub/dpdk.org/main/lib/eal/common -Ilib/eal
> -I../../../git/pub/dpdk.org/main/lib/eal -Ilib/kvargs
> -I../../../git/pub/dpdk.org/main/lib/kvargs -Ilib/log
> -I../../../git/pub/dpdk.org/main/lib/log -Ilib/metrics
> -I../../../git/pub/dpdk.org/main/lib/metrics -Ilib/telemetry
> -I../../../git/pub/dpdk.org/main/lib/telemetry -Ilib/ethdev
> -I../../../git/pub/dpdk.org/main/lib/ethdev -Ilib/net
> -I../../../git/pub/dpdk.org/main/lib/net -Ilib/mbuf
> -I../../../git/pub/dpdk.org/main/lib/mbuf -Ilib/mempool
> -I../../../git/pub/dpdk.org/main/lib/mempool -Ilib/ring
> -I../../../git/pub/dpdk.org/main/lib/ring -Ilib/meter
> -I../../../git/pub/dpdk.org/main/lib/meter -Ilib/cryptodev
> -I../../../git/pub/dpdk.org/main/lib/cryptodev -Ilib/rcu
> -I../../../git/pub/dpdk.org/main/lib/rcu -Ilib/hash
> -I../../../git/pub/dpdk.org/main/lib/hash -Ilib/pci
> -I../../../git/pub/dpdk.org/main/lib/pci -Ilib/dmadev
> -I../../../git/pub/dpdk.org/main/lib/dmadev -fdiagnostics-color=always
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11
> -O2 -g -include rte_config.h -Wcast-qual -Wdeprecated -Wformat
> -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
> -Wno-missing-field-initializers -Wno-zero-length-bounds
> -Wno-pointer-to-int-cast -D_GNU_SOURCE -m32 -fPIC -march=native -mrtm
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> -DVHOST_GCC_UNROLL_PRAGMA -fno-strict-aliasing -DVHOST_HAS_VDUSE
> -DRTE_LOG_DEFAULT_LOGTYPE=lib.vhost -MD -MQ
> lib/librte_vhost.a.p/vhost_virtio_net.c.o -MF
> lib/librte_vhost.a.p/vhost_virtio_net.c.o.d -o
> lib/librte_vhost.a.p/vhost_virtio_net.c.o -c
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c
> In function ‘mbuf_to_desc’,
>     inlined from ‘vhost_enqueue_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
>     inlined from ‘virtio_dev_rx_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
>     inlined from ‘virtio_dev_rx_async_submit_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1230:18: error:
> ‘buf_vec[0].buf_addr’ may be used uninitialized
> [-Werror=maybe-uninitialized]
>  1230 |         buf_addr = buf_vec[vec_idx].buf_addr;
>       |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
> ‘virtio_dev_rx_async_submit_packed’:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
> ‘buf_vec’ declared here
>  1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
>       |                           ^~~~~~~
> In function ‘mbuf_to_desc’,
>     inlined from ‘vhost_enqueue_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
>     inlined from ‘virtio_dev_rx_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
>     inlined from ‘virtio_dev_rx_async_submit_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1231:18: error:
> ‘buf_vec[0].buf_iova’ may be used uninitialized
> [-Werror=maybe-uninitialized]
>  1231 |         buf_iova = buf_vec[vec_idx].buf_iova;
>       |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
> ‘virtio_dev_rx_async_submit_packed’:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
> ‘buf_vec’ declared here
>  1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
>       |                           ^~~~~~~
> In function ‘mbuf_to_desc’,
>     inlined from ‘vhost_enqueue_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1948:6,
>     inlined from ‘virtio_dev_rx_async_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1965:6,
>     inlined from ‘virtio_dev_rx_async_submit_packed’ at
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:2127:7:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1232:35: error:
> ‘buf_vec[0].buf_len’ may be used uninitialized
> [-Werror=maybe-uninitialized]
>  1232 |         buf_len = buf_vec[vec_idx].buf_len;
>       |                   ~~~~~~~~~~~~~~~~^~~~~~~~
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c: In function
> ‘virtio_dev_rx_async_submit_packed’:
> ../../../git/pub/dpdk.org/main/lib/vhost/virtio_net.c:1963:27: note:
> ‘buf_vec’ declared here
>  1963 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
>       |                           ^~~~~~~
> cc1: all warnings being treated as errors
> ninja: build stopped: subcommand failed.
> 
> I had a look at the vhost library and I think the compiler thinks size may be
> 0.

In 32 bit architecture, "size" could be zero, ref. line 1909:

uint64_t size = pkt->pkt_len + sizeof(struct virtio_net_hdr_mrg_rxbuf);

The values on both sides of the addition are 32 bit unsigned, so the addition will be performed as 32 bit unsigned, and the result could in theory be 0. Casting one of them to 64 bit, e.g. (uint64_t)sizeof(struct virtio_net_hdr_mrg_rxbuf), might fix the warning if the compiler is clever enough to know that adding a non-zero 64 bit value to any 32 bit value cannot give zero as the result.

Side note, off track: Why is "size" uint64_t, wouldn't uint32_t suffice?

> Changing the loop on size with a do { } while (size > 0); resolves the
> warning.
> I can post a change for this, as we hit a similar issue in the past
> and the code does not make sense comparing size on the first iteration
> of this loop.
> 
> However, I am a bit puzzled why the prefetch change makes the compiler
> consider this loop differently.
> We have the same constructs everywhere in this library and x86_64
> builds are fine...

That is indeed the relevant question here!

Perhaps the compiler somehow ignores the "const" part of the parameter given to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?

> 
> 
> 
> --
> David Marchand

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[David Marchand]

On Thu, Aug 24, 2023 at 2:47 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: David Marchand [mailto:david.marchand@redhat.com]
> > However, I am a bit puzzled why the prefetch change makes the compiler
> > consider this loop differently.
> > We have the same constructs everywhere in this library and x86_64
> > builds are fine...
>
> That is indeed the relevant question here!
>
> Perhaps the compiler somehow ignores the "const" part of the parameter given to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?

It is possible to reproduce the issue with current DPDK tree (with
existing prefetch implementation in asm) and removing all
rte_prefetch0 calls from the async rx path:

diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
index d7624d18c8..6f941cf27d 100644
--- a/lib/vhost/virtio_net.c
+++ b/lib/vhost/virtio_net.c
@@ -748,8 +748,6 @@ map_one_desc(struct virtio_net *dev, struct
vhost_virtqueue *vq,
                if (unlikely(!desc_addr))
                        return -1;

-               rte_prefetch0((void *)(uintptr_t)desc_addr);
-
                buf_vec[vec_id].buf_iova = desc_iova;
                buf_vec[vec_id].buf_addr = desc_addr;
                buf_vec[vec_id].buf_len  = desc_chunck_len;
@@ -1808,8 +1806,6 @@ virtio_dev_rx_async_submit_split(struct
virtio_net *dev, struct vhost_virtqueue
         */
        avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);

-       rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
-
        async_iter_reset(async);

        for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
@@ -1997,7 +1993,6 @@ virtio_dev_rx_async_packed_batch_enqueue(struct
virtio_net *dev,
        uint16_t i;

        vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
-               rte_prefetch0((void *)(uintptr_t)desc_addrs[i]);
                desc = vhost_iova_to_vva(dev, vq, desc_addrs[i],
&lens[i], VHOST_ACCESS_RW);
                hdrs[i] = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc;
                lens[i] = pkts[i]->pkt_len +
@@ -2106,8 +2101,6 @@ virtio_dev_rx_async_submit_packed(struct
virtio_net *dev, struct vhost_virtqueue
        uint16_t i;

        do {
-               rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
-
                if (count - pkt_idx >= PACKED_BATCH_SIZE) {
                        if (!virtio_dev_rx_async_packed_batch(dev, vq,
&pkts[pkt_idx],
                                        dma_id, vchan_id)) {


If any prefetch is left, the warning disappears.
So the asm usage probably impacts/disables some compiler feature, for
this code path.


-- 
David Marchand

RE: [PATCH v11 06/16] eal: use prefetch intrinsics

[Morten Brørup]

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Thursday, 24 August 2023 16.18
> 
> On Thu, Aug 24, 2023 at 2:47 PM Morten Brørup <mb@smartsharesystems.com>
> wrote:
> > > From: David Marchand [mailto:david.marchand@redhat.com]
> > > However, I am a bit puzzled why the prefetch change makes the compiler
> > > consider this loop differently.
> > > We have the same constructs everywhere in this library and x86_64
> > > builds are fine...
> >
> > That is indeed the relevant question here!
> >
> > Perhaps the compiler somehow ignores the "const" part of the parameter given
> to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?
> 
> It is possible to reproduce the issue with current DPDK tree (with
> existing prefetch implementation in asm) and removing all
> rte_prefetch0 calls from the async rx path:
> 
> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> index d7624d18c8..6f941cf27d 100644
> --- a/lib/vhost/virtio_net.c
> +++ b/lib/vhost/virtio_net.c
> @@ -748,8 +748,6 @@ map_one_desc(struct virtio_net *dev, struct
> vhost_virtqueue *vq,
>                 if (unlikely(!desc_addr))
>                         return -1;
> 
> -               rte_prefetch0((void *)(uintptr_t)desc_addr);
> -
>                 buf_vec[vec_id].buf_iova = desc_iova;
>                 buf_vec[vec_id].buf_addr = desc_addr;
>                 buf_vec[vec_id].buf_len  = desc_chunck_len;
> @@ -1808,8 +1806,6 @@ virtio_dev_rx_async_submit_split(struct
> virtio_net *dev, struct vhost_virtqueue
>          */
>         avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);
> 
> -       rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
> -
>         async_iter_reset(async);
> 
>         for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
> @@ -1997,7 +1993,6 @@ virtio_dev_rx_async_packed_batch_enqueue(struct
> virtio_net *dev,
>         uint16_t i;
> 
>         vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> -               rte_prefetch0((void *)(uintptr_t)desc_addrs[i]);
>                 desc = vhost_iova_to_vva(dev, vq, desc_addrs[i],
> &lens[i], VHOST_ACCESS_RW);
>                 hdrs[i] = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc;
>                 lens[i] = pkts[i]->pkt_len +
> @@ -2106,8 +2101,6 @@ virtio_dev_rx_async_submit_packed(struct
> virtio_net *dev, struct vhost_virtqueue
>         uint16_t i;
> 
>         do {
> -               rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
> -
>                 if (count - pkt_idx >= PACKED_BATCH_SIZE) {
>                         if (!virtio_dev_rx_async_packed_batch(dev, vq,
> &pkts[pkt_idx],
>                                         dma_id, vchan_id)) {
> 
> 
> If any prefetch is left, the warning disappears.
> So the asm usage probably impacts/disables some compiler feature, for
> this code path.

Perhaps any asm usage causes the compiler to assume that any memory might have been modified, which then causes the compiler to not warn about the use of potentially uninitialized variables.

If so, then compiling other code using asm might also not omit warnings about potentially uninitialized variables where it otherwise should have.

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[Tyler Retzlaff]

On Thu, Aug 24, 2023 at 04:18:06PM +0200, David Marchand wrote:
> On Thu, Aug 24, 2023 at 2:47 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > From: David Marchand [mailto:david.marchand@redhat.com]
> > > However, I am a bit puzzled why the prefetch change makes the compiler
> > > consider this loop differently.
> > > We have the same constructs everywhere in this library and x86_64
> > > builds are fine...
> >
> > That is indeed the relevant question here!
> >
> > Perhaps the compiler somehow ignores the "const" part of the parameter given to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?
> 
> It is possible to reproduce the issue with current DPDK tree (with
> existing prefetch implementation in asm) and removing all
> rte_prefetch0 calls from the async rx path:
> 
> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> index d7624d18c8..6f941cf27d 100644
> --- a/lib/vhost/virtio_net.c
> +++ b/lib/vhost/virtio_net.c
> @@ -748,8 +748,6 @@ map_one_desc(struct virtio_net *dev, struct
> vhost_virtqueue *vq,
>                 if (unlikely(!desc_addr))
>                         return -1;
> 
> -               rte_prefetch0((void *)(uintptr_t)desc_addr);
> -
>                 buf_vec[vec_id].buf_iova = desc_iova;
>                 buf_vec[vec_id].buf_addr = desc_addr;
>                 buf_vec[vec_id].buf_len  = desc_chunck_len;
> @@ -1808,8 +1806,6 @@ virtio_dev_rx_async_submit_split(struct
> virtio_net *dev, struct vhost_virtqueue
>          */
>         avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);
> 
> -       rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
> -
>         async_iter_reset(async);
> 
>         for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
> @@ -1997,7 +1993,6 @@ virtio_dev_rx_async_packed_batch_enqueue(struct
> virtio_net *dev,
>         uint16_t i;
> 
>         vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> -               rte_prefetch0((void *)(uintptr_t)desc_addrs[i]);
>                 desc = vhost_iova_to_vva(dev, vq, desc_addrs[i],
> &lens[i], VHOST_ACCESS_RW);
>                 hdrs[i] = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc;
>                 lens[i] = pkts[i]->pkt_len +
> @@ -2106,8 +2101,6 @@ virtio_dev_rx_async_submit_packed(struct
> virtio_net *dev, struct vhost_virtqueue
>         uint16_t i;
> 
>         do {
> -               rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
> -
>                 if (count - pkt_idx >= PACKED_BATCH_SIZE) {
>                         if (!virtio_dev_rx_async_packed_batch(dev, vq,
> &pkts[pkt_idx],
>                                         dma_id, vchan_id)) {
> 
> 
> If any prefetch is left, the warning disappears.
> So the asm usage probably impacts/disables some compiler feature, for
> this code path.

So as an aside one of the reasons often cited as to why intrinsics are
preferred over inline asm is that inline asm can't be considered when
the compiler performs optimization. It could be that when moving to use
the intrinsics the scope of what can be optimized around the prefetch0
calls can be used for optimization leading to the observations here.

Ty

> 
> 
> -- 
> David Marchand

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[David Marchand]

On Thu, Aug 24, 2023 at 5:54 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> On Thu, Aug 24, 2023 at 04:18:06PM +0200, David Marchand wrote:
> > On Thu, Aug 24, 2023 at 2:47 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > From: David Marchand [mailto:david.marchand@redhat.com]
> > > > However, I am a bit puzzled why the prefetch change makes the compiler
> > > > consider this loop differently.
> > > > We have the same constructs everywhere in this library and x86_64
> > > > builds are fine...
> > >
> > > That is indeed the relevant question here!
> > >
> > > Perhaps the compiler somehow ignores the "const" part of the parameter given to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?
> >
> > It is possible to reproduce the issue with current DPDK tree (with
> > existing prefetch implementation in asm) and removing all
> > rte_prefetch0 calls from the async rx path:
> >
> > diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> > index d7624d18c8..6f941cf27d 100644
> > --- a/lib/vhost/virtio_net.c
> > +++ b/lib/vhost/virtio_net.c
> > @@ -748,8 +748,6 @@ map_one_desc(struct virtio_net *dev, struct
> > vhost_virtqueue *vq,
> >                 if (unlikely(!desc_addr))
> >                         return -1;
> >
> > -               rte_prefetch0((void *)(uintptr_t)desc_addr);
> > -
> >                 buf_vec[vec_id].buf_iova = desc_iova;
> >                 buf_vec[vec_id].buf_addr = desc_addr;
> >                 buf_vec[vec_id].buf_len  = desc_chunck_len;
> > @@ -1808,8 +1806,6 @@ virtio_dev_rx_async_submit_split(struct
> > virtio_net *dev, struct vhost_virtqueue
> >          */
> >         avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);
> >
> > -       rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
> > -
> >         async_iter_reset(async);
> >
> >         for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
> > @@ -1997,7 +1993,6 @@ virtio_dev_rx_async_packed_batch_enqueue(struct
> > virtio_net *dev,
> >         uint16_t i;
> >
> >         vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> > -               rte_prefetch0((void *)(uintptr_t)desc_addrs[i]);
> >                 desc = vhost_iova_to_vva(dev, vq, desc_addrs[i],
> > &lens[i], VHOST_ACCESS_RW);
> >                 hdrs[i] = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc;
> >                 lens[i] = pkts[i]->pkt_len +
> > @@ -2106,8 +2101,6 @@ virtio_dev_rx_async_submit_packed(struct
> > virtio_net *dev, struct vhost_virtqueue
> >         uint16_t i;
> >
> >         do {
> > -               rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
> > -
> >                 if (count - pkt_idx >= PACKED_BATCH_SIZE) {
> >                         if (!virtio_dev_rx_async_packed_batch(dev, vq,
> > &pkts[pkt_idx],
> >                                         dma_id, vchan_id)) {
> >
> >
> > If any prefetch is left, the warning disappears.
> > So the asm usage probably impacts/disables some compiler feature, for
> > this code path.
>
> So as an aside one of the reasons often cited as to why intrinsics are
> preferred over inline asm is that inline asm can't be considered when
> the compiler performs optimization. It could be that when moving to use
> the intrinsics the scope of what can be optimized around the prefetch0
> calls can be used for optimization leading to the observations here.

Agreed.
While we decide the next steps on the vhost library, and for making
progress on this series, I decided to keep the previous asm
implementation and put intrinsics under a #ifdef MSVC.


-- 
David Marchand

Re: [PATCH v11 06/16] eal: use prefetch intrinsics

[Tyler Retzlaff]

On Fri, Aug 25, 2023 at 10:44:01AM +0200, David Marchand wrote:
> On Thu, Aug 24, 2023 at 5:54 PM Tyler Retzlaff
> <roretzla@linux.microsoft.com> wrote:
> >
> > On Thu, Aug 24, 2023 at 04:18:06PM +0200, David Marchand wrote:
> > > On Thu, Aug 24, 2023 at 2:47 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > > From: David Marchand [mailto:david.marchand@redhat.com]
> > > > > However, I am a bit puzzled why the prefetch change makes the compiler
> > > > > consider this loop differently.
> > > > > We have the same constructs everywhere in this library and x86_64
> > > > > builds are fine...
> > > >
> > > > That is indeed the relevant question here!
> > > >
> > > > Perhaps the compiler somehow ignores the "const" part of the parameter given to the "asm" (in rte_prefetch0()) for 64 bit arch, but not for 32 bit arch?
> > >
> > > It is possible to reproduce the issue with current DPDK tree (with
> > > existing prefetch implementation in asm) and removing all
> > > rte_prefetch0 calls from the async rx path:
> > >
> > > diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> > > index d7624d18c8..6f941cf27d 100644
> > > --- a/lib/vhost/virtio_net.c
> > > +++ b/lib/vhost/virtio_net.c
> > > @@ -748,8 +748,6 @@ map_one_desc(struct virtio_net *dev, struct
> > > vhost_virtqueue *vq,
> > >                 if (unlikely(!desc_addr))
> > >                         return -1;
> > >
> > > -               rte_prefetch0((void *)(uintptr_t)desc_addr);
> > > -
> > >                 buf_vec[vec_id].buf_iova = desc_iova;
> > >                 buf_vec[vec_id].buf_addr = desc_addr;
> > >                 buf_vec[vec_id].buf_len  = desc_chunck_len;
> > > @@ -1808,8 +1806,6 @@ virtio_dev_rx_async_submit_split(struct
> > > virtio_net *dev, struct vhost_virtqueue
> > >          */
> > >         avail_head = __atomic_load_n(&vq->avail->idx, __ATOMIC_ACQUIRE);
> > >
> > > -       rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
> > > -
> > >         async_iter_reset(async);
> > >
> > >         for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
> > > @@ -1997,7 +1993,6 @@ virtio_dev_rx_async_packed_batch_enqueue(struct
> > > virtio_net *dev,
> > >         uint16_t i;
> > >
> > >         vhost_for_each_try_unroll(i, 0, PACKED_BATCH_SIZE) {
> > > -               rte_prefetch0((void *)(uintptr_t)desc_addrs[i]);
> > >                 desc = vhost_iova_to_vva(dev, vq, desc_addrs[i],
> > > &lens[i], VHOST_ACCESS_RW);
> > >                 hdrs[i] = (struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc;
> > >                 lens[i] = pkts[i]->pkt_len +
> > > @@ -2106,8 +2101,6 @@ virtio_dev_rx_async_submit_packed(struct
> > > virtio_net *dev, struct vhost_virtqueue
> > >         uint16_t i;
> > >
> > >         do {
> > > -               rte_prefetch0(&vq->desc_packed[vq->last_avail_idx]);
> > > -
> > >                 if (count - pkt_idx >= PACKED_BATCH_SIZE) {
> > >                         if (!virtio_dev_rx_async_packed_batch(dev, vq,
> > > &pkts[pkt_idx],
> > >                                         dma_id, vchan_id)) {
> > >
> > >
> > > If any prefetch is left, the warning disappears.
> > > So the asm usage probably impacts/disables some compiler feature, for
> > > this code path.
> >
> > So as an aside one of the reasons often cited as to why intrinsics are
> > preferred over inline asm is that inline asm can't be considered when
> > the compiler performs optimization. It could be that when moving to use
> > the intrinsics the scope of what can be optimized around the prefetch0
> > calls can be used for optimization leading to the observations here.
> 
> Agreed.
> While we decide the next steps on the vhost library, and for making
> progress on this series, I decided to keep the previous asm
> implementation and put intrinsics under a #ifdef MSVC.

I'm fine with this, we can micro-optimize things out of the MSVC only
blocks later in more targeted changes. These kinds of little things is
why earlier versions of the series only used intrinsics for MSVC bah!

Thanks

> 
> -- 
> David Marchand

[PATCH v11 07/16] eal: use byte swap intrinsics

[Tyler Retzlaff]

Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 11 +++++++++++
 lib/eal/x86/include/rte_byteorder.h     |  4 ++++
 2 files changed, 15 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
 #endif /* __DOXYGEN__ */
 
 #ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
 #define rte_bswap16(x) __builtin_bswap16(x)
 #endif
@@ -241,6 +242,16 @@
 #define rte_bswap32(x) __builtin_bswap32(x)
 
 #define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
 
 #endif
 
diff --git a/lib/eal/x86/include/rte_byteorder.h b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 
+#ifndef RTE_TOOLCHAIN_MSVC
 /*
  * An architecture-optimized byte swap for a 16-bit value.
  *
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 				   rte_arch_bswap16(x)))
 #endif
 #endif
+#endif
 
 #define rte_cpu_to_le_16(x) (x)
 #define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
 #define rte_be_to_cpu_32(x) rte_bswap32(x)
 #define rte_be_to_cpu_64(x) rte_bswap64(x)
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifdef RTE_ARCH_I686
 #include "rte_byteorder_32.h"
 #else
 #include "rte_byteorder_64.h"
 #endif
+#endif
 
 #ifdef __cplusplus
 }
-- 
1.8.3.1

Re: [PATCH v11 07/16] eal: use byte swap intrinsics

[David Marchand]

On Fri, Aug 11, 2023 at 9:21 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> Inline assembly is not supported for MSVC x64 instead expand
> use _byteswap_u{ushort,ulong,uint64} intrinsics instead.
>
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>

For the record, I rebased this patch on top of
https://patchwork.dpdk.org/project/dpdk/patch/20230824093356.1476716-1-david.marchand@redhat.com/
and moved blocks under a single #ifdef RTE_FORCE_INTRINSICS.


-- 
David Marchand

[PATCH v11 08/16] eal: hide GCC extension based alignment markers

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs used as alignment
markers.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 15765b4..2f464e3 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 
 /*********** Structure alignment markers ********/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /** Generic marker for any place in a structure. */
 __extension__ typedef void    *RTE_MARKER[0];
 /** Marker for 1B alignment in a structure. */
@@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /** Marker for 8B alignment in a structure. */
 __extension__ typedef uint64_t RTE_MARKER64[0];
 
+#endif
+
 /**
  * Combines 32b inputs most significant set bits into the least
  * significant bits to construct a value with the same MSBs as x
-- 
1.8.3.1

[PATCH v11 09/16] eal: hide typedefs based on GCC vector extensions

[Tyler Retzlaff]

When compiling with MSVC don't expose typedefs based on GCC vector
extensions.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_vect.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h
index 3fec2bf..777510c 100644
--- a/lib/eal/include/generic/rte_vect.h
+++ b/lib/eal/include/generic/rte_vect.h
@@ -17,6 +17,8 @@
 
 #include <rte_compat.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /* Unsigned vector types */
 
 /**
@@ -186,6 +188,8 @@
  */
 typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
 
+#endif
+
 /**
  * The max SIMD bitwidth value to limit vector path selection.
  */
-- 
1.8.3.1

[PATCH v11 10/16] eal: expand most macros to empty when using MSVC

[Tyler Retzlaff]

For now expand a lot of common rte macros empty. The catch here is we
need to test that most of the macros do what they should but at the same
time they are blocking work needed to bootstrap of the unit tests.

Later we will return and provide (where possible) expansions that work
correctly for msvc and where not possible provide some alternate macros
to achieve the same outcome.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_branch_prediction.h |  8 +++++
 lib/eal/include/rte_common.h            | 54 +++++++++++++++++++++++++++++++++
 lib/eal/include/rte_compat.h            | 20 ++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h
index 414cd92..c0356ca 100644
--- a/lib/eal/include/rte_branch_prediction.h
+++ b/lib/eal/include/rte_branch_prediction.h
@@ -24,7 +24,11 @@
  *      do_stuff();
  */
 #ifndef likely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define likely(x)	(!!(x))
+#else
 #define likely(x)	__builtin_expect(!!(x), 1)
+#endif
 #endif /* likely */
 
 /**
@@ -37,7 +41,11 @@
  *      do_stuff();
  */
 #ifndef unlikely
+#ifdef RTE_TOOLCHAIN_MSVC
+#define unlikely(x)	(!!(x))
+#else
 #define unlikely(x)	__builtin_expect(!!(x), 0)
+#endif
 #endif /* unlikely */
 
 #ifdef __cplusplus
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 2f464e3..b087532 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -41,6 +41,10 @@
 #define RTE_STD_C11
 #endif
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __extension__
+#endif
+
 /*
  * RTE_TOOLCHAIN_GCC is defined if the target is built with GCC,
  * while a host application (like pmdinfogen) may have another compiler.
@@ -65,7 +69,11 @@
 /**
  * Force alignment
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_aligned(a)
+#else
 #define __rte_aligned(a) __attribute__((__aligned__(a)))
+#endif
 
 #ifdef RTE_ARCH_STRICT_ALIGN
 typedef uint64_t unaligned_uint64_t __rte_aligned(1);
@@ -80,16 +88,29 @@
 /**
  * Force a structure to be packed
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_packed
+#else
 #define __rte_packed __attribute__((__packed__))
+#endif
 
 /**
  * Macro to mark a type that is not subject to type-based aliasing rules
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_may_alias
+#else
 #define __rte_may_alias __attribute__((__may_alias__))
+#endif
 
 /******* Macro to mark functions and fields scheduled for removal *****/
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_deprecated
+#define __rte_deprecated_msg(msg)
+#else
 #define __rte_deprecated	__attribute__((__deprecated__))
 #define __rte_deprecated_msg(msg)	__attribute__((__deprecated__(msg)))
+#endif
 
 /**
  *  Macro to mark macros and defines scheduled for removal
@@ -110,14 +131,22 @@
 /**
  * Force symbol to be generated even if it appears to be unused.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_used
+#else
 #define __rte_used __attribute__((used))
+#endif
 
 /*********** Macros to eliminate unused variable warnings ********/
 
 /**
  * short definition to mark a function parameter unused
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_unused
+#else
 #define __rte_unused __attribute__((__unused__))
+#endif
 
 /**
  * Mark pointer as restricted with regard to pointer aliasing.
@@ -141,6 +170,9 @@
  * even if the underlying stdio implementation is ANSI-compliant,
  * so this must be overridden.
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_format_printf(format_index, first_arg)
+#else
 #if RTE_CC_IS_GNU
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(gnu_printf, format_index, first_arg)))
@@ -148,6 +180,7 @@
 #define __rte_format_printf(format_index, first_arg) \
 	__attribute__((format(printf, format_index, first_arg)))
 #endif
+#endif
 
 /**
  * Tells compiler that the function returns a value that points to
@@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 /**
  * Hint never returning function
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_noreturn
+#else
 #define __rte_noreturn __attribute__((noreturn))
+#endif
 
 /**
  * Issue a warning in case the function's return value is ignored.
@@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  }
  * @endcode
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_warn_unused_result
+#else
 #define __rte_warn_unused_result __attribute__((warn_unused_result))
+#endif
 
 /**
  * Force a function to be inlined
  */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_always_inline
+#else
 #define __rte_always_inline inline __attribute__((always_inline))
+#endif
 
 /**
  * Force a function to be noinlined
@@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 #define RTE_CACHE_LINE_MIN_SIZE 64
 
 /** Force alignment to cache line. */
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_cache_aligned
+#else
 #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
+#endif
 
 /** Force minimum cache line alignment. */
 #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE)
@@ -812,6 +861,10 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
  *  struct wrapper *w = container_of(x, struct wrapper, c);
  */
 #ifndef container_of
+#ifdef RTE_TOOLCHAIN_MSVC
+#define container_of(ptr, type, member) \
+			((type *)((uintptr_t)(ptr) - offsetof(type, member)))
+#else
 #define container_of(ptr, type, member)	__extension__ ({		\
 			const typeof(((type *)0)->member) *_ptr = (ptr); \
 			__rte_unused type *_target_ptr =	\
@@ -819,6 +872,7 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
 			(type *)(((uintptr_t)_ptr) - offsetof(type, member)); \
 		})
 #endif
+#endif
 
 /** Swap two variables. */
 #define RTE_SWAP(a, b) \
diff --git a/lib/eal/include/rte_compat.h b/lib/eal/include/rte_compat.h
index fc9fbaa..716bc03 100644
--- a/lib/eal/include/rte_compat.h
+++ b/lib/eal/include/rte_compat.h
@@ -12,14 +12,22 @@
 
 #ifndef ALLOW_EXPERIMENTAL_API
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
 section(".text.experimental")))
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_experimental
+#else
 #define __rte_experimental \
 __attribute__((section(".text.experimental")))
+#endif
 
 #endif
 
@@ -30,23 +38,35 @@
 
 #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((error("Symbol is not public ABI"), \
 section(".text.internal")))
+#endif
 
 #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 _Pragma("GCC diagnostic push") \
 _Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
 __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
 section(".text.internal"))) \
 _Pragma("GCC diagnostic pop")
+#endif
 
 #else
 
+#ifdef RTE_TOOLCHAIN_MSVC
+#define __rte_internal
+#else
 #define __rte_internal \
 __attribute__((section(".text.internal")))
+#endif
 
 #endif
 
-- 
1.8.3.1

[PATCH v11 11/16] eal: exclude exposure of rte atomic APIs for MSVC builds

[Tyler Retzlaff]

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_atomic.h | 7 +++++++
 lib/eal/x86/include/rte_atomic.h     | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index 2d36eb0..b14e9fe 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -161,6 +161,8 @@
 
 /*------------------------- 16 bit atomic operations -------------------------*/
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Atomic compare and set.
  *
@@ -1068,8 +1070,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 }
 #endif
 
+#endif
+
 /*------------------------ 128 bit atomic operations -------------------------*/
 
+
 /**
  * 128-bit integer structure.
  */
@@ -1079,8 +1084,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
 	union {
 		uint64_t val[2];
 #ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
 		__extension__ __int128 int128;
 #endif
+#endif
 	};
 } __rte_aligned(16) rte_int128_t;
 
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 7aba1c3..9ba61f8 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
 
 #define rte_io_rmb() rte_compiler_barrier()
 
+#ifndef RTE_TOOLCHAIN_MSVC
+
 /**
  * Synchronization fence between threads based on the specified memory order.
  *
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
 #include "rte_atomic_64.h"
 #endif
 
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.3.1

[PATCH v11 12/16] eal: always define MSVC as little endian

[Tyler Retzlaff]

The MSVC compiler does not target big endian platforms so define
little endian always.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/generic/rte_byteorder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h
index 1e32a1b..375f118 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -45,6 +45,8 @@
 #define RTE_BYTE_ORDER RTE_BIG_ENDIAN
 #elif defined __LITTLE_ENDIAN__
 #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
+#elif defined RTE_TOOLCHAIN_MSVC
+#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
 #endif
 #if !defined(RTE_BYTE_ORDER)
 #error Unknown endianness.
-- 
1.8.3.1

[PATCH v11 13/16] eal: do not define typeof macro when building with MSVC

[Tyler Retzlaff]

When building with MSVC do not assume typeof is a macro and don't
define a typeof macro that conflicts with C23 typeof keyword.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index b087532..cf7d8d8 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -24,9 +24,11 @@
 /* OS specific include */
 #include <rte_os.h>
 
+#ifndef RTE_TOOLCHAIN_MSVC
 #ifndef typeof
 #define typeof __typeof__
 #endif
+#endif
 
 #ifndef __cplusplus
 #ifndef asm
-- 
1.8.3.1

[PATCH v11 14/16] log: use standard ternary operator instead of GCC extension

[Tyler Retzlaff]

Use standard ternary operator instead of gcc extension. There is
no concern of side-effects for this evaluation so allow the code
to be portable.

While here update the condition to compare default_log_stream
directly against NULL.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/log/log.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/log/log.c b/lib/log/log.c
index 52c771f..b80725a 100644
--- a/lib/log/log.c
+++ b/lib/log/log.c
@@ -93,7 +93,7 @@ struct log_cur_msg {
 		 * of stderr, even if the application closes and
 		 * reopens it.
 		 */
-		return default_log_stream ? : stderr;
+		return default_log_stream != NULL ? default_log_stream : stderr;
 	}
 	return f;
 }
-- 
1.8.3.1

RE: [PATCH v11 14/16] log: use standard ternary operator instead of GCC extension

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 11 August 2023 21.21
> 
> Use standard ternary operator instead of gcc extension. There is
> no concern of side-effects for this evaluation so allow the code
> to be portable.
> 
> While here update the condition to compare default_log_stream
> directly against NULL.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/log/log.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/log/log.c b/lib/log/log.c
> index 52c771f..b80725a 100644
> --- a/lib/log/log.c
> +++ b/lib/log/log.c
> @@ -93,7 +93,7 @@ struct log_cur_msg {
>  		 * of stderr, even if the application closes and
>  		 * reopens it.
>  		 */
> -		return default_log_stream ? : stderr;

I didn't know this GCC extension.

Someone please consider disallowing this in checkpatches.


> +		return default_log_stream != NULL ? default_log_stream : stderr;
>  	}
>  	return f;
>  }
> --
> 1.8.3.1

Reviewed-by: Morten Brørup <mb@smartsharesystems.com>

Re: [PATCH v11 14/16] log: use standard ternary operator instead of GCC extension

[Stephen Hemminger]

On Mon, 25 Sep 2023 08:24:58 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> I didn't know this GCC extension.
> 
> Someone please consider disallowing this in checkpatches.

We don't need to make checkpatch more complex.
When MSVC is in build system, it will catch it 

[PATCH v11 15/16] eal: use standard ternary operator instead of GCC extension

[Tyler Retzlaff]

Use standard ternary operator instead of gcc extension. There is
no concern of side-effects for this evaluation so allow the code
to be portable.

While here update the condition to compare default_log_stream
directly against NULL.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/common/eal_common_hexdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/eal/common/eal_common_hexdump.c b/lib/eal/common/eal_common_hexdump.c
index 63bbbdc..6fd6e21 100644
--- a/lib/eal/common/eal_common_hexdump.c
+++ b/lib/eal/common/eal_common_hexdump.c
@@ -15,7 +15,7 @@
 	char line[LINE_LEN];	/* space needed 8+16*3+3+16 == 75 */
 
 	fprintf(f, "%s at [%p], len=%u\n",
-		title ? : "  Dump data", data, len);
+		title != NULL ? title : "  Dump data", data, len);
 	ofs = 0;
 	while (ofs < len) {
 		/* format the line in the buffer */
-- 
1.8.3.1

RE: [PATCH v11 15/16] eal: use standard ternary operator instead of GCC extension

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 11 August 2023 21.21
> 
> Use standard ternary operator instead of gcc extension. There is
> no concern of side-effects for this evaluation so allow the code
> to be portable.
> 
> While here update the condition to compare default_log_stream
> directly against NULL.
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
>  lib/eal/common/eal_common_hexdump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/eal/common/eal_common_hexdump.c
> b/lib/eal/common/eal_common_hexdump.c
> index 63bbbdc..6fd6e21 100644
> --- a/lib/eal/common/eal_common_hexdump.c
> +++ b/lib/eal/common/eal_common_hexdump.c
> @@ -15,7 +15,7 @@
>  	char line[LINE_LEN];	/* space needed 8+16*3+3+16 == 75 */
> 
>  	fprintf(f, "%s at [%p], len=%u\n",
> -		title ? : "  Dump data", data, len);
> +		title != NULL ? title : "  Dump data", data, len);
>  	ofs = 0;
>  	while (ofs < len) {
>  		/* format the line in the buffer */
> --
> 1.8.3.1

Reviewed-by: Morten Brørup <mb@smartsharesystems.com>

[PATCH v11 16/16] eal: define priority based ctor dtor for MSVC

[Tyler Retzlaff]

Provide RTE_INIT_PRIO and RTE_FINI_PRIO for MSVC allowing priority
based equivalents to __attribute__(({constructor,destructor})

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/eal/include/rte_common.h | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index cf7d8d8..791ceed 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -214,8 +214,29 @@
  *   Lowest number is the first to run.
  */
 #ifndef RTE_INIT_PRIO /* Allow to override from EAL */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define RTE_INIT_PRIO(func, prio) \
 static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
+#else
+/* definition from the Microsoft CRT */
+typedef int(__cdecl *_PIFV)(void);
+
+#define CTOR_SECTION_LOG ".CRT$XIB"
+#define CTOR_SECTION_BUS ".CRT$XIC"
+#define CTOR_SECTION_CLASS ".CRT$XID"
+#define CTOR_SECTION_LAST ".CRT$XIY"
+
+#define CTOR_PRIORITY_TO_SECTION(priority) CTOR_SECTION_ ## priority
+
+#define RTE_INIT_PRIO(name, priority) \
+	static void name(void); \
+	static int __cdecl name ## _thunk(void) { name(); return 0; } \
+	__pragma(const_seg(CTOR_PRIORITY_TO_SECTION(priority))) \
+	__declspec(allocate(CTOR_PRIORITY_TO_SECTION(priority))) \
+	    _PIFV name ## _pointer = &name ## _thunk; \
+	__pragma(const_seg()) \
+	static void name(void)
+#endif
 #endif
 
 /**
@@ -239,8 +260,24 @@ static void __attribute__((constructor(RTE_PRIO(prio)), used)) func(void)
  *   Lowest number is the last to run.
  */
 #ifndef RTE_FINI_PRIO /* Allow to override from EAL */
+#ifndef RTE_TOOLCHAIN_MSVC
 #define RTE_FINI_PRIO(func, prio) \
 static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
+#else
+#define DTOR_SECTION_LOG "mydtor$B"
+#define DTOR_SECTION_BUS "mydtor$C"
+#define DTOR_SECTION_CLASS "mydtor$D"
+#define DTOR_SECTION_LAST "mydtor$Y"
+
+#define DTOR_PRIORITY_TO_SECTION(priority) DTOR_SECTION_ ## priority
+
+#define RTE_FINI_PRIO(name, priority) \
+	static void name(void); \
+	__pragma(const_seg(DTOR_PRIORITY_TO_SECTION(priority))) \
+	__declspec(allocate(DTOR_PRIORITY_TO_SECTION(priority))) name ## _pointer = &name; \
+	__pragma(const_seg()) \
+	static void name(void)
+#endif
 #endif
 
 /**
-- 
1.8.3.1

RE: [PATCH v11 16/16] eal: define priority based ctor dtor for MSVC

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 11 August 2023 21.21
> 
> Provide RTE_INIT_PRIO and RTE_FINI_PRIO for MSVC allowing priority
> based equivalents to __attribute__(({constructor,destructor})
> 
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---

Acked-by: Morten Brørup <mb@smartsharesystems.com>

Re: [PATCH v11 00/16] msvc integration changes

[David Marchand]

On Fri, Aug 11, 2023 at 9:21 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> In accordance with draft plan
> http://mails.dpdk.org/archives/web/2023-February/002023.html
> introduces conditionally compiled code to enable building with MSVC that
> _does not_ require C99/C11 meaning it can be integrated now.
>
> This series covers minimal changes for item #2 in draft plan for EAL
> dependencies log, kvargs, telemetry and consumed EAL public headers.
>
> Note if any patch in the series requires in-depth discussion I'll
> detach it from this series for separate submission & more focused
> discussion so it doesn't block the entire series.
>
> Note other "common" intrinsics were investigated for viability but
> were not adopted either because they were not available on older
> versions of GCC or because they generate different code for msvc
> vs GCC.

As I mentionned on the prefetch and byteorder patches, I made some
adjustments while rebasing the series.
Hopefully, I broke nothing.

Series applied, thanks Tyler and reviewers.


-- 
David Marchand