> From: dev [mailto:dev-boun...@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.
