[RFC v2 02/14] test: avoid long hash names

[Bruce Richardson]

On Thu, Dec 04, 2025 at 06:28:11PM -0800, Stephen Hemminger wrote:
> The test was using hash table names which were too long and
> would break if the hash library was checking the parameters.
> 
> Fixes: af75078fece3 ("first public release")
> Fixes: 9c7d8eed1a45 ("test/hash: add RCU tests")
> Fixes: 567bb951716f ("hash: reclaim RCU defer queue")
> Cc: stable at dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> ---
>  app/test/test_hash.c | 29 +++++++++++++++++++----------
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/app/test/test_hash.c b/app/test/test_hash.c
> index 5791fd7f4c..8cecc28d11 100644
> --- a/app/test/test_hash.c
> +++ b/app/test/test_hash.c
> @@ -1399,8 +1399,16 @@ static int test_hash_creation_with_bad_parameters(void)
>  		return -1;
>  	}
>  
> -	memcpy(&params, &ut_params, sizeof(params));
> -	params.name = "creation_with_bad_parameters_0";
> +	params = ut_params;
> +	params.name = "really_long_name_of_22";
> +	handle = rte_hash_create(&params);
> +	if (handle != NULL) {
> +		rte_hash_free(handle);
> +		printf("Impossible creating hash successfully with excessively long name\n");
> +		return -1;
> +	}
> +

I'm not sure about this behaviour, for something like the hash name. I'd
tend more towards having the hash library just truncate the name rather
than returning an error if it was too long.

Also, I worry that this could break end-applications which were relying on
previous behaviour of ignoring long names.

What do you/others think?

/Bruce