On Fri, Apr 12, 2019 at 09:46:17AM +0200, David Marchand wrote:
> On Thu, Apr 11, 2019 at 9:52 PM Aaron Conole <[1]acon...@redhat.com>
> wrote:
>
> The arguments being passed will cause failures on laptops that have,
> for instance, 2 cores only. Most of the tests don't require more
> than a single core. Some require multiple cores (but those tests
> should be modified to 'SKIP' when the correct number of cores
> aren't available).
> The unit test results shouldn't be impacted by this change, but it
> allows for a future enhancement to pass flags such as '--no-huge'.
> Also include a fix to a reported issue with running on FreeBSD.
> Signed-off-by: Aaron Conole <[2]acon...@redhat.com>
> ---
> Conflicts with [3]http://patches.dpdk.org/patch/50850/
> app/test/meson.build | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
> diff --git a/app/test/meson.build b/app/test/meson.build
> index 867cc5863..1010bfbc8 100644
> --- a/app/test/meson.build
> +++ b/app/test/meson.build
> @@ -344,17 +344,32 @@ if get_option('tests')
> timeout_seconds = 600
> timeout_seconds_fast = 10
> + # Retreive the number of CPU cores
>
> nit: Retrieve
> Little concern here on the approach of getting the max available cpu
> index.
> If we have non contiguous cpus (let's say hyper threading is disabled),
> this won't work.
> But we can just assume this won't happen for non regression setups
> (vms).
>
> + num_cores = run_command('lscpu',
> '-p=cpu').stdout().strip().split('\n')[-1]
>
> lscpu is a linux command afaik.
> Maybe for FreeBSD:
> root@freebsd-10:~ # sysctl dev.cpu |cut -d . -f 3 |sort |tail -1
> 3
> Not sure if FreeBSD ensures that the keys names/objects won't change
> accross the versions.
>
Very similar thoughs/concerns here. I think doing this per OS is probably
safer in the long term - even though lscpu is available for FreeBSD as an
extra package.
My suggestion: for FreeBSD, get the number of CPUs using
"/sbin/sysctl -n hw.ncpu"
For Linux, rather than using a "0-N" range, use output from
"cat /sys/devices/system/cpu/present", which will ensure that it works
even in the non-contiguous CPU numbering case. [Though I suspect we get
non-contiguous numbers only in the case a core or two has been hotplugged
out, I think - disabling hyperthreading won't leave gaps, just fewer cores]
/Bruce
