[dpdk-dev] lib/power: add turbo functions to version.map

  allows vm_power_manager example to be built against shared libraries

Signed-off-by: David Hunt <david.hunt@intel.com>
---
 lib/librte_power/rte_power_version.map | 9 +++++++++
 1 file changed, 9 insertions(+)
  

Hi,
I have some comments about the API scope and some formatting.

Suggested title:
	power: add turbo functions to map file

02/10/2017 14:20, David Hunt:
> allows vm_power_manager example to be built against shared libraries

Fixes: 94608a0f7f45 ("power: add per-core turbo boost API")

> Signed-off-by: David Hunt <david.hunt@intel.com>
[...]
> +DPDK_17.11 {
> +	global:
> +
> +	rte_power_acpi_turbo_status;

Is it really the function you want to expose?
rte_power_turbo_status seems more generic.

More comments about what is part of the API:
If you do not want to expose ACPI and VM implementations,
it should not be part of the rte_* include files.

> +	rte_power_freq_disable_turbo;
> +	rte_power_freq_enable_turbo;
> +};
> +

This is a trailing new line.
  

Hi Thomas


On 2/10/2017 3:55 PM, Thomas Monjalon wrote:
> Hi,
> I have some comments about the API scope and some formatting.
>
> Suggested title:
> 	power: add turbo functions to map file
>
> 02/10/2017 14:20, David Hunt:
>> allows vm_power_manager example to be built against shared libraries
> Fixes: 94608a0f7f45 ("power: add per-core turbo boost API")

Sure, I'll address this in next version.
>> Signed-off-by: David Hunt <david.hunt@intel.com>
> [...]
>> +DPDK_17.11 {
>> +	global:
>> +
>> +	rte_power_acpi_turbo_status;
> Is it really the function you want to expose?
> rte_power_turbo_status seems more generic.

Not really, it was in there for completeness, but users should be able 
to keep track of the turbo'd cores, so not really needed.

> More comments about what is part of the API:
> If you do not want to expose ACPI and VM implementations,
> it should not be part of the rte_* include files.
>
>> +	rte_power_freq_disable_turbo;
>> +	rte_power_freq_enable_turbo;
>> +};
>> +
> This is a trailing new line.
>
>


I'll address the above comments in the next version.

Regards,
Dave.
  

02/10/2017 17:06, Hunt, David:
> On 2/10/2017 3:55 PM, Thomas Monjalon wrote:
>> +DPDK_17.11 {
> >> +	global:
> >> +
> >> +	rte_power_acpi_turbo_status;
> > Is it really the function you want to expose?
> > rte_power_turbo_status seems more generic.
> 
> Not really, it was in there for completeness, but users should be able 
> to keep track of the turbo'd cores, so not really needed.
> 
> > More comments about what is part of the API:
> > If you do not want to expose ACPI and VM implementations,
> > it should not be part of the rte_* include files.
> 
> I'll address the above comments in the next version.

You did not address the comment about what is rte_*.h.
If you do not want to expose everything, you should move it to
another .h file.

Files starting with rte_ are included in doxygen API doc.
Only rte_power.h is installed.
The installed include, the doxygen doc and the map file
should all expose the same API consistently.

I think a cleanup is needed.
  

Hi Thomas,


On 2/10/2017 4:39 PM, Thomas Monjalon wrote:
> 02/10/2017 17:06, Hunt, David:
>> On 2/10/2017 3:55 PM, Thomas Monjalon wrote:
>>> +DPDK_17.11 {
>>>> +	global:
>>>> +
>>>> +	rte_power_acpi_turbo_status;
>>> Is it really the function you want to expose?
>>> rte_power_turbo_status seems more generic.
>> Not really, it was in there for completeness, but users should be able
>> to keep track of the turbo'd cores, so not really needed.
>>
>>> More comments about what is part of the API:
>>> If you do not want to expose ACPI and VM implementations,
>>> it should not be part of the rte_* include files.
>> I'll address the above comments in the next version.
> You did not address the comment about what is rte_*.h.
> If you do not want to expose everything, you should move it to
> another .h file.
>
> Files starting with rte_ are included in doxygen API doc.
> Only rte_power.h is installed.
> The installed include, the doxygen doc and the map file
> should all expose the same API consistently.
>
> I think a cleanup is needed.

While I agree a cleanup is needed, this small patch is only intended to 
fix the priority issue of the shared library builds, which are broken at 
the moment.
The initial patch should have had rte_power_turbo_status, not 
rte_power_acpi_turbo_status.
Rather than moving code around at this stage, I propose having the three 
exposed functions in the map file (with the correct names).
Then, later on, I can do an ABI breakage notification for the next 
release to rename all the other rte*.h files, as some consumers of DPDK 
may be using those directly, at which stage we will be down to just 
exporting the functions in rte_power.h.
Does that sound OK with you?
Regards,
Dave.
  

02/10/2017 18:25, Hunt, David:
> Hi Thomas,
> 
> 
> On 2/10/2017 4:39 PM, Thomas Monjalon wrote:
> > 02/10/2017 17:06, Hunt, David:
> >> On 2/10/2017 3:55 PM, Thomas Monjalon wrote:
> >>> +DPDK_17.11 {
> >>>> +	global:
> >>>> +
> >>>> +	rte_power_acpi_turbo_status;
> >>> Is it really the function you want to expose?
> >>> rte_power_turbo_status seems more generic.
> >> Not really, it was in there for completeness, but users should be able
> >> to keep track of the turbo'd cores, so not really needed.
> >>
> >>> More comments about what is part of the API:
> >>> If you do not want to expose ACPI and VM implementations,
> >>> it should not be part of the rte_* include files.
> >> I'll address the above comments in the next version.
> > 
> > You did not address the comment about what is rte_*.h.
> > If you do not want to expose everything, you should move it to
> > another .h file.
> >
> > Files starting with rte_ are included in doxygen API doc.
> > Only rte_power.h is installed.
> > The installed include, the doxygen doc and the map file
> > should all expose the same API consistently.
> >
> > I think a cleanup is needed.
> 
> While I agree a cleanup is needed, this small patch is only intended to 
> fix the priority issue of the shared library builds, which are broken at 
> the moment.
> The initial patch should have had rte_power_turbo_status, not 
> rte_power_acpi_turbo_status.
> Rather than moving code around at this stage, I propose having the three 
> exposed functions in the map file (with the correct names).

OK, so we need a v3 (v2 has only 2 functions).

> Then, later on, I can do an ABI breakage notification for the next 
> release to rename all the other rte*.h files, as some consumers of DPDK 
> may be using those directly, at which stage we will be down to just 
> exporting the functions in rte_power.h.
> Does that sound OK with you?

OK, thanks