From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
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
Date: Fri, 14 Feb 2020 05:54:40 +0000 [thread overview]
Message-ID: <VE1PR08MB51497ED7575A342F14BCEC3698150@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
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
next reply other threads:[~2020-02-14 5:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 5:54 Honnappa Nagarahalli [this message]
2020-02-25 23:56 ` Honnappa Nagarahalli
2020-02-26 16:57 ` Carrillo, Erik G
2020-02-27 16:58 ` Honnappa Nagarahalli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VE1PR08MB51497ED7575A342F14BCEC3698150@VE1PR08MB5149.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=Phil.Yang@arm.com \
--cc=dev@dpdk.org \
--cc=erik.g.carrillo@intel.com \
--cc=nd@arm.com \
--cc=rsanford@akamai.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).