Re: [dpdk-dev] Questions about rte_timer APIs

["Carrillo, Erik G" <erik.g.carrillo@intel.com>]

Hi Honnappa,

Your description below looks correct to me.  For the current implementation, I referenced a couple of existing DPDK libraries, but primarily the rte_service library.  However, I agree that allocating the timer data structs only as needed would be a good idea.

You are also correct that, since the rte_timer_alt_* APIs are still experimental, they can change without constraint;  this would allow for the APIs to change as needed to support the above design.  It looks like the only users of those APIs in DPDK currently are the event timer adapter and unit test code.

Thanks,
Erik

> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Tuesday, February 25, 2020 5:56 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Robert
> Sanford <rsanford@akamai.com>; Carrillo, Erik G <erik.g.carrillo@intel.com>
> Cc: dev <dev@dpdk.org>; nd <nd@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; Gavin Hu <Gavin.Hu@arm.com>;
> david.marchand@redhat.com; thomas@monjalon.net; nd <nd@arm.com>
> Subject: RE: Questions about rte_timer APIs
> 
> Hi Erik,
> 	I see that the rte_timer_alt_xxx APIs are still marked as
> experimental. So, we should be able to change them without any ABI
> constraints. Please let me know what you think.
> 
> Thank you,
> Honnappa
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Honnappa Nagarahalli
> > Sent: Thursday, February 13, 2020 11:55 PM
> > To: Robert Sanford <rsanford@akamai.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>
> > Cc: dev <dev@dpdk.org>; nd <nd@arm.com>; Phil Yang
> > <Phil.Yang@arm.com>; Gavin Hu <Gavin.Hu@arm.com>; nd
> <nd@arm.com>
> > Subject: [dpdk-dev] Questions about rte_timer APIs
> >
> > Hi Erik/Robert,
> > 	I was looking at the rte_timer library code and have questions around
> > the way instances of timer list are allocated.
> >
> > The API 'rte_timer_subsystem_init' allocates RTE_MAX_DATA_ELS (64)
> > number of timer data structs. Each timer data struct acts as an
> > independent instance of timer list. The user allocates an instance by
> > calling 'rte_timer_data_alloc' which provides an index in the instance array.to s
> > Essentially, the library is allocating the memory upfront even though
> > there might not be a need to have 64 instances. Please correct me if I am
> wrong.
> >
> > Usually, creating multiple instances is handled by allocating required
> > memory, as and when required, by an 'init' API. This API also returns
> > a pointer to that instance which is passed to other APIs in the
> > library. For ex: rte_hash library follows this approach. IMO, this is an
> elegant way to handle multiple instances.
> > This approach does not waste memory and does not put any restriction
> > on number of instances.
> >
> > I wanted to understand the reasoning behind the current design to
> > handle multiple instances. Appreciate your inputs.
> >
> > Thank you,
> > Honnappa