DPDK patches and discussions
 help / color / Atom feed
* [dpdk-dev] Questions about rte_timer APIs
@ 2020-02-14  5:54 Honnappa Nagarahalli
  2020-02-25 23:56 ` Honnappa Nagarahalli
  0 siblings, 1 reply; 4+ messages in thread
From: Honnappa Nagarahalli @ 2020-02-14  5:54 UTC (permalink / raw)
  To: Robert Sanford, Erik Gabriel Carrillo; +Cc: dev, nd, Phil Yang, Gavin Hu, nd

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Questions about rte_timer APIs
  2020-02-14  5:54 [dpdk-dev] Questions about rte_timer APIs Honnappa Nagarahalli
@ 2020-02-25 23:56 ` Honnappa Nagarahalli
  2020-02-26 16:57   ` Carrillo, Erik G
  0 siblings, 1 reply; 4+ messages in thread
From: Honnappa Nagarahalli @ 2020-02-25 23:56 UTC (permalink / raw)
  To: Honnappa Nagarahalli, Robert Sanford, Erik Gabriel Carrillo
  Cc: dev, nd, Phil Yang, Gavin Hu, david.marchand, thomas, nd

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Questions about rte_timer APIs
  2020-02-25 23:56 ` Honnappa Nagarahalli
@ 2020-02-26 16:57   ` Carrillo, Erik G
  2020-02-27 16:58     ` Honnappa Nagarahalli
  0 siblings, 1 reply; 4+ messages in thread
From: Carrillo, Erik G @ 2020-02-26 16:57 UTC (permalink / raw)
  To: Honnappa Nagarahalli, Robert Sanford
  Cc: dev, nd, Phil Yang, Gavin Hu, david.marchand, thomas, nd

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] Questions about rte_timer APIs
  2020-02-26 16:57   ` Carrillo, Erik G
@ 2020-02-27 16:58     ` Honnappa Nagarahalli
  0 siblings, 0 replies; 4+ messages in thread
From: Honnappa Nagarahalli @ 2020-02-27 16:58 UTC (permalink / raw)
  To: Carrillo, Erik G, Robert Sanford
  Cc: dev, nd, Phil Yang, Gavin Hu, david.marchand, thomas, nd, nd

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14  5:54 [dpdk-dev] Questions about rte_timer APIs Honnappa Nagarahalli
2020-02-25 23:56 ` Honnappa Nagarahalli
2020-02-26 16:57   ` Carrillo, Erik G
2020-02-27 16:58     ` Honnappa Nagarahalli

DPDK patches and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox