Re: [dpdk-dev] Questions about rte_timer APIs

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

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.
> 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