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 D2FAB2C6A for ; Tue, 11 Jul 2017 14:49:27 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 05:49:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,346,1496127600"; d="scan'208";a="125149052" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga005.fm.intel.com with ESMTP; 11 Jul 2017 05:49:24 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.211]) by IRSMSX151.ger.corp.intel.com ([169.254.4.191]) with mapi id 14.03.0319.002; Tue, 11 Jul 2017 13:49:22 +0100 From: "Van Haaren, Harry" To: Jerin Jacob CC: Thomas Monjalon , "dev@dpdk.org" , "Wiles, Keith" , "Richardson, Bruce" Thread-Topic: [PATCH v4 1/7] service cores: header and implementation Thread-Index: AQHS9z/jwjXkVTa0DESrgHxIpVBb1KJOQHgAgAAXsoCAADtJkP//9CuAgAARKhA= Date: Tue, 11 Jul 2017 12:49:21 +0000 Message-ID: References: <1498735421-100164-1-git-send-email-harry.van.haaren@intel.com> <1499445667-32588-2-git-send-email-harry.van.haaren@intel.com> <20170711082950.GB29792@jerin> <13391507.vzRJCuhnFb@xps> <20170711124408.GA12964@jerin> In-Reply-To: <20170711124408.GA12964@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTQ1YmFjMDEtMTAwZi00Y2Q0LTkxZmMtNzM5MzBjYjcwZTA0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjNaeE9NeWgyXC9EWEpBMjNvdnpGeGF6bGxya2hZQXlhODlWcktUMDFqOXgwPSJ9 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: Re: [dpdk-dev] [PATCH v4 1/7] service cores: header and implementation 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, 11 Jul 2017 12:49:28 -0000 > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Tuesday, July 11, 2017 1:45 PM > To: Van Haaren, Harry > Cc: Thomas Monjalon ; dev@dpdk.org; Wiles, Keith > ; Richardson, Bruce > Subject: Re: [PATCH v4 1/7] service cores: header and implementation > > The service registration API should be exposed to the application. > > > > Imagine a use case where the application wants to run services *and* an= application > specific function on the same core. In the current implementation this i= s possible, as > the application can register a service. The app then configures all servi= ces (including > its own "app-service") to run on a service lcore. > > > > If we hide the service registration from the application, we make it im= possible for the > application to multiplex services and application specific workloads on a= single core. >=20 > Then we could move the registration functions to service.h. > IMO, It does not look correct if we expose _prviate.h to application or > we could rename to service_component.h or something like that. Fair enough - I will rename to rte_service_component.h for v5. Thanks for i= nput!