From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [dpdk-dev] [RFCv2] service core concept
Date: Tue, 6 Jun 2017 15:40:48 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA640C1A7FA@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com>
> From: Ananyev, Konstantin
> Sent: Tuesday, June 6, 2017 4:29 PM
> Subject: RE: [dpdk-dev] [RFCv2] service core concept
>
>
> > From: Richardson, Bruce
> > Sent: Tuesday, June 6, 2017 3:54 PM
> >
> > On Tue, Jun 06, 2017 at 11:25:57AM +0100, Van Haaren, Harry wrote:
> > > > From: Ananyev, Konstantin
> > > > Sent: Saturday, June 3, 2017 11:23 AM
> > >
> > > <snip>
<snip other discussion>
> > >
> > > There are a number of options here, each with its own merit:
> > >
> > > A) Services/cores config in EAL
> > > Benefit is that service functionality can be transparent to the application. Negative is
> that the complexity is in EAL.
> > >
> > > B) Application configures services/cores
> > > Benefit is no added EAL complexity. Negative is that application code has to configure
> cores (duplicated per application).
> > >
> > >
> > > To answer this question, I think we need to estimate how many applications would benefit
> from EAL integration and balance that against
> > the "complexity cost" of doing so. I do like the simplicity of option (B), however if there
> is significant value in total transparency to the
> > application I think (A) is the better choice.
> > >
> > >
> > > Input on A) or B) welcomed! -Harry
> >
> > I'm definitely in favour of having it in EAL. The whole reason for doing
> > this work is to make it easy for applications to dedicate cores to
> > background tasks - including applications written before this
> > functionality was added. By merging this into EAL, we can have
> > transparency in the app, as we can have the service cores completely in
> > the background, and the app can call rte_eal_mp_remote_launch() exactly
> > as before, without unexpected failures. If we move this externally, the
> > app needs to be reworked to take account of that fact, and call new,
> > service-core aware, launch functions instead.
>
> Not sure I understood you here:
> If the app don' plan to use any cores for services, it for sure will be able to call
> rte_eal_mp_remote_launch() as before (no services running case).
Correct - EAL behavior remains unchanged if --service-cores=0xf is not passed
> From other side, if the app would like to use services - it would need to specify
> which service it wants to run, and for each service provide a coremask, even if
> EAL already allocates service cores for it.
See next paragraph
> Or are you talking about the when EAL allocates service cores, and then
> PMDs themselves (or EAL again) register their services on that cores?
EAL could provide sane default behavior. For example, round-robin services over available service-cores. Multithread-capable services can be registered on all service cores. Its not a perfect solution for all service-to-core mapping problems, but I'd guess about 80% of cases would be covered: using a single service with a single service core dedicated to it :)
> That's probably possible, but how PMD would know which service core(s) it allowed to use?
The PMD shouldn't be deciding - EAL for basic sanity config, or Application for advanced usage.
> Things might get over-complicated here - in theory there could be multiple PMDs,
> each of them can have more than one service, running on multiple sets of cores, etc.
True - the NxM service:core mapping possibility can be huge - the API allows the application the flexibility if that flexibility is really required. If the flexibility is not required, the round-robin 1:1 service:core EAL scheme should cover it?
-Harry
next prev parent reply other threads:[~2017-06-06 15:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 16:09 Van Haaren, Harry
2017-06-03 10:22 ` Ananyev, Konstantin
2017-06-06 10:25 ` Van Haaren, Harry
2017-06-06 10:56 ` Ananyev, Konstantin
2017-06-06 14:53 ` Bruce Richardson
2017-06-06 15:29 ` Ananyev, Konstantin
2017-06-06 15:40 ` Van Haaren, Harry [this message]
2017-06-07 9:50 ` Ananyev, Konstantin
2017-06-07 10:29 ` Van Haaren, Harry
2017-06-07 13:09 ` Ananyev, Konstantin
2017-06-05 7:23 ` Jerin Jacob
2017-06-06 10:06 ` Van Haaren, Harry
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=E923DB57A917B54B9182A2E928D00FA640C1A7FA@IRSMSX101.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=keith.wiles@intel.com \
--cc=konstantin.ananyev@intel.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).