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 8306F39EA for ; Thu, 29 Jun 2017 16:36:35 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 07:36:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,281,1496127600"; d="scan'208";a="1188537229" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga002.fm.intel.com with ESMTP; 29 Jun 2017 07:36:30 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.211]) by IRSMSX103.ger.corp.intel.com ([169.254.3.9]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 15:36:04 +0100 From: "Van Haaren, Harry" To: "dev@dpdk.org" CC: 'Jerin Jacob' , "thomas@monjalon.net" , "Wiles, Keith" , "Richardson, Bruce" Thread-Topic: Service lcores and Application lcores Thread-Index: AdLw4cih5pwlzbSuRKKmF+/821WngA== Date: Thu, 29 Jun 2017 14:36:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTJkOTM5NjgtOWE3Yi00YmE0LWFlMDAtMDYwYjI0MjdmYTg0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkUzeEhUcExsRWlVdUo4bTloeEVaNjdLWHYrWHEwRGk1Z0JvYWY0NVwvOGpNPSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] Service lcores and Application lcores 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: Thu, 29 Jun 2017 14:36:36 -0000 Hi All, The recently posted service cores patchset[1], introduces service lcores to= run services for DPDK applications. Services are just an ordinary function= for eg: eventdev scheduling, NIC RX, statistics and monitoring, etc. A ser= vice is just a callback function, which a core invokes. An atomic ensures t= hat services that are non-multi-thread-safe are never concurrently invoked. The topic of discussion in this thread is how we can ensure that applicatio= n lcores do not interfere with service cores. I have a solution described b= elow, opinions welcome. Regards, -Harry PS: This discussion extends that in the ML thread here[2], participants of = that thread added to CC. [1] Service Cores v2 patchset http://dpdk.org/dev/patchwork/bundle/hvanhaar= /service_cores_v2/ [2] http://dpdk.org/ml/archives/dev/2017-June/069290.html ________________________ A proposal for Eventdev, to ensure Service lcores and Application lcores pl= ay nice; 1) Application lcores must not directly call rte_eventdev_schedule() 2A) Service cores are the proper method to run services 2B) If an application insists on running a service "manually" on an app lco= re, we provide a function for that: rte_service_run_from_app_lcore(struct service *srv); The above function would allow a pesky app to run services on its own (non-= service core) lcores, but does so through the service-core framework, allowing the service-library at= omic to keep access serialized as required for non-multi-thread-safe servic= es. The above solution maintains the option of running the eventdev PMD as now = (single-core dedicated to a single service), while providing correct serial= ization by using the rte_service_run_from_app_lcore() function. Given the a= tomic is only used when required (multiple cores mapped to the service) the= re should be no performance delta. Given that the application should not invoke rte_eventdev_schedule(), we co= uld even consider removing it from the Eventdev API. A PMD that requires cy= cles registers a service, and an application can use a service core or the = run_from_app_lcore() function if it wishes to invoke that service on an app= lication owned lcore. Opinions?