Re: [PATCH v4 1/7] service cores: header and implementation

-----Original Message-----

Date: Tue, 11 Jul 2017 12:32:58 +0000
From: "Van Haaren, Harry" <redacted>
To: Thomas Monjalon <redacted>, Jerin Jacob
 [off-list ref]
CC: "dev@dpdk.org" <redacted>, "Wiles, Keith" <redacted>,
 "Richardson, Bruce" [off-list ref]
Subject: RE: [PATCH v4 1/7] service cores: header and implementation

quoted

From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Tuesday, July 11, 2017 10:55 AM
To: Jerin Jacob <redacted>; Van Haaren, Harry
[off-list ref]
Cc: dev@dpdk.org; Wiles, Keith <redacted>; Richardson, Bruce
[off-list ref]
Subject: Re: [PATCH v4 1/7] service cores: header and implementation

11/07/2017 10:29, Jerin Jacob:

quoted

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.