[PATCH v5 05/10] app/test: define unit tests suites based on test macros
Bruce Richardson
bruce.richardson at intel.com
Wed Aug 16 13:02:03 CEST 2023
On Tue, Aug 15, 2023 at 04:10:49PM +0100, Bruce Richardson wrote:
> Rather than having the test suites listed out in the meson.build files
> and having to have them enabled/disabled selectively based on what libs
> are being built, pull the tests to run from the source files which were
> added to the build.
>
> Most test suites require no additional info other than the list of test
> names in the suite. However the fast-test are special that they have
> additional parameters associated with them. This requires some
> additional work in the test extraction script and in the meson.build
> file for processing the output.
>
> Signed-off-by: Bruce Richardson <bruce.richardson at intel.com>
> Acked-by: Morten Brørup <mb at smartsharesystems.com>
> ---
> app/meson.build | 7 +-
> app/test/suites/meson.build | 74 +++++++++++++++++++
> buildtools/get-test-suites.py | 33 +++++++++
> .../has-hugepages.py | 0
> buildtools/meson.build | 2 +
> 5 files changed, 115 insertions(+), 1 deletion(-)
> create mode 100644 app/test/suites/meson.build
> create mode 100644 buildtools/get-test-suites.py
> rename app/test/has_hugepage.py => buildtools/has-hugepages.py (100%)
>
> diff --git a/app/meson.build b/app/meson.build
> index 0d8b618e7f..c14dc80892 100644
> --- a/app/meson.build
> +++ b/app/meson.build
> @@ -101,7 +101,7 @@ foreach app:apps
> link_libs = dpdk_static_libraries + dpdk_drivers
> endif
>
> - executable('dpdk-' + name,
> + exec = executable('dpdk-' + name,
> sources,
> c_args: cflags,
> link_args: ldflags,
> @@ -110,4 +110,9 @@ foreach app:apps
> include_directories: includes,
> install_rpath: join_paths(get_option('prefix'), driver_install_path),
> install: true)
> + if name == 'test'
> + dpdk_test = exec
> + autotest_sources = sources
> + subdir('test/suites') # define the pre-canned test suites
> + endif
> endforeach
> diff --git a/app/test/suites/meson.build b/app/test/suites/meson.build
> new file mode 100644
> index 0000000000..ec74d8adf2
> --- /dev/null
> +++ b/app/test/suites/meson.build
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2023 Intel Corporation
> +
> +# some perf tests (eg: memcpy perf autotest)take very long
> +# to complete, so timeout to 10 minutes
> +timeout_seconds = 600
> +timeout_seconds_fast = 10
> +
> +test_no_huge_args = ['--no-huge', '-m', '2048']
> +has_hugepage = run_command(has_hugepages_cmd, check: true).stdout().strip() != '0'
> +message('hugepage availability: @0@'.format(has_hugepage))
> +
> +# process source files to determine the different unit test suites
> +# - fast_tests
> +# - perf_tests
> +# - driver_tests
> +test_suites = run_command(get_test_suites_cmd, autotest_sources,
> + check: true).stdout().strip().split()
> +foreach suite:test_suites
> + # simple cases - tests without parameters or special handling
> + suite = suite.split('=')
> + suite_name = suite[0]
> + suite_tests = suite[1].split(',')
> + if suite_name != 'fast-tests'
> + # simple cases - tests without parameters or special handling
> + foreach t: suite_tests
> + test(t, dpdk_test,
> + env: ['DPDK_TEST=' + t],
> + timeout: timeout_seconds,
> + is_parallel: false,
> + suite: suite_name)
> + endforeach
> + else
> + # special fast-test handling here
> + foreach t: suite_tests
> + params = t.split(':')
> + test_name = params[0]
> + nohuge = params[1] == 'true'
> + asan = params[2] == 'true'
> +
> + test_args = []
> + if nohuge
> + test_args += test_no_huge_args
> + elif not has_hugepage
> + continue #skip this tests
> + endif
> + if not asan and (get_option('b_sanitize') == 'address'
> + or get_option('b_sanitize') == 'address,undefined')
> + continue # skip this test
> + endif
> +
> + if get_option('default_library') == 'shared'
> + test_args += ['-d', dpdk_drivers_build_dir]
> + endif
These lines here seem to be exposing a bug in the mempool unit tests for
shared builds, which is why we have a CI failure.
The mempool unit tests use the mempool "create_empty" API, and then call
the populate APIs to finish setting up the mempool. However, the
create_empty API does not explicitly configure a particular set of mempool
ops for the new mempool, leaving the ops field at 0. This means that unless
the app explicitly sets other ops, the mempool will use the ops from
whatever driver registers itself first. This occurs even when the driver is
unsuitable, e.g. on my Intel system, the dpaa2 is first on the list,
leading to failures in setting up and using the mempool.
In v6 of this set, I intend to fix this, by changing the create empty API
to explicitly set the ring driver as default for new mempools. It's the
most likely to work for common cases.
/Bruce
More information about the dev
mailing list