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 A5C602BBD for ; Wed, 7 Jun 2017 11:50:44 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 02:50:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,310,1493708400"; d="scan'208";a="110184539" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga005.jf.intel.com with ESMTP; 07 Jun 2017 02:50:43 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.250]) by IRSMSX106.ger.corp.intel.com ([169.254.8.236]) with mapi id 14.03.0319.002; Wed, 7 Jun 2017 10:50:41 +0100 From: "Ananyev, Konstantin" To: "Van Haaren, Harry" , "Richardson, Bruce" CC: "dev@dpdk.org" , Thomas Monjalon , Jerin Jacob , "Wiles, Keith" Thread-Topic: [dpdk-dev] [RFCv2] service core concept Thread-Index: AdLbug0EIDngSYVITLmskNXYmitsLAAmDFfAAJaZv6AAB+sMgAAChhgAAADg5nAAJk9SQA== Date: Wed, 7 Jun 2017 09:50:41 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FB06787@IRSMSX109.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com> <20170606145347.GA55760@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFCv2] service core 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, 07 Jun 2017 09:50:45 -0000 > -----Original Message----- > From: Van Haaren, Harry > Sent: Tuesday, June 6, 2017 4:41 PM > To: Ananyev, Konstantin ; Richardson, Bruce= > Cc: dev@dpdk.org; Thomas Monjalon ; Jerin Jacob ; Wiles, Keith > > Subject: RE: [dpdk-dev] [RFCv2] service core concept >=20 > > From: Ananyev, Konstantin > > Sent: Tuesday, June 6, 2017 4:29 PM > > Subject: RE: [dpdk-dev] [RFCv2] service core concept > > > > > > > From: Richardson, Bruce > > > Sent: Tuesday, June 6, 2017 3:54 PM > > > > > > On Tue, Jun 06, 2017 at 11:25:57AM +0100, Van Haaren, Harry wrote: > > > > > From: Ananyev, Konstantin > > > > > Sent: Saturday, June 3, 2017 11:23 AM > > > > > > > > >=20 > >=20 > > > > > > > > There are a number of options here, each with its own merit: > > > > > > > > A) Services/cores config in EAL > > > > Benefit is that service functionality can be transparent to the app= lication. Negative is > > that the complexity is in EAL. > > > > > > > > B) Application configures services/cores > > > > Benefit is no added EAL complexity. Negative is that application co= de has to configure > > cores (duplicated per application). > > > > > > > > > > > > To answer this question, I think we need to estimate how many appli= cations would benefit > > from EAL integration and balance that against > > > the "complexity cost" of doing so. I do like the simplicity of option= (B), however if there > > is significant value in total transparency to the > > > application I think (A) is the better choice. > > > > > > > > > > > > Input on A) or B) welcomed! -Harry > > > > > > I'm definitely in favour of having it in EAL. The whole reason for do= ing > > > this work is to make it easy for applications to dedicate cores to > > > background tasks - including applications written before this > > > functionality was added. By merging this into EAL, we can have > > > transparency in the app, as we can have the service cores completely = in > > > the background, and the app can call rte_eal_mp_remote_launch() exact= ly > > > as before, without unexpected failures. If we move this externally, t= he > > > app needs to be reworked to take account of that fact, and call new, > > > service-core aware, launch functions instead. > > > > Not sure I understood you here: > > If the app don' plan to use any cores for services, it for sure will be= able to call > > rte_eal_mp_remote_launch() as before (no services running case). >=20 > Correct - EAL behavior remains unchanged if --service-cores=3D0xf is not = passed >=20 >=20 > > From other side, if the app would like to use services - it would need = to specify > > which service it wants to run, and for each service provide a coremask,= even if > > EAL already allocates service cores for it. >=20 > See next paragraph >=20 >=20 > > Or are you talking about the when EAL allocates service cores, and then > > PMDs themselves (or EAL again) register their services on that cores? >=20 > EAL could provide sane default behavior. For example, round-robin service= s over available service-cores. Multithread-capable services can > be registered on all service cores. Its not a perfect solution for all se= rvice-to-core mapping problems, but I'd guess about 80% of cases > would be covered: using a single service with a single service core dedic= ated to it :) >=20 >=20 > > That's probably possible, but how PMD would know which service core(s) = it allowed to use? >=20 > The PMD shouldn't be deciding - EAL for basic sanity config, or Applicati= on for advanced usage. >=20 >=20 > > Things might get over-complicated here - in theory there could be multi= ple PMDs, > > each of them can have more than one service, running on multiple sets o= f cores, etc. >=20 > True - the NxM service:core mapping possibility can be huge - the API all= ows the application the flexibility if that flexibility is really required. > If the flexibility is not required, the round-robin 1:1 service:core EAL = scheme should cover it? Ok, so if I understand you right: by default EAL will allow each PMD to reg= ister it's services on all available service cores? Konstantin=20