[dpdk-dev] Questions about rte_timer APIs

[Honnappa Nagarahalli]

Thanks Erik. We will create some patches and send them for review.

> -----Original Message-----
> From: Carrillo, Erik G <erik.g.carrillo at intel.com>
> Sent: Wednesday, February 26, 2020 10:58 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>; Robert
> Sanford <rsanford at akamai.com>
> Cc: dev <dev at dpdk.org>; nd <nd at arm.com>; Phil Yang
> <Phil.Yang at arm.com>; Gavin Hu <Gavin.Hu at arm.com>;
> david.marchand at redhat.com; thomas at monjalon.net; nd <nd at 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.Nagarahalli at arm.com>
> > Sent: Tuesday, February 25, 2020 5:56 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>; Robert
> > Sanford <rsanford at akamai.com>; Carrillo, Erik G
> > <erik.g.carrillo at intel.com>
> > Cc: dev <dev at dpdk.org>; nd <nd at arm.com>; Phil Yang
> > <Phil.Yang at arm.com>; Gavin Hu <Gavin.Hu at arm.com>;
> > david.marchand at redhat.com; thomas at monjalon.net; nd <nd at 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 at dpdk.org> On Behalf Of Honnappa Nagarahalli
> > > Sent: Thursday, February 13, 2020 11:55 PM
> > > To: Robert Sanford <rsanford at akamai.com>; Erik Gabriel Carrillo
> > > <erik.g.carrillo at intel.com>
> > > Cc: dev <dev at dpdk.org>; nd <nd at arm.com>; Phil Yang
> > > <Phil.Yang at arm.com>; Gavin Hu <Gavin.Hu at arm.com>; nd
> > <nd at 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