There is a common macro __rte_packed for packing structs,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Multiple global variable are defined in multiple unit test files with
same name, but all unit test files are linked into single executable,
which means those variables share same storage which is not the
intention, fixed by making global variables 'static'.
Issue has been detected by '-fno-common' gcc flag.
Fixes: fdeb30fa71 ("test/bitrate: add unit tests for bitrate library")
Fixes: c3eabff124 ("distributor: add unit tests")
Fixes: 0e925aef27 ("app/test: add EFD functional and perf tests")
Fixes: 359e17bf08 ("app/test: improve hash unit tests")
Fixes: c7eb0972e7 ("test/hash: add lock-free r/w concurrency")
Fixes: 1e3676a06e ("test/latency: add unit tests for latencystats library")
Fixes: 0cc67a96e4 ("test/member: add functional and perf tests")
Fixes: e6a14121f4 ("test/rcu: remove arbitrary limit on max core count")
Fixes: 104dbec208 ("test/rcu: increase size of core numbers")
Cc: stable@dpdk.org
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Since we change these macros, we might as well avoid triggering complaints
from checkpatch because of mixed case.
old=RTE_IPv4
new=RTE_IPV4
git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
old=RTE_ETHER_TYPE_IPv4
new=RTE_ETHER_TYPE_IPV4
git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
old=RTE_ETHER_TYPE_IPv6
new=RTE_ETHER_TYPE_IPV6
git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
This patch enables compilation of print_key_info() always using
log-level based approach instead of a macro. Need to set efd log type
to debug to print debug information, using the following eal parameter:
--log-level=test.efd:debug
Suggested-by: Thomas Monjalon <thomas@monjalon.net>
Signed-off-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Since all other apps have been moved to the "app" folder, the autotest app
remains alone in the test folder. Rather than having an entire top-level
folder for this, we can move it back to where it all started in early
versions of DPDK - the "app/" folder.
This move has a couple of advantages:
* This reduces clutter at the top level of the project, due to one less
folder.
* It eliminates the separate build task necessary for building the
autotests using make "make test-build" which means that developers are
less likely to miss something in their own compilation tests
* It re-aligns the final location of the test binary in the app folder when
building with make with it's location in the source tree.
For meson builds, the autotest app is different from the other apps in that
it needs a series of different test cases defined for it for use by "meson
test". Therefore, it does not get built as part of the main loop in the
app folder, but gets built separately at the end.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
This is to logically group unit tests into their own folder,
separating them from "app" folder.
Hopefully this will make the unit test in DPDK more visible.
Following binaries moved to "test" folder:
cmdline-test
test-acl
test-pipeline
test <-- various DPDK unit tests
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
When RTE_EFD_VALUE_NUM_BITS is 32, there was a compilation issue
because of an overflow:
app/test/test_efd.c:157:55: error: overflow in expression;
result is 2147483647 with type 'int' [-Werror,-Winteger-overflow]
data[0] = mrand48() & ((1 << RTE_EFD_VALUE_NUM_BITS) - 1);
This commit fixes the issue by using a setting a different
macro VALUE_BITMASK with a conditional
Fixes: 0e925aef27 ("app/test: add EFD functional and perf tests")
Reported-by: Yong Liu <yong.liu@intel.com>
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
