From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 08:57:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,281,1496127600"; d="scan'208";a="1188572956" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.28]) by fmsmga002.fm.intel.com with SMTP; 29 Jun 2017 08:57:08 -0700 Received: by (sSMTP sendmail emulation); Thu, 29 Jun 2017 16:57:08 +0100 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" Message-ID: <20170629155707.GA15724@bricha3-MOBL3.ger.corp.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.1 (2017-04-11) Subject: Re: [dpdk-dev] Service lcores and Application lcores 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: Thu, 29 Jun 2017 15:57:17 -0000 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