DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev]  [RFCv2] service core concept
@ 2017-06-02 16:09 Van Haaren, Harry
  2017-06-03 10:22 ` Ananyev, Konstantin
  2017-06-05  7:23 ` Jerin Jacob
  0 siblings, 2 replies; 12+ messages in thread
From: Van Haaren, Harry @ 2017-06-02 16:09 UTC (permalink / raw)
  To: dev
  Cc: Thomas Monjalon, Jerin Jacob, Richardson, Bruce, Ananyev,
	Konstantin, Wiles, Keith

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

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.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-06-07 13:09 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-02 16:09 [dpdk-dev] [RFCv2] service core concept 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
2017-06-06 10:06   ` Van Haaren, Harry

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