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 <ashwin.sekhar@caviumnetworks.com>
Reviewed-by: Jan Viktorin <viktorin@rehivetech.com>
Increase the default baseline from "core2" architecture to "corei7". This
means that all builds will have SSE4.2 support included, and we can remove
special case manipulation of CFLAGS for the same. Naturally, this does mean
that some machines that previously could run DPDK now can't do so, but
hardware with SSE4.2 has been around for almost a decade now, so this
should not be a major problem.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Fixing typos across dpdk source code using codespell utility.
Skipped the ethdev driver's base code fixes to keep the base
code intact.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
There are two new warnings in GCC 7 that cause problems in the DPDK
compile.
1. GCC now warns if you have a switch fall-through without a suitable
comment indicating that it was intentional. The compiler supports a number
of levels of warning which are triggered depending on the type of message
used, with level 3 being the default. To accept a wider range of possible
fall-through messages, we adjust this down to level 2.
2. GCC also warns about an snprintf where there may be truncation and the
return value is not checked. Given that we often use snprintf in DPDK in
place of strncpy, and in many cases where truncation is not a problem, we
can just disable this particular warning.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
clang 4 gives "taking address of packed member may result in an
unaligned pointer value" warnings in a few locations [1].
Disabled "-Waddress-of-packed-member" warning for clang >= 4
[1] build errors:
.../lib/librte_eal/common/eal_common_memzone.c:275:25:
error: taking address of packed member 'mlock' of class or structure
'rte_mem_config' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
rte_rwlock_write_lock(&mcfg->mlock);
^~~~~~~~~~~
.../lib/librte_ip_frag/rte_ipv4_reassembly.c:139:31:
error: taking address of packed member 'src_addr' of class or structure
'ipv4_hdr' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
psd = (unaligned_uint64_t *)&ip_hdr->src_addr;
^~~~~~~~~~~~~~~~
.../lib/librte_vhost/vhost_user.c:1037:34:
error: taking address of packed member 'payload' of class or structure
'VhostUserMsg' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
vhost_user_set_vring_num(dev, &msg.payload.state);
^~~~~~~~~~~~~~~~~
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Disable for gcc < 4.7 and icc <= 14.0
PMD uses some compiler builtins and new compiler options. Tested with
gcc 4.5.1 and following were not supported:
option:
-Ofast
macros:
_Static_assert
__ORDER_LITTLE_ENDIAN__
__ORDER_BIG_ENDIAN__
__BYTE_ORDER__
__atomic_fetch_add
__ATOMIC_ACQUIRE
__atomic_load_n
__ATOMIC_RELAXED
__atomic_store_n
__ATOMIC_RELEASE
It is not easy to fix all in PMD, disabling PMD for older compilers.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
On my system, the version of the compiler is not properly retrieved,
resulting in strange logs when building the dpdk:
/bin/sh: line 0: test: too many arguments
This happens when mk/toolchain/clang/rte.toolchain-compat.mk is included
from a directory that use gcc to build (ex: kernel modules). In that
case, the CLANG_VERSION variable contains spaces that breaks some shell
calls to the test program.
The error is because the output of "gcc -v" on my system contains 2 lines
that matches the "version" string:
Configured with: ../src/configure -v \
--with-pkgversion='Debian 6.3.0-6' [...]
gcc version 6.3.0 20170205 (Debian 6.3.0-6)
This may be specific to Debian. Fix it by specializing the grep.
Fixes: 2ef6eea891 ("mk: add clang toolchain")
Cc: stable@dpdk.org
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
ICC build time
Before this patch (bnx2x PMD enabled [1])
real 8m16.622s
After this patch (bnx2x enabled)
real 0m35.140s
[1]
bnx2x cause the build take a lot, otherwise build times are more sane
numbers.
ICC has a default inline limit and when this limit is hit it generates
a warning, and in DPDK this breaks the build.
Previous solution was to remove the inline limit, which does more
aggressive inlining and build may take too much time.
This patch keeps the default inline limits, but prevents the warning ICC
generates.
Fixes: 8acbad88c4 ("mk: fix build with icc-15")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Rather than allowing just armv7 to have non-fatal strict alignment
cast warnings, generalize it to both strict alignment architectures,
armv7 and tile.
Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
error #188: enumerated type mixed with another type
This is get when an integer assigned to an enum variable.
Since this usage is common and causing many ICC compilation errors, and
other compilers accept this usage. Disabling the warning.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
-dumpversion is for gcc compatibility and doesn't return actual clang
version. -dumpversion only returns 4.2.1 for a long time.
Fixes: 2ef6eea891 ("mk: add clang toolchain")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
In openSUSE Tumbleweed (and in any other SUSE distribution which
uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on
purpose as discussed in https://bugzilla.opensuse.org/show_bug.cgi?id=941428
As a result of which, the gcc-4.x comparison (40 against 5) does not
work leading to tons of warnings and failures during build.
This patch aims to change the way the gcc version is obtained by using
the gcc macros directly.
This is similar to what's being used in the Linux kernel. Querying the
GCC macros directly gives more accurate results compared to -dumpversion
which could vary across distributions.
Signed-off-by: Markos Chandras <mchandras@suse.de>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Add RTE_DEVEL_BUILD make-variable which can be used to do things
differently when doing development vs building a release,
autodetected from source root .git presence and overridable via
commandline. It is used it to enable -Werror compiler flag and may
be extended to other checks.
Failing build on warnings is a useful developer tool but its bad
for release tarballs which can and do get built with newer
compilers than what was used/available during development. Compilers
routinely add new warnings so code which built silently with cc X
might no longer do so with X+1. This doesn't make the existing code
any more buggier and failing the build in this case does not help
to improve the quality of an already released version either.
This change the default flags which can be tuned with EXTRA_CFLAGS.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
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 <jerin.jacob@caviumnetworks.com>
This patch changes the ICC conditional check to disable
-no-inline-max-size and -no-inline-max-total-size to be
for all versions of icc greater than 14 and not just for version 15.
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
There several issues with alignment when compiling for ARMv7.
They are not considered to be fatal (ARMv7 supports unaligned
access of 32b words), so we just leave them as warnings. They
should be solved later, however.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Vlastimil Kosar <kosar@rehivetech.com>
Acked-by: David Marchand <david.marchand@6wind.com>
With GCC 4.4.7 from CentOS 6.5, the following errors arise:
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_dev_rx_queue_setup':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: (near initialization for 'dev_info.driver_name')
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_set_rsc':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:4072: error: missing initializer
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:4072: error: (near initialization for 'dev_info.driver_name')
lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_recv_pkts_lro_single_alloc':
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:1479: error: 'next_rsc_entry' may be used uninitialized in this function
lib/librte_pmd_ixgbe/ixgbe_rxtx.c:1480: error: 'next_rxe' may be used uninitialized in this function
The "missing initializer" warning is a GCC bug which seems fixed in 4.7.
The same warning is thrown by clang.
The "may be used uninitialized" warning is another GCC bug which seems fixed in 4.7.
Fixes: 8eecb3295a ("ixgbe: add LRO support")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Commit 71f0ab1849 broke compilation
on some versions of Debian and Ubuntu where gcc has been modified
to only emit MAJOR.MINOR part of the version from 'gcc -dumpversion'.
Drop the micro-version from gcc version comparisons to work around
this, it wasn't being used for anything anyway.
Fixes: 71f0ab1849 ("mk: rework gcc version detection to permit versions newer than 4.x")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: David Marchand <david.marchand@6wind.com>
Separately comparing major and minor versions becomes seriously clumsy
when with major version changes, convert the entire version string into
a numeric value (ie 4.6.0 becomes 460 and 5.0.0 becomes 500) and use
that for comparisons, eliminate unnecessary negations while at it.
This makes the comparisons simpler, more obvious and makes gcc 5.0
naturally recognized at least as capable as newest 4.x.
This three-digit scheme would run into trouble if gcc ever went to
two-digit version segments, but that hasn't happened in the last 10+
years so it seems like a safe assumption.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This patch add Support for ICC 15.
ICC 15 changed inline-max-size and inline-max-total-size default values,
so for ICC 15 flags -no-inline-max-size -no-inline-max-total-size must be added.
additionally disable compile error for:
13368 - loop was not vectorized with "vector always assert"
15527 - loop was not vectorized: function call to fprintf cannot be vectorize
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
Acked-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
At least on kernels 3.15 or newer, wrong compiler flags are set when building
kernel modules.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Add support for clang by adding a toolchain folder for it with the
appropriate files.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Zhaochen Zhan <zhaochen.zhan@intel.com>
[Thomas: CC from command line overrides HOSTCC]
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
When overriding the CC variable on the commandline, the HOSTCC value
was remaining at "gcc", which caused errors on Free BSD10 when using a gcc
as e.g. gcc48, without a binary just called "gcc". This change overrides
HOSTCC when CC is overridden, which means that setting CC=gcc48, will
now also set HOSTCC=gcc48, allowing the "testhost" app to compile on
BSD10.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
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 <bruce.richardson@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
[Thomas: remove spaces before tabs in libs]
[Thomas: remove more trailing spaces in non-C files]
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Add support for haswell based systems.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
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 <bruce.richardson@intel.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
In rte.toolchain-compat.mk, ensure MACHINE_CFLAGS is initialized when
using GCC 4.7. Update the GCC 4.6 test to also include GCC 4.7.
Signed-off-by: Krzysztof Witek <krzysztof.witek@6wind.com>
Signed-off-by: Zijie Pan <zijie.pan@6wind.com>
Acked-by: Ivan Boule <ivan.boule@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Using gcc is wrong, we should use the cross gcc to detect the
version of gcc.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
