-----Original Message----- > Date: Tue, 11 Jul 2017 12:32:58 +0000 > From: "Van Haaren, Harry" <harry.van.haa...@intel.com> > To: Thomas Monjalon <tho...@monjalon.net>, Jerin Jacob > <jerin.ja...@caviumnetworks.com> > CC: "dev@dpdk.org" <dev@dpdk.org>, "Wiles, Keith" <keith.wi...@intel.com>, > "Richardson, Bruce" <bruce.richard...@intel.com> > Subject: RE: [PATCH v4 1/7] service cores: header and implementation > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Tuesday, July 11, 2017 10:55 AM > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>; Van Haaren, Harry > > <harry.van.haa...@intel.com> > > Cc: dev@dpdk.org; Wiles, Keith <keith.wi...@intel.com>; Richardson, Bruce > > <bruce.richard...@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.