> From: Tyler Retzlaff [mailto:roret...@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 <roret...@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.
