Re: [dpdk-dev] [PATCH] examples/ip_pipeline: avoid the failure of creating hash table

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Jianbo Liu [mailto:jianbo.liu@arm.com]
> Sent: Monday, October 30, 2017 3:33 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] examples/ip_pipeline: avoid the failure of creating hash
> table
> 
> The 10/27/2017 10:01, Dumitrescu, Cristian wrote:
> >
> >
> > > -----Original Message-----
> > > From: Jianbo Liu [mailto:jianbo.liu@arm.com]
> > > Sent: Friday, October 27, 2017 3:55 AM
> > > To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > > Cc: Jianbo Liu <jianbo.liu@arm.com>
> > > Subject: [PATCH] examples/ip_pipeline: avoid the failure of creating hash
> > > table
> > >
> > > Hash table function will check if the input bucket size is power of 2,
> > > so the parameter should be rounded up before sending to the creating
> > > function.
> > >
> > > Signed-off-by: Jianbo Liu <jianbo.liu@arm.com>
> > > ---
> > >  examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c | 2 +-
> > >  examples/ip_pipeline/pipeline/pipeline_routing_be.c             | 3 ++-
> > >  2 files changed, 3 insertions(+), 2 deletions(-)
> > >
> >
> > Existing code is simply letting the library detect the misconfiguration and
> gracefully fail. It avoids duplicating library checks in the app.
> >
> > Your proposal tries to prevent library from failing by silently tweaking some
> user configuration params. Easier to debug in some cases.
> 
> Yes. but is it must for the parameters to be power of 2? I saw the
> config exmple in examples/ip_pipeline/config/network_layers.cfg:
> 
> ....
> 178 port_local_dest = 4 ; SINK2 (Drop)
> 179 n_arp_entries = 1000
> 180 ip_hdr_offset = 270
> 
> If not, it's the programmer to correct it before sending to the library.
> 
> Thanks!
> Jianbo
> 

In the latest code, the number of keys does not have to be a power of 2, while the number of buckets does.

I am considering changing the implementation to quietly upgrade number of buckets to the next power of 2 to eliminate some of these error cases.
+: less things for the (unengaged) user to worry about
-: number of buckets needs to be a power of two internally, so a non-power of 2 is likely a misconfiguration; the memory footprint can get much higher when quiet upgrade takes place

> >
> > For this case, I am OK with your proposal, although not really required, so:
> >
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> >
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.