From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: Service lcores and Application lcores Date: Thu, 29 Jun 2017 16:57:08 +0100 Message-ID: <20170629155707.GA15724@bricha3-MOBL3.ger.corp.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , 'Jerin Jacob' , "thomas@monjalon.net" , "Wiles, Keith" To: "Van Haaren, Harry" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 8707937A0 for ; Thu, 29 Jun 2017 17:57:16 +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" 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 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. /Bruce