DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [dpdk-dev] [RFCv2] service core concept
Date: Mon, 5 Jun 2017 12:53:07 +0530	[thread overview]
Message-ID: <20170605072306.GA1280@jerin> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA63BF2D169@IRSMSX102.ger.corp.intel.com>

-----Original Message-----
> Date: Fri, 2 Jun 2017 16:09:13 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: "dev@dpdk.org" <dev@dpdk.org>
> CC: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob
>  <jerin.jacob@caviumnetworks.com>, "Richardson, Bruce"
>  <bruce.richardson@intel.com>, "Ananyev, Konstantin"
>  <konstantin.ananyev@intel.com>, "Wiles, Keith" <keith.wiles@intel.com>
> Subject: [dpdk-dev] [RFCv2] service core concept
> 
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Van Haaren, Harry
> > Sent: Thursday, May 25, 2017 2:28 PM
> > Subject: Re: [dpdk-dev] [RFC] service core concept header implementation
> > 
> > Thanks everybody for the input on the RFC - appreciated! From an application point-of-view, I
> > see merit in Konstantin's suggestions for the API, over the RFC I sent previously. I will re-
> > work the API taking inspiration from both APIs and send an RFCv2, you'll be on CC :)
> 
> 
> Hi All,
> 
> This email is the v2 RFC for Service Cores, in response to the v1 sent previously[1].
> The service-cores API has been updated, and various concepts have changed.
> 
> The API has been redesigned, with Konstantin's API suggestions as a base, and the
> other comments taken into account. In my opinion this v2 API is more application-centric,
> and enables the common application tasks much better. Such tasks are for example start/stop
> of a service, and add/remove of a service core.
> 
> In particular this version of the API enables applications that are not aware of services to
> benefit from the services concept, as EAL args can be used to setup services and service cores.
> With this design, switching to/from SW/HW PMD is transparent to the application. An example
> use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a service core. 
> 
> I have noted the implementation comments that were raised on the v1. For v2, I think our time
> is better spent looking at the API design, and I will handle implementation feedback in the
> follow-up patchset to v2 RFC.
> 
> Below a summary of what we are trying to achieve, and the current API design.
> Have a good weekend! Cheers, -Harry
> 
> 
> Summary of goals (summarized from a previous email)
> 1. Allowing libraries and drivers to register the fact that they require background processing
> 2. Providing support for easily multiplexing these independent functions from different libs onto a different core
> 3. Providing support for the application to configure the running of these background services on specific cores
> 4. Once configured, hiding these services and the cores they run on from the rest of the application,
>    so that the rest of the app logic does not need to change depending on whether service cores are in use or not
> 
> 
> === RFC v2 API ===
> 
> There are 3 parts to the API; they separate the concerns of each "user" of the API:
> 	- Service Registration
> 	- Service Config
> 	- ServiceCore Config
> 
> Service Registration: 
> A service requires a core. It only knows about its NUMA node, and that it requires CPU time.
> Registration of a service requires only that information.
> 
> Service Config:
> An application may configure what service runs where using the Service Config APIs.
> EAL is capable of performing this during rte_eal_init() if requested by passing a
> --service-cores argument. The application (mostly) calls these functions at initialization
> time, with start() and stop() being available to dynamically switch on/off a service if required.
> 
> ServiceCore Config
> An application can start/stop or add/remove service-lcores using the ServiceCore Config, allowing
> dynamically scaling the number of used lcores by services. Lcores used as service-cores are removed
> from the application coremask, and are not available to remote_launch() as they are already in use.
> 
> 
> Service Registration:
> int32_t rte_service_register(const struct rte_service_spec *spec);
> int32_t rte_service_unregister(struct rte_service_spec *service);
> 
> Service Configuration:
> uint32_t rte_service_get_count(void);
> struct rte_service_spec *rte_service_get_by_id(uint32_t id);
> const char *rte_service_get_name(const struct rte_service_spec *service);
> int32_t rte_service_set_coremask(struct rte_service_spec *service, const rte_cpuset_t *coremask);
> int32_t rte_service_start(struct rte_service_spec *service); /* runtime function */
> int32_t rte_service_stop(struct rte_service_spec *service);  /* runtime function */

Looks good to me in general.

How about an API to query the service function running status?
bool rte_service_is_running(struct rte_service_spec *service); or something similar.


> 
> ServiceCore Configuration:
> int32_t rte_service_cores_start(void);
> int32_t rte_service_cores_stop(void);
> int32_t rte_service_cores_add(const rte_cpuset_t *coremask);
> int32_t rte_service_cores_del(const rte_cpuset_t *coremask);
> 
> 
> I am working on a patchset - but for now I would appreciate general design feedback,
> particularly if a specific use-case is not handled.

  parent reply	other threads:[~2017-06-05  7:23 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
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 [this message]
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=20170605072306.GA1280@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.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).