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 2FD3D2C1A for ; Wed, 7 Jun 2017 12:29:55 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 03:29:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,310,1493708400"; d="scan'208";a="865453253" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by FMSMGA003.fm.intel.com with ESMTP; 07 Jun 2017 03:29:54 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.242]) by IRSMSX106.ger.corp.intel.com ([169.254.8.236]) with mapi id 14.03.0319.002; Wed, 7 Jun 2017 11:29:53 +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+sMgAAChhgAAADg5nAAJk9SQAAArcmw Date: Wed, 7 Jun 2017 10:29:52 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772583FB0525F@IRSMSX109.ger.corp.intel.com> <20170606145347.GA55760@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB06531@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB06787@IRSMSX109.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB06787@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTQxMzg5ODEtYWFiYS00Nzk2LTk1ZDQtMzJmODJmMjlkODNmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImFpWjFHTHRjaHlDbTV5VFJkQXNTc09EYkxRdW95TkI5bWh4dlhyYmM4TEU9In0= 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: Wed, 07 Jun 2017 10:29:56 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Wednesday, June 7, 2017 10:51 AM > To: Van Haaren, Harry ; Richardson, Bruce > > Cc: dev@dpdk.org; Thomas Monjalon ; Jerin Jacob > ; Wiles, Keith > Subject: RE: [dpdk-dev] [RFCv2] service core concept >=20 >=20 >=20 > > -----Original Message----- > > From: Van Haaren, Harry > > Sent: Tuesday, June 6, 2017 4:41 PM > > To: Ananyev, Konstantin ; Richardson, Bru= ce > > > Cc: dev@dpdk.org; Thomas Monjalon ; Jerin Jacob > ; Wiles, Keith > > > > Subject: RE: [dpdk-dev] [RFCv2] service core concept > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > 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 a= pplication. 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 app= lications would > benefit > > > from EAL integration and balance that against > > > > the "complexity cost" of doing so. I do like the simplicity of opti= on (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 = doing > > > > 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 completel= y in > > > > the background, and the app can call rte_eal_mp_remote_launch() exa= ctly > > > > 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. > > > > > > 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). > > > > Correct - EAL behavior remains unchanged if --service-cores=3D0xf is no= t passed > > > > > > > From other side, if the app would like to use services - it would nee= d to specify > > > which service it wants to run, and for each service provide a coremas= k, even if > > > EAL already allocates service cores for it. > > > > See next paragraph > > > > > > > Or are you talking about the when EAL allocates service cores, and th= en > > > PMDs themselves (or EAL again) register their services on that cores? > > > > EAL could provide sane default behavior. For example, round-robin servi= ces over available > service-cores. Multithread-capable services can > > be registered 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 ded= icated 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 Applica= tion for advanced > usage. > > > > > > > Things might get over-complicated here - in theory there could be mul= tiple 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 a= llows the application > the flexibility if that flexibility is really required. > > If the flexibility is not required, the round-robin 1:1 service:core EA= L scheme should cover > it? >=20 > Ok, so if I understand you right: by default EAL will allow each PMD to r= egister it's services > on all available service cores? Close, but I don't see the PMD being involved in core mapping. I think of i= t like this: 1) A PMD registers its service (unaware of number of service cores availabl= e) 2) EAL provides default core to service mappings 2.1) Application configures using API for advanced uses (optional) Worked examples of EAL default core mapping with two services registered: - Eventdev SW PMD - Ethdev to eventdev RX Example A) With cores >=3D services, the services get one core assigned eac= h: ./dpdk-app --service-cores=3D0x3 eventdev_sw0 : lcore 0 ethdev_to_eventdev_rx0 : lcore 1 Example B) With more services than cores, the services share the available = cores:=20 ./dpdk-app --service-cores=3D0x1 eventdev_sw0 : lcore 0 ethdev_to_eventdev_rx0 : lcore 0 The EAL core-mapping logic round-robins services onto cores. If there are m= ore cores than services, they are not used (and a warning print given). If = there are more services than cores, they are wrapped back to the first core= , and services share the core (example B). Keep in mind this is just for simple use-cases. For complex services to cor= es mappings the application has the service API to configure it precisely a= s it wishes.