From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: Service lcores and Application lcores Date: Fri, 30 Jun 2017 10:15:09 +0530 Message-ID: <20170630044508.GA3735@jerin> References: <20170629155707.GA15724@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Van Haaren, Harry" , "dev@dpdk.org" , "thomas@monjalon.net" , "Wiles, Keith" To: Bruce Richardson Return-path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0051.outbound.protection.outlook.com [104.47.33.51]) by dpdk.org (Postfix) with ESMTP id 3CFC22C2A for ; Fri, 30 Jun 2017 06:45:31 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20170629155707.GA15724@bricha3-MOBL3.ger.corp.intel.com> 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: Thu, 29 Jun 2017 16:57:08 +0100 > From: Bruce Richardson > To: "Van Haaren, Harry" > CC: "dev@dpdk.org" , 'Jerin Jacob' > , "thomas@monjalon.net" > , "Wiles, Keith" > Subject: Re: Service lcores and Application lcores > User-Agent: Mutt/1.8.1 (2017-04-11) > > On Thu, Jun 29, 2017 at 03:36:04PM +0100, Van Haaren, Harry wrote: > > Hi All, > > > > > > The recently posted service cores patchset[1], introduces service lcores to run services for DPDK applications. Services are just an ordinary function for eg: eventdev scheduling, NIC RX, statistics and monitoring, etc. A service is just a callback function, which a core invokes. An atomic ensures that services that are > > non-multi-thread-safe are never concurrently invoked. > > > > The topic of discussion in this thread is how we can ensure that application lcores do not interfere with service cores. I have a solution described below, opinions welcome. > > > > > > Regards, -Harry > > > > > > PS: This discussion extends that in the ML thread here[2], participants of that thread added to CC. > > > > [1] Service Cores v2 patchset http://dpdk.org/dev/patchwork/bundle/hvanhaar/service_cores_v2/ > > [2] http://dpdk.org/ml/archives/dev/2017-June/069290.html > > > > > > ________________________ > > > > > > > > A proposal for Eventdev, to ensure Service lcores and Application lcores play nice; > > > > 1) Application lcores must not directly call rte_eventdev_schedule() > > 2A) Service cores are the proper method to run services > > 2B) If an application insists on running a service "manually" on an app lcore, we provide a function for that: > > rte_service_run_from_app_lcore(struct service *srv); > > > > The above function would allow a pesky app to run services on its own (non-service core) lcores, but > > does so through the service-core framework, allowing the service-library atomic to keep access serialized as required for non-multi-thread-safe services. > > > > The above solution maintains the option of running the eventdev PMD as now (single-core dedicated to a single service), while providing correct serialization by using the rte_service_run_from_app_lcore() function. Given the atomic is only used when required (multiple cores mapped to the service) there should be no performance delta. > > > > Given that the application should not invoke rte_eventdev_schedule(), we could even consider removing it from the Eventdev API. A PMD that requires cycles registers a service, and an application can use a service core or the run_from_app_lcore() function if it wishes to invoke that service on an application owned lcore. > > > > > > Opinions? > > I would be in favour of this proposal, except for the proposed name for > the new function. It would be useful for an app to be able to "adopt" a > service into it's main loop if so desired. If we do this, I think I'd +1 Agree with Harry and Bruce here. I think, The adapter function should take "struct service *" and return lcore_function_t so that it can run using exiting rte_eal_remote_launch() > also support the removal of a dedicated schedule call from the eventdev > API, or alternatively, if it is needed by other PMDs, leave it as a > no-op in the sw PMD in favour of the service-cores managed function. I would be in favor of removing eventdev schedule and RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability so that it is completely transparent to application whether scheduler runs on HW or SW or "combination of both" > > /Bruce