RE: [PATCH v3 03/14] test/mcslock: scale test based on number of cores

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> This test uses loops to synchronize but has problems on systems
> with high number of cores. Scale iterations to the number of
> cores.
> 
> Fixes: 32dcb9fd2a22 ("test/mcslock: add MCS queued lock unit test")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  app/test/test_mcslock.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/app/test/test_mcslock.c b/app/test/test_mcslock.c
> index 245df99a5d..b182da72f1 100644
> --- a/app/test/test_mcslock.c
> +++ b/app/test/test_mcslock.c
> @@ -42,6 +42,10 @@ RTE_ATOMIC(rte_mcslock_t *) p_ml_perf;
> 
>  static unsigned int count;
> 
> +#define MAX_LOOP_BASE  1000000u
> +#define MAX_LOOP_MIN   10000u
> +static unsigned int max_loop;
> +
>  static RTE_ATOMIC(uint32_t) synchro;
> 
>  static int
> @@ -60,8 +64,6 @@ test_mcslock_per_core(__rte_unused void *arg)
> 
>  static uint64_t time_count[RTE_MAX_LCORE] = {0};
> 
> -#define MAX_LOOP 1000000
> -
>  static int
>  load_loop_fn(void *func_param)
>  {
> @@ -78,7 +80,7 @@ load_loop_fn(void *func_param)
>  	rte_wait_until_equal_32((uint32_t *)(uintptr_t)&synchro, 1,
> rte_memory_order_relaxed);
> 
>  	begin = rte_get_timer_cycles();
> -	while (lcount < MAX_LOOP) {
> +	while (lcount < max_loop) {
>  		if (use_lock)
>  			rte_mcslock_lock(&p_ml_perf, &ml_perf_me);
> 
> @@ -175,6 +177,8 @@ test_mcslock(void)
>  	rte_mcslock_t ml_me;
>  	rte_mcslock_t ml_try_me;
> 
> +	max_loop = test_scale_iterations(MAX_LOOP_BASE, MAX_LOOP_MIN);
> +

Here, and in other similar cases, would it make sense to terminate by timeout
(i.e. number of cycles passed since start of the test)?
 

>  	/*
>  	 * Test mcs lock & unlock on each core
>  	 */
> --
> 2.51.0