From: "Wiles, Keith" <keith.wiles@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
DPDK <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"Vangati, Narender" <narender.vangati@intel.com>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"Eads, Gage" <gage.eads@intel.com>
Subject: Re: [dpdk-dev] [RFC] Service Cores concept
Date: Tue, 16 May 2017 22:48:00 +0000 [thread overview]
Message-ID: <97735AA8-2CCB-4432-9D9B-114C89CA3F50@intel.com> (raw)
In-Reply-To: <5129240.aMJQgb24zL@xps>
> On May 16, 2017, at 3:11 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 03/05/2017 13:29, Harry van Haaren:
>> The concept is to allow a software function register itself with EAL as
>> a "service", which requires CPU time to perform its duties. Multiple
>> services can be registered in an application, if more than one service
>> exists. The application can retrieve a list of services, and decide how
>> many "service cores" to use. The number of service cores is removed
>> from the application usage, and they are mapped to services based on
>> an application supplied coremask.
>>
>> The application now continues as normal, without having to manually
>> schedule and implement arbitration of CPU time for the SW services.
>
> I think it should not be the DPDK responsibility to schedule threads.
> The mainloops and scheduling are application design choices.
>
> If I understand well the idea of your proposal, it is a helper for
> the application to configure the thread scheduling of known services.
> So I think we could add interrupt processing and other thread creations
> in this concept.
> Could we also embed the rte_eal_mp_remote_launch() calls in this concept?
I did not really see the RFC as replacing the current design in DPDK for thread handling, but that maybe just me. What I saw was a design to create and destroy threads more dynamically or possible some type of thread pool design.
DPDK needs a thread handler anyway (as we have one now) and the current one seems to work, but it does not allow for someone to replace the thread handling with something different. What I would suggest is figure out how to pull DPDK current thread handling out into a plugin design, then someone can replace that plugin with his own thread handling scheme.
We need to keep DPDK stable, so adding the plugin support and pulling out the current design needs to be transparent to all current applications using the current APIs and methods.
Regards,
Keith
next prev parent reply other threads:[~2017-05-16 22:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 11:29 Harry van Haaren
2017-05-03 11:29 ` [dpdk-dev] [RFC] service core concept header implementation Harry van Haaren
2017-05-04 6:35 ` Jerin Jacob
2017-05-04 12:01 ` Jerin Jacob
2017-05-05 15:48 ` Van Haaren, Harry
2017-05-06 14:26 ` Jerin Jacob
2017-05-17 12:47 ` Ananyev, Konstantin
2017-05-17 12:58 ` Bruce Richardson
2017-05-17 13:47 ` Ananyev, Konstantin
2017-05-25 13:27 ` Van Haaren, Harry
2017-05-16 22:11 ` [dpdk-dev] [RFC] Service Cores concept Thomas Monjalon
2017-05-16 22:48 ` Wiles, Keith [this message]
2017-05-17 10:32 ` Bruce Richardson
2017-05-17 11:28 ` Thomas Monjalon
2017-05-17 12:36 ` Bruce Richardson
2017-05-17 14:51 ` [dpdk-dev] Discuss plugin threading model for DPDK Wiles, Keith
2017-05-17 15:46 ` Thomas Monjalon
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=97735AA8-2CCB-4432-9D9B-114C89CA3F50@intel.com \
--to=keith.wiles@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=nipun.gupta@nxp.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).