path: root/mk/
AgeCommit message (Collapse)Author
2018-11-04mk: disable gcc AVX512F supportYongseok Koh
This is a workaround to prevent a crash, which might be caused by optimization of newer gcc (7.3.0) on Intel Skylake. This disables AVX512F support of gcc by adding -mno-avx512f if it is disabled in DPDK (CONFIG_RTE_ENABLE_AVX512=n). This does not apply to the meson build as that doesn't have such an option but always enable AVX512F whenever supported. Bugzilla ID: 97 Cc: Signed-off-by: Yongseok Koh <>
2018-09-16build: enable ARM NEON flag when __aarch64__ definedHonnappa Nagarahalli
GCC version 4.8.5 does not pre-define __ARM_NEON. NEON is not optional for ArmV8. Hence NEON related code can be enabled when __aarch64__ is defined. Bugzilla ID: 82 Cc: Reported-by: Raslan Darawsheh <> Reported-by: Thomas F Herbert <> Signed-off-by: Honnappa Nagarahalli <> Reviewed-by: Phil Yang <> Reviewed-by: Gavin Hu <> Acked-by: Jerin Jacob <>
2018-01-04mk: use SPDX tag for Intel copyright filesBruce Richardson
Replace the BSD license header with the SPDX tag for Makefiles with only an Intel copyright on them. Signed-off-by: Bruce Richardson <>
2017-11-07eal/x86: revert select optimized memcpy at run-timeXiaoyun Li
Revert the patchset run-time Linking support including the following 3 commits: Fixes: 84cc318424d4 ("eal/x86: select optimized memcpy at run-time") Fixes: c7fbc80fe60f ("test: select memcpy alignment unit at run-time") Fixes: 5f180ae32962 ("efd: move AVX2 lookup in its own compilation unit") The patchset would cause perf drop in vhost/virtio loopback performance test. Because the run-time dispatch must cost at least a function call comparing to the compile-time dispatch. And the reference cpu cycles value is small. And in the test, when using 128-256 bytes packet, it would cause 16%-20% perf drop with mergeble path. When using 256 bytes packet, it would cause 13% perf drop with vector path. Signed-off-by: Xiaoyun Li <>
2017-10-13eal/x86: select optimized memcpy at run-timeXiaoyun Li
This patch dynamically selects functions of memcpy at run-time based on CPU flags that current machine supports. This patch uses function pointers which are bind to the relative functions at constrctor time. In addition, AVX512 instructions set would be compiled only if users config it enabled and the compiler supports it. Signed-off-by: Xiaoyun Li <>
2017-07-04mk: add crypto capability for armv8a and thunderxAshwin Sekhar T K
armv8-a has optional CRYPTO extension which adds the AES, PMULL, SHA1 and SHA2 capabilities. -march=armv8-a+crypto enables code generation for the ARMv8-A architecture together with the optional CRYPTO extensions. Added the following flags to detect the corresponding capability at compile time. * RTE_MACHINE_CPUFLAG_AES * RTE_MACHINE_CPUFLAG_PMULL * RTE_MACHINE_CPUFLAG_SHA1 * RTE_MACHINE_CPUFLAG_SHA2 At run-time, the following flags can be used to detect the capabilities. * RTE_CPUFLAG_AES * RTE_CPUFLAG_PMULL * RTE_CPUFLAG_SHA1 * RTE_CPUFLAG_SHA2 Signed-off-by: Ashwin Sekhar T K <> Reviewed-by: Jan Viktorin <>
2017-04-30config: make AVX and AVX512 configurableZhihong Wang
Making AVX and AVX512 configurable is useful for performance and power testing. The similar kernel patch at AVX512 support like in rte_memcpy has been in DPDK since 16.04, but it's still unproven in rich use cases in hardware. Therefore it's marked as experimental for now, will enable it after enough field test and possible optimization. Signed-off-by: Zhihong Wang <> Reviewed-by: Zhiyong Yang <> Reviewed-by: Yuanhan Liu <>
2016-03-24mk: improve ARM NEON detectionJan Viktorin
The __ARM_NEON declares that the arm_neon.h is available which is not always true for the __ARM_NEON_FP. $ arm-linux-gnueabi-gcc -dM -E - < /dev/null | grep "_FP\|_NEON" #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __VFP_FP__ 1 $ arm-linux-gnueabi-gcc -mfpu=neon -dM -E - < /dev/null | grep "_FP\|_NEON" #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __ARM_NEON__ 1 #define __VFP_FP__ 1 #define __ARM_NEON 1 $ aarch64-linux-gnu-gcc -dM -E - < /dev/null | grep "NEON\|FP" #define __FP_FAST_FMAF 1 #define __ARM_NEON 1 #define __FP_FAST_FMA 1 $ aarch64-thunderx-linux-gnu-gcc -dM -E - < /dev/null |grep "NEON\|FP" #define __ARM_FP 12 #define __ARM_NEON_FP 12 #define __FP_FAST_FMAF 1 #define __ARM_NEON 1 #define __FP_FAST_FMA 1 Signed-off-by: Jan Viktorin <> Acked-by: Jerin Jacob <>
2016-03-22mk: restrict CPU flags listThomas Monjalon
When compiling each file, the CPU flags are given as RTE_MACHINE_CPUFLAG_* and in the list RTE_COMPILE_TIME_CPUFLAGS. RTE_MACHINE_CPUFLAG_* are used to check the CPU features when compiling. The list RTE_COMPILE_TIME_CPUFLAGS is used only to check the CPU at runtime in the function rte_cpu_check_supported(). So it is not needed to define this list for every files. That's why RTE_COMPILE_TIME_CPUFLAGS is removed from the common variable MACHINE_CFLAGS and is added only to the CFLAGS of eal_common_cpuflags.c. Signed-off-by: Thomas Monjalon <>
2016-01-27mk: predefine AVX512 macro for compilerZhihong Wang
Predefine AVX512 macro if AVX512 is enabled by compiler. Signed-off-by: Zhihong Wang <>
2015-12-08mk: fix warnings when adding extra warning flagsPanu Matilainen
Starting with commit 9aa2053c6e81493b23346ff4e387903560de5c81 EXTRA_CFLAGS is sometimes being passed to the compiler without WERROR_FLAGS which can cause spurious warnings by the dozen, for example with when compiling with EXTRA_CFLAGS="-Wformat-security": cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security] Passing WERROR_FLAGS to AUTO_CPU helper makes the warning flag usage consistent throughout the codebase, silencing the warnings. Fixes: 9aa2053c6e81 ("mk: influence CPU flags with user input") Signed-off-by: Panu Matilainen <> Acked-by: Simon Kagstrom <>
2015-12-04mk: influence CPU flags with user inputSimon Kagstrom
We have encountered a CPU where the AES-NI instruction set is disabled due to export restrictions. Since the build machine and target machine is different, using -native configs doesn't work, and on this CPU, the application refuses to run due to the AES CPU flags being amiss. The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper, which allows us to add -mno-aes to the compile flags and resolve this problem. Signed-off-by: Simon Kagstrom <> Acked-by: Olivier Matz <>
2015-11-25hash: use armv8-a CRC32 instructionsJerin Jacob
armv8-a has optional CRC32 extension, march=armv8-a+crc enables code generation for the ARMv8-A architecture together with the optional CRC32 extensions. added RTE_MACHINE_CPUFLAG_CRC32 to detect the availability of CRC32 extension in compile time. At run-time, The RTE_CPUFLAG_CRC32 can be used to find the availability. armv8-a+crc target support added in GCC 4.9, Used inline assembly and emulated __ARM_FEATURE_CRC32 to work with tool-chain < 4.9 Signed-off-by: Jerin Jacob <>
2015-11-18eal/arm: add CPU flags for ARMv7Vlastimil Kosar
This implementation is based on IBM POWER version of rte_cpuflags. We use software emulation of HW capability registers, because those are usually not directly accessible from userspace on ARM. Signed-off-by: Vlastimil Kosar <> Signed-off-by: Jan Viktorin <> Acked-by: David Marchand <>
2014-11-26eal/ppc: cpu flag checks for IBM PowerChao Zhu
IBM Power processor doesn't have CPU flag hardware registers. This patch uses aux vector software register to get CPU flags and add CPU flag checking support for IBM Power architecture. Signed-off-by: Chao Zhu <> Acked-by: David Marchand <>
2014-06-11remove trailing whitespacesBruce Richardson
This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <> Acked-by: Neil Horman <> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <>
2014-02-25mk: rework cpu flags detectionBruce Richardson
For cases where the compilation microarchitecture is explicitly given, we extract the cpu-flags to use from the compiler rather than hard-coding. This means that we will only ever use instruction sets supported by the compiler, rather than having a case where the uarch and the Intel DPDK both support a given instruction-set, but the compiler does not. In the case where 'native' uarch support is requested, the same mechanism is also used to detect the instruction-sets supported Signed-off-by: Bruce Richardson <> Signed-off-by: David Marchand <>