On Fri, Dec 05, 2025 at 09:00:03AM -0800, Stephen Hemminger wrote:
> On Fri, 5 Dec 2025 08:29:39 +0000
> Bruce Richardson <[email protected]> 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: [email protected]
> > > 
> > > Signed-off-by: Stephen Hemminger <[email protected]>
> > > ---
> > >  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".

Reply via email to