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

[Bruce Richardson]

On Fri, Dec 05, 2025 at 09:00:03AM -0800, Stephen Hemminger wrote:
> 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.
> 
Yes, I realise that. However, we have been silently truncating for years
without reported issues, therefore I think it is safer to go from "silently
truncating" to "noisily truncating", rather than jumping straight to
"failing the API".