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

[Stephen Hemminger]

On Fri, 5 Dec 2025 08:29:39 +0000
Bruce Richardson <bruce.richardson at intel.com> wrote:

> 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?

Truncating the name could create issues where two hashes end up sharing a ring
underneath.