From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v4 1/7] service cores: header and
	implementation
Date: Tue, 11 Jul 2017 18:14:31 +0530
Message-ID: <20170711124408.GA12964@jerin>
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>
 <E923DB57A917B54B9182A2E928D00FA640C3B248@IRSMSX102.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
 "Wiles, Keith" <keith.wiles@intel.com>,
 "Richardson, Bruce" <bruce.richardson@intel.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-BY2-obe.outbound.protection.outlook.com
 (mail-by2nam03on0077.outbound.protection.outlook.com [104.47.42.77])
 by dpdk.org (Postfix) with ESMTP id A2EF53250
 for <dev@dpdk.org>; Tue, 11 Jul 2017 14:45:23 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA640C3B248@IRSMSX102.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

-----Original Message-----
> Date: Tue, 11 Jul 2017 12:32:58 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob
>  <jerin.jacob@caviumnetworks.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, "Wiles, Keith" <keith.wiles@intel.com>,
>  "Richardson, Bruce" <bruce.richardson@intel.com>
> Subject: RE: [PATCH v4 1/7] service cores: header and implementation
> 
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Tuesday, July 11, 2017 10:55 AM
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>; Van Haaren, Harry
> > <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org; Wiles, Keith <keith.wiles@intel.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>
> > Subject: Re: [PATCH v4 1/7] service cores: header and implementation
> > 
> > 11/07/2017 10:29, Jerin Jacob:
> > > IMO, We don't need to expose rte_service_private.h to application. If
> > > you agree, add the following or similar change
> > 
> > If it must not be exposed, the file should not have the prefix rte_
> > In doc/api/doxy-api.conf, every files with rte_ prefix will be processed
> > for doxygen documentation:
> > 	FILE_PATTERNS = rte_*.h
> 
> 
> 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 is possible, as the application can register a service. The app then configures all services (including its own "app-service") to run on a service lcore.
> 
> If we hide the service registration from the application, we make it impossible for the application to multiplex services and application specific workloads on a single core.

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.

> 
> 
> I strongly prefer of leaving the header as is. Given we have EXPERIMENTAL tag, ABI/API are not a concern until later - we have time to figure out if the service-registration API is good enough in current form, before we commit to it.
> 
> I'll send v5 asap with headers as is.