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

Stephen Hemminger
2025-12-05T17:00:13Z

On Fri, 5 Dec 2025 08:29:39 +0000
Bruce Richardson <bruce.richardson@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@dpdk.org
> >
> > Signed-off-by: Stephen Hemminger <stephen@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.