DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Carrillo, Erik G" <erik.g.carrillo@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
	"Vangati, Narender" <narender.vangati@intel.com>,
	"Rao, Nikhil" <nikhil.rao@intel.com>,
	"pbhagavatula@caviumnetworks.com"
	<pbhagavatula@caviumnetworks.com>,
	"Eads, Gage" <gage.eads@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH v2 0/1] eventtimer: introduce event timer adapter
Date: Mon, 9 Oct 2017 20:30:35 +0000	[thread overview]
Message-ID: <BE54F058557D9A4FAC1D84E2FC6D87570ED729B8@fmsmsx115.amr.corp.intel.com> (raw)
In-Reply-To: <20171003143723.GB10493@jerin>

> >
> > The second big change is to replace API parameters specifying pointer
> > to rte_event_timer_adapter with ids, which seems more common
> > throughout DPDK.
> >
> > Other changes include:
> >  - removed rte_event_timer_adapter_lookup() function, since APIs no
> longer
> >    accept pointer to rte_event_timer_adapter
> 
> There is one difference between ethdev rx adapter, where we have
> rte_event_timer_arm_burst(), rte_event_timer_arm_tmo_tick_burst(),
> rte_event_timer_cancel_burst(),
> APIs in fastpath. So any multi process scheme where resolving the fastpath
> API functions in _one_ or zero redirection is fine.

I see, makes sense.

> 
> I guess in we may need 2 or 3 indirection to resolve the fastpath functions
> with id scheme. Please choose scheme with one 1 or no redirection.
> I think,
> - By allocating adapter memory from the heap and

Just to check, are you talking about the heap (e.g., rte_malloc) in hugepage memory?

> - adapter hold the function pointers for multi process and
> - mempool kind of pointer object scheme without id and lookup() Can
> resolve function pointers without any indirection.
> 

Can you elaborate here?  In the mempool implementation, it looks like there's a per-process array of ops objects, and each mempool instance has an index into the array that it uses to select the ops object to call through.  Since the ops structures are initialized per-process, they get function pointers valid in that process - which relates to the second point above. If the adapter holds function pointers for a primary process (for example), they'll be invalid in the secondary.  Am I missing something?

Thanks,
Gabriel

> So please analyze on those lines as well.
> 
> 

  reply	other threads:[~2017-10-09 20:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17 16:11 [dpdk-dev] [RFC PATCH 0/1] eventtimer: introduce event timer wheel Jerin Jacob
2017-08-17 16:11 ` [dpdk-dev] [RFC PATCH 1/1] " Jerin Jacob
2017-08-23 22:57 ` [dpdk-dev] [RFC PATCH 0/1] " Carrillo, Erik G
2017-08-25 10:25   ` Jerin Jacob
2017-08-29 15:02     ` Thomas Monjalon
2017-08-29 15:41       ` Jerin Jacob
2017-08-29 15:48         ` Thomas Monjalon
2017-08-29 16:07           ` Jerin Jacob
2017-09-22 15:17 ` [dpdk-dev] [RFC PATCH v2 0/1] eventtimer: introduce event timer adapter Erik Gabriel Carrillo
2017-09-22 15:17   ` [dpdk-dev] [RFC PATCH v2 1/1] " Erik Gabriel Carrillo
2017-10-03 14:37   ` [dpdk-dev] [RFC PATCH v2 0/1] " Jerin Jacob
2017-10-09 20:30     ` Carrillo, Erik G [this message]
2017-10-16 12:04       ` Pavan Nikhilesh Bhagavatula
2017-10-16 12:37         ` Pavan Nikhilesh Bhagavatula
2017-10-18 21:48           ` Carrillo, Erik G
2017-10-26 15:45             ` Pavan Nikhilesh Bhagavatula
2017-11-20 22:35   ` [dpdk-dev] [RFC PATCH v3 " Erik Gabriel Carrillo
2017-11-20 22:35     ` [dpdk-dev] [RFC PATCH v3 1/1] " Erik Gabriel Carrillo
2017-11-23  4:37       ` Pavan Nikhilesh Bhagavatula
2017-11-27 14:47         ` Carrillo, Erik G
2017-11-28 17:40     ` [dpdk-dev] [RFC PATCH v4 0/4] " Erik Gabriel Carrillo
2017-11-28 17:40       ` [dpdk-dev] [RFC PATCH v4 1/4] " Erik Gabriel Carrillo
2017-11-29 10:29         ` Pavan Nikhilesh Bhagavatula
2017-11-28 17:40       ` [dpdk-dev] [RFC PATCH v4 2/4] eventtimer: add common code Erik Gabriel Carrillo
2017-11-29  5:19         ` Pavan Nikhilesh Bhagavatula
2017-11-30 20:59           ` Carrillo, Erik G
2017-12-01  5:13             ` Pavan Nikhilesh Bhagavatula
2017-12-01 20:19               ` Carrillo, Erik G
2017-11-28 17:40       ` [dpdk-dev] [RFC PATCH v4 3/4] eventtimer: add default software implementation stub Erik Gabriel Carrillo
2017-11-29 10:34         ` Pavan Nikhilesh Bhagavatula
2017-11-30 23:56           ` Carrillo, Erik G
2017-12-01  5:15             ` Pavan Nikhilesh Bhagavatula
2017-11-28 17:40       ` [dpdk-dev] [RFC PATCH v4 4/4] test: add event timer adapter auto-test Erik Gabriel Carrillo

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=BE54F058557D9A4FAC1D84E2FC6D87570ED729B8@fmsmsx115.amr.corp.intel.com \
    --to=erik.g.carrillo@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=narender.vangati@intel.com \
    --cc=nikhil.rao@intel.com \
    --cc=nipun.gupta@nxp.com \
    --cc=pbhagavatula@caviumnetworks.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).