From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFCv2] service core concept Date: Mon, 5 Jun 2017 12:53:07 +0530 Message-ID: <20170605072306.GA1280@jerin> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , Thomas Monjalon , "Richardson, Bruce" , "Ananyev, Konstantin" , "Wiles, Keith" To: "Van Haaren, Harry" Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0070.outbound.protection.outlook.com [104.47.38.70]) by dpdk.org (Postfix) with ESMTP id 4D6DC7CCE for ; Mon, 5 Jun 2017 09:23:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Fri, 2 Jun 2017 16:09:13 +0000 > From: "Van Haaren, Harry" > To: "dev@dpdk.org" > CC: Thomas Monjalon , Jerin Jacob > , "Richardson, Bruce" > , "Ananyev, Konstantin" > , "Wiles, Keith" > 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.