From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 8DB31292D for ; Wed, 17 May 2017 00:48:03 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2017 15:48:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,351,1491289200"; d="scan'208";a="857616347" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 16 May 2017 15:48:02 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 16 May 2017 15:48:01 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.235]) by fmsmsx115.amr.corp.intel.com ([169.254.4.213]) with mapi id 14.03.0319.002; Tue, 16 May 2017 15:48:01 -0700 From: "Wiles, Keith" To: Thomas Monjalon CC: "Van Haaren, Harry" , DPDK , "Richardson, Bruce" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Vangati, Narender" , Jerin Jacob , "Eads, Gage" Thread-Topic: [dpdk-dev] [RFC] Service Cores concept Thread-Index: AQHSxAC1lMfbckZN+Ui8xRDbyonazKH4D/wAgAAKSwA= Date: Tue, 16 May 2017 22:48:00 +0000 Message-ID: <97735AA8-2CCB-4432-9D9B-114C89CA3F50@intel.com> References: <1493810961-139469-1-git-send-email-harry.van.haaren@intel.com> <5129240.aMJQgb24zL@xps> In-Reply-To: <5129240.aMJQgb24zL@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.65.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <9EAAAB9D1087044EB2AB29B67BF4D338@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 16 May 2017 22:48:04 -0000 > On May 16, 2017, at 3:11 PM, Thomas Monjalon wrote: >=20 > 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. >>=20 >> The application now continues as normal, without having to manually >> schedule and implement arbitration of CPU time for the SW services. >=20 > I think it should not be the DPDK responsibility to schedule threads. > The mainloops and scheduling are application design choices. >=20 > 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? I did not really see the RFC as replacing the current design in DPDK for th= read handling, but that maybe just me. What I saw was a design to create an= d destroy threads more dynamically or possible some type of thread pool des= ign. DPDK needs a thread handler anyway (as we have one now) and the current one= seems to work, but it does not allow for someone to replace the thread han= dling with something different. What I would suggest is figure out how to p= ull DPDK current thread handling out into a plugin design, then someone can= replace that plugin with his own thread handling scheme. We need to keep DPDK stable, so adding the plugin support and pulling out t= he current design needs to be transparent to all current applications using= the current APIs and methods. Regards, Keith