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 <[email protected]> On Behalf Of Honnappa Nagarahalli
> Sent: Thursday, February 13, 2020 11:55 PM
> To: Robert Sanford <[email protected]>; Erik Gabriel Carrillo
> <[email protected]>
> Cc: dev <[email protected]>; nd <[email protected]>; Phil Yang
> <[email protected]>; Gavin Hu <[email protected]>; nd <[email protected]>
> 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
