From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id B964C7CF9 for ; Sat, 3 Jun 2017 12:22:53 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2017 03:22:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,289,1493708400"; d="scan'208";a="1137581980" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga001.jf.intel.com with ESMTP; 03 Jun 2017 03:22:50 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.250]) by IRSMSX108.ger.corp.intel.com ([169.254.11.133]) with mapi id 14.03.0319.002; Sat, 3 Jun 2017 11:22:49 +0100 From: "Ananyev, Konstantin" To: "Van Haaren, Harry" , "dev@dpdk.org" CC: Thomas Monjalon , Jerin Jacob , "Richardson, Bruce" , "Wiles, Keith" Thread-Topic: [dpdk-dev] [RFCv2] service core concept Thread-Index: AdLbug0EIDngSYVITLmskNXYmitsLAAmDFfA Date: Sat, 3 Jun 2017 10:22:48 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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: Sat, 03 Jun 2017 10:22:54 -0000 Hi Harry, > > > > Thanks everybody for the input on the RFC - appreciated! From an applic= ation 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'l= l be on CC :) >=20 >=20 > Hi All, >=20 > This email is the v2 RFC for Service Cores, in response to the v1 sent pr= eviously[1]. > The service-cores API has been updated, and various concepts have changed= . >=20 > 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 appl= ication-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. >=20 > In particular this version of the API enables applications that are not a= ware of services to > benefit from the services concept, as EAL args can be used to setup servi= ces and service cores. > With this design, switching to/from SW/HW PMD is transparent to the appli= cation. An example > use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a servic= e 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 implementati= on feedback in the > follow-up patchset to v2 RFC. >=20 > Below a summary of what we are trying to achieve, and the current API des= ign. > 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?=20 Might be better to leave it to the particular app to decide. Konstantin >=20 >=20 > 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 thes= e 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 >=20 >=20 > =3D=3D=3D RFC v2 API =3D=3D=3D >=20 > There are 3 parts to the API; they separate the concerns of each "user" o= f the API: > - Service Registration > - Service Config > - ServiceCore Config >=20 > 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. >=20 > Service Config: > An application may configure what service runs where using the Service Co= nfig APIs. > EAL is capable of performing this during rte_eal_init() if requested by p= assing a > --service-cores argument. The application (mostly) calls these functions = at initialization > time, with start() and stop() being available to dynamically switch on/of= f a service if required. >=20 > ServiceCore Config > An application can start/stop or add/remove service-lcores using the Serv= iceCore 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() a= s they are already in use. >=20 >=20 > Service Registration: > int32_t rte_service_register(const struct rte_service_spec *spec); > int32_t rte_service_unregister(struct rte_service_spec *service); >=20 > 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 f= unction */ > int32_t rte_service_stop(struct rte_service_spec *service); /* runtime f= unction */ >=20 > 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); >=20 >=20 > I am working on a patchset - but for now I would appreciate general desig= n feedback, > particularly if a specific use-case is not handled.