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 via email to