[dpdk-dev] Questions about rte_timer APIs
Honnappa.Nagarahalli at arm.com
Wed Feb 26 00:56:28 CET 2020
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.
> -----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.
> 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,
More information about the dev