From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 33BF22986 for ; Wed, 17 May 2017 13:28:16 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A2072088D; Wed, 17 May 2017 07:28:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 17 May 2017 07:28:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=pcM4Jt36rWXIZkh 7z3jOPu72UxpVJGsuqAR1w26/avY=; b=JcgPW0lUSngcjyVAs9sYKqskqNh/1Zv kKQ9YDKH9h61vuJRqNGaIUaGc6ulpSumMaz0ROsyo3woPLOpJ9V5bLyk9w029whf Rq3xoEK/T53WCbkMaq55kNBxJhRJJgBgFIOoUlYfr5I/GX1sk0tpAD41vugKM0zK RaoVhSD9jBOs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=pcM4Jt36rWXIZkh7z3jOPu72UxpVJGsuqAR1w26/avY=; b=fmVO3sJU QgtizbQBhtFiqaJT/qbuQLfEJR7llrlwF6gzLJLSu/q9h6zlm9uhooOzAFwzSJfe GVu8gg5tipLGJv6puggyZzY2+5wx28V9WRqaAW508yH4cHj2dh+ZKLIB/oQIP3P+ 8CeP/KNUSSAuRN4EQvcJUAs8UBcMeitziCrq3hYGzzoaCGryW/4KRf3s9GY5/zpQ hVJjKPXMmP0nEGbi88xDhEVQexbs1RX/cnTHf+Opkj48F3BpaekHB71n4Nyo5wPa 5QQg26qGbNxcaRVPwUelAetyS0P+sGjTx/wkbVis1iFuzH5k0CId+M+ZdoTqn8+s OZDVGq1bz8O4cw== X-ME-Sender: X-Sasl-enc: V52tzzCuQUKvCkuwVb2lKvkHj1xg2g1evgvNSNaet1Xh 1495020495 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 580317E0EE; Wed, 17 May 2017 07:28:15 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: Harry van Haaren , dev@dpdk.org, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, jerin.jacob@caviumnetworks.com, gage.eads@intel.com, Keith Wiles Date: Wed, 17 May 2017 13:28:14 +0200 Message-ID: <3696663.2JsLXSjzmN@xps> In-Reply-To: <20170517103228.GA14292@bricha3-MOBL3.ger.corp.intel.com> References: <1493810961-139469-1-git-send-email-harry.van.haaren@intel.com> <5129240.aMJQgb24zL@xps> <20170517103228.GA14292@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] Service Cores 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: Wed, 17 May 2017 11:28:16 -0000 17/05/2017 12:32, Bruce Richardson: > On Wed, May 17, 2017 at 12:11:10AM +0200, Thomas Monjalon wrote: > > 03/05/2017 13:29, Harry van Haaren: > > > The concept is to allow a software function register itself with EAL as > > > a "service", which requires CPU time to perform its duties. Multiple > > > services can be registered in an application, if more than one service > > > exists. The application can retrieve a list of services, and decide how > > > many "service cores" to use. The number of service cores is removed > > > from the application usage, and they are mapped to services based on > > > an application supplied coremask. > > > > > > The application now continues as normal, without having to manually > > > schedule and implement arbitration of CPU time for the SW services. > > > > I think it should not be the DPDK responsibility to schedule threads. > > The mainloops and scheduling are application design choices. > > > > If I understand well the idea of your proposal, it is a helper for > > the application to configure the thread scheduling of known services. > > So I think we could add interrupt processing and other thread creations > > in this concept. > > Could we also embed the rte_eal_mp_remote_launch() calls in this concept? > > > There are a couple of parts of this: > 1. Allowing libraries and drivers to register the fact that they require > background processing, e.g. as a SW fallback for functionality that > would otherwise be implemented in hardware > 2. Providing support for easily multi-plexing these independent > functions from different libs onto a different core, compared to the > normal operation of DPDK of firing a single run-forever function on each > 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 > 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. For > instance, removing the service cores from the core list in foreach-lcore > loops, and preventing the EAL from trying to run app functions on the > cores when the app calls mp_remote_launch. > > Overall, the objective is to provide us a way to have software > equivalents of hardware functions in as transparent a manner as > possible. There is a certain amount of scheduling being done by the > DPDK, but it is still very much under the control of the app. > > As for other things being able to use this concept, definite +1 for > interrupt threads and similar. I would not see mp_remote_launch as being > affected here in any significant way (except from the hiding service > cores from it, obviously) OK to register CPU needs for services (including interrupts processing). Then we could take this opportunity to review how threads are managed. We will have three types of cores: - not used - reserved for services - used for polling / application processing It is fine to reserve/define CPU from DPDK point of view. Then DPDK launch threads on cores. Maybe we should allow the application to choose how threads are launched and managed. Keith was talking about a plugin approach for thread management I think.