Thanks Erik. We will create some patches and send them for review.
> -----Original Message-----
> From: Carrillo, Erik G <erik.g.carri...@intel.com>
> Sent: Wednesday, February 26, 2020 10:58 AM
> To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; Robert
> Sanford <rsanf...@akamai.com>
> Cc: dev <dev@dpdk.org>; nd <n...@arm.com>; Phil Yang
> <phil.y...@arm.com>; Gavin Hu <gavin...@arm.com>;
> david.march...@redhat.com; tho...@monjalon.net; nd <n...@arm.com>
> Subject: RE: Questions about rte_timer APIs
>
> 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.nagaraha...@arm.com>
> > Sent: Tuesday, February 25, 2020 5:56 PM
> > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; Robert
> > Sanford <rsanf...@akamai.com>; Carrillo, Erik G
> > <erik.g.carri...@intel.com>
> > Cc: dev <dev@dpdk.org>; nd <n...@arm.com>; Phil Yang
> > <phil.y...@arm.com>; Gavin Hu <gavin...@arm.com>;
> > david.march...@redhat.com; tho...@monjalon.net; nd <n...@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-boun...@dpdk.org> On Behalf Of Honnappa Nagarahalli
> > > Sent: Thursday, February 13, 2020 11:55 PM
> > > To: Robert Sanford <rsanf...@akamai.com>; Erik Gabriel Carrillo
> > > <erik.g.carri...@intel.com>
> > > Cc: dev <dev@dpdk.org>; nd <n...@arm.com>; Phil Yang
> > > <phil.y...@arm.com>; Gavin Hu <gavin...@arm.com>; nd
> > <n...@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
