build: remove unnecessary AVX2 compiler flag

Since AVX2 is always available at build time, the CC_AVX2_SUPPORT cflag
became equivalent to the RTE_ARCH_X86 one. Therefore, we can just remove
all use

build: remove unnecessary AVX2 compiler flag

Since AVX2 is always available at build time, the CC_AVX2_SUPPORT cflag
became equivalent to the RTE_ARCH_X86 one. Therefore, we can just remove
all use of the flag, replacing it will the RTE_ARCH_X86 one, and also
simplifying the code in a few places where we can merge with other
X86/non-X86 blocks e.g. for providing SSE fallbacks.

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

show more ...

build/x86: remove checks for AVX2 support

In a number of libraries and drivers we have multiple levels of checks
for enabling AVX2 support. In these cases:

* we first check for AVX2 support in the

build/x86: remove checks for AVX2 support

In a number of libraries and drivers we have multiple levels of checks
for enabling AVX2 support. In these cases:

* we first check for AVX2 support in the build-time ISA, i.e. through
the instruction-set/-march flag. If present, we add source file to the
list of sources.
* if not enabled at the minimum instruction-set level, i.e. a
default/generic build, we then check for compiler support for AVX2
and, if available, did a separate build of the AVX2 file using an
additional flag to enable the instruction set.

While this works, and was necessary in older releases, we no longer need
this level of complexity, as all supported DPDK compilers have support
for AVX2. This makes the second check unnecessary.

However, when we look at the effect of the second option above vs the
first, the only real difference is that in the second case, we add an
additional "-mavx2" to the build flags. This flag simply makes the
instruction set available for use, so should be harmless in the case
where the "march" flag already has that instruction set available.
Therefore, we can remove the check for the first case also, and always
use the fallback case with the extra flag.

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

show more ...

config/x86: skip GNU binutils bug check for LLVM

AVX512 was disabled when GNU binutils were missing or had a known bug,
even if LLVM binutils were used for the build,
because binutils-avx512-check.s

config/x86: skip GNU binutils bug check for LLVM

AVX512 was disabled when GNU binutils were missing or had a known bug,
even if LLVM binutils were used for the build,
because binutils-avx512-check.sh was invoked regardless and failed.
In particular, this was the case for FreeBSD with clang (default).
Run the check only when GNU binutils are used.

Fixes: 68b1f1cda5b4 ("build: check AVX512 rather than binutils version")
Cc: stable@dpdk.org

Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...

build/windows: remove separate list of libs

Rather than maintaining a separate list of libraries which are to be
built on windows, use the standard library list and explicitly add to
each library th

build/windows: remove separate list of libs

Rather than maintaining a separate list of libraries which are to be
built on windows, use the standard library list and explicitly add to
each library that is not to be built a check for windows and disable
the library at that per-lib level. As well as shortening the main
lib/meson.build file, this also leads to the build summary at the end of
the meson config run correctly listing the libraries which are not to be
built.

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

show more ...

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
m

lib: remove librte_ prefix from directory names

There is no reason for the DPDK libraries to all have 'librte_' prefix on
the directory names. This prefix makes the directory names longer and also
makes it awkward to add features referring to individual libraries in the
build - should the lib names be specified with or without the prefix.
Therefore, we can just remove the library prefix and use the library's
unique name as the directory name, i.e. 'eal' rather than 'librte_eal'

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

show more ...