DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Carrillo, Erik G" <erik.g.carrillo@intel.com>,
	Robert Sanford <rsanford@akamai.com>
Cc: dev <dev@dpdk.org>, nd <nd@arm.com>,
	Phil Yang <Phil.Yang@arm.com>, Gavin Hu <Gavin.Hu@arm.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>, nd <nd@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] Questions about rte_timer APIs
Date: Thu, 27 Feb 2020 16:58:15 +0000	[thread overview]
Message-ID: <VE1PR08MB51499820059D3BB5454B57E398EB0@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <BYAPR11MB3415F3650CBA18A8AFC97CCEB9EA0@BYAPR11MB3415.namprd11.prod.outlook.com>

Thanks Erik. We will create some patches and send them for review.

> -----Original Message-----
> From: Carrillo, Erik G <erik.g.carrillo@intel.com>
> Sent: Wednesday, February 26, 2020 10:58 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Robert
> Sanford <rsanford@akamai.com>
> Cc: dev <dev@dpdk.org>; nd <nd@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; Gavin Hu <Gavin.Hu@arm.com>;
> david.marchand@redhat.com; thomas@monjalon.net; nd <nd@arm.com>
> Subject: RE: Questions about rte_timer APIs
> 
> Hi Honnappa,
> 
> Your description below looks correct to me.  For the current implementation, I
> referenced a couple of existing DPDK libraries, but primarily the rte_service
> library.  However, I agree that allocating the timer data structs only as needed
> would be a good idea.
> 
> You are also correct that, since the rte_timer_alt_* APIs are still experimental,
> they can change without constraint;  this would allow for the APIs to change
> as needed to support the above design.  It looks like the only users of those
> APIs in DPDK currently are the event timer adapter and unit test code.
> 
> Thanks,
> Erik
> 
> > -----Original Message-----
> > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Sent: Tuesday, February 25, 2020 5:56 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Robert
> > Sanford <rsanford@akamai.com>; Carrillo, Erik G
> > <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>;
> > david.marchand@redhat.com; thomas@monjalon.net; nd <nd@arm.com>
> > Subject: RE: Questions about rte_timer APIs
> >
> > 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.to s 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


      reply	other threads:[~2020-02-27 16:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14  5:54 Honnappa Nagarahalli
2020-02-25 23:56 ` Honnappa Nagarahalli
2020-02-26 16:57   ` Carrillo, Erik G
2020-02-27 16:58     ` Honnappa Nagarahalli [this message]

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=VE1PR08MB51499820059D3BB5454B57E398EB0@VE1PR08MB5149.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Phil.Yang@arm.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=erik.g.carrillo@intel.com \
    --cc=nd@arm.com \
    --cc=rsanford@akamai.com \
    --cc=thomas@monjalon.net \
    /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).