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