All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [RFCv2] service core concept
Date: Sat, 3 Jun 2017 10:22:48 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA63BF2D169@IRSMSX102.ger.corp.intel.com>


Hi Harry,

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

Looks good to me in general.
The only comment I have - do we really need to put it into rte_eal_init()
and a new EAL command-line parameter for it? 
Might be better to leave it to the particular app to decide.
Konstantin

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

  reply	other threads:[~2017-06-03 10:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 16:09 [RFCv2] service core concept Van Haaren, Harry
2017-06-03 10:22 ` Ananyev, Konstantin [this message]
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
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=2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=keith.wiles@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.