From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id DF39A7D04 for ; Fri, 2 Jun 2017 18:09:16 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 09:09:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,285,1493708400"; d="scan'208";a="108480657" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga005.jf.intel.com with ESMTP; 02 Jun 2017 09:09:14 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.52]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0319.002; Fri, 2 Jun 2017 17:09:13 +0100 From: "Van Haaren, Harry" To: "dev@dpdk.org" CC: Thomas Monjalon , Jerin Jacob , "Richardson, Bruce" , "Ananyev, Konstantin" , "Wiles, Keith" Thread-Topic: [dpdk-dev] [RFCv2] service core concept Thread-Index: AdLbug0EIDngSYVITLmskNXYmitsLA== Date: Fri, 2 Jun 2017 16:09:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODg1MGNlN2UtNzQzZi00YTM4LTk4OTctMGQzMDU1NzQ0YzQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkdWR1daUTVaNndHRUQ3NUVRbmRhTTdXSitLWVhqMDdxbDBhOUN3aDRIdU09In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] [RFCv2] service core concept X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:09:17 -0000 > 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 >=20 > Thanks everybody for the input on the RFC - appreciated! From an applicat= ion point-of-view, I > see merit in Konstantin's suggestions for the API, over the RFC I sent pr= eviously. 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 prev= iously[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, a= nd the other comments taken into account. In my opinion this v2 API is more applic= ation-centric, and enables the common application tasks much better. Such tasks are for ex= ample start/stop of a service, and add/remove of a service core. In particular this version of the API enables applications that are not awa= re of services to benefit from the services concept, as EAL args can be used to setup service= s and service cores. With this design, switching to/from SW/HW PMD is transparent to the applica= tion. An example use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a service = core.=20 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 desig= n. 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 ba= ckground processing 2. Providing support for easily multiplexing these independent functions fr= om 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 th= e rest of the application, so that the rest of the app logic does not need to change depending on w= hether service cores are in use or not =3D=3D=3D RFC v2 API =3D=3D=3D 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:=20 A service requires a core. It only knows about its NUMA node, and that it r= equires CPU time. Registration of a service requires only that information. Service Config: An application may configure what service runs where using the Service Conf= ig APIs. EAL is capable of performing this during rte_eal_init() if requested by pas= sing 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 Servic= eCore Config, allowing dynamically scaling the number of used lcores by services. Lcores used as s= ervice-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 rt= e_cpuset_t *coremask); int32_t rte_service_start(struct rte_service_spec *service); /* runtime fun= ction */ int32_t rte_service_stop(struct rte_service_spec *service); /* runtime fun= ction */ 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.