From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 8087A532D for ; Tue, 6 Jun 2017 17:40:52 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 08:40:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,306,1493708400"; d="scan'208";a="270853647" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga004.fm.intel.com with ESMTP; 06 Jun 2017 08:40:50 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.242]) by IRSMSX151.ger.corp.intel.com ([169.254.4.191]) with mapi id 14.03.0319.002; Tue, 6 Jun 2017 16:40:49 +0100 From: "Van Haaren, Harry" To: "Ananyev, Konstantin" , "Richardson, Bruce" CC: "dev@dpdk.org" , Thomas Monjalon , Jerin Jacob , "Wiles, Keith" Thread-Topic: [dpdk-dev] [RFCv2] service core concept Thread-Index: AdLbug0EIDngSYVITLmskNXYmitsLAAmDFfAAJaZv6AAB+sMgAAChhgAAADg5nA= Date: Tue, 6 Jun 2017 15:40:48 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com> <20170606145347.GA55760@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWUzYjhiZDAtNjkzNC00ZTg5LTliMGQtMTUxMmNmODNlN2JmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImJtK2o4bWdncmx4QVJHWG03V3NkNWpPY2t0T21JODZjS200N2Q5Q3RPUjg9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] 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: Tue, 06 Jun 2017 15:40:53 -0000 > From: Ananyev, Konstantin > Sent: Tuesday, June 6, 2017 4:29 PM > Subject: RE: [dpdk-dev] [RFCv2] service core concept >=20 >=20 > > 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 > > > > > > > > > > > > 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 appli= cation. Negative is > that the complexity is in EAL. > > > > > > B) Application configures services/cores > > > Benefit is no added EAL complexity. Negative is that application code= has to configure > cores (duplicated per application). > > > > > > > > > To answer this question, I think we need to estimate how many applica= tions 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 doin= g > > 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() exactly > > as before, without unexpected failures. If we move this externally, the > > app needs to be reworked to take account of that fact, and call new, > > service-core aware, launch functions instead. >=20 > Not sure I understood you here: > If the app don' plan to use any cores for services, it for sure will be a= ble to call > rte_eal_mp_remote_launch() as before (no services running case). Correct - EAL behavior remains unchanged if --service-cores=3D0xf is not pa= ssed > 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, e= ven if > EAL already allocates service cores for it. See next paragraph > Or are you talking about the when EAL allocates service cores, and then > PMDs themselves (or EAL again) register their services on that cores? EAL could provide sane default behavior. For example, round-robin services = over available service-cores. Multithread-capable services can be registere= d on all service cores. Its not a perfect solution for all service-to-core = mapping problems, but I'd guess about 80% of cases would be covered: using = a single service with a single service core dedicated to it :) > That's probably possible, but how PMD would know which service core(s) it= allowed to use? The PMD shouldn't be deciding - EAL for basic sanity config, or Application= for advanced usage. > Things might get over-complicated here - in theory there could be multipl= e PMDs, > each of them can have more than one service, running on multiple sets of = cores, etc. True - the NxM service:core mapping possibility can be huge - the API allow= s the application the flexibility if that flexibility is really required. I= f the flexibility is not required, the round-robin 1:1 service:core EAL sch= eme should cover it? -Harry