[dpdk-dev] [PATCH 0/6] power: fix make build for power apps
Burakov, Anatoly
anatoly.burakov at intel.com
Wed Jan 13 18:30:37 CET 2021
On 13-Jan-21 1:25 PM, David Hunt wrote:
>
> On 13/1/2021 11:18 AM, Burakov, Anatoly wrote:
>> On 13-Jan-21 11:14 AM, David Hunt wrote:
>>> Hi Anatoly,
>>>
>>> On 13/1/2021 11:08 AM, Burakov, Anatoly wrote:
>>>> On 08-Jan-21 2:30 PM, David Hunt wrote:
>>>>> The power example applications that uses the virtio-serial method of
>>>>> communication cannot currently be built with make, and can only be
>>>>> built
>>>>> using meson/ninja.
>>>>>
>>>>> The guest channel message definitions and functions in guest_channel.h
>>>>> are needed by applications and need to be made public.
>>>>>
>>>>> This worked pre-20.11, but now with all the meson/ninja changes,
>>>>> making
>>>>> these apps externally no longer works. To fix, we need to move the
>>>>> header
>>>>> file with the API definitions for the channel commands public, and
>>>>> rename
>>>>> the functions accordingly.
>>>>>
>>>>> The main change is to rename channel_commands.h to
>>>>> rte_power_guest_channel.h so that it gets picked up by the
>>>>> installer and
>>>>> copied to /usr/local/include. Other changes include renaming
>>>>> #defines to
>>>>> have RTE_ at the beginning instead of CPU_. Finally we refactor the
>>>>> code
>>>>> to work with those changes.
>>>>>
>>>>> ---
>>>>> v2 changes
>>>>> - re-worked from monolithic patch to a 6 patch patchset for
>>>>> easier review
>>>>>
>>>>> [PATCH v2 1/6] power: create guest channel public header file
>>>>> [PATCH v2 2/6] power: make channel msg functions public
>>>>> [PATCH v2 3/6] power: rename public structs
>>>>> [PATCH v2 4/6] power: rename defines
>>>>> [PATCH v2 5/6] power: add new header file to export list
>>>>> [PATCH v2 6/6] power: clean up includes
>>>>>
>>>>
>>>> Just a general question: wouldn't it be better to move this stuff
>>>> entirely into sample app and not bother with keeping it in the
>>>> library? There is precedent - ethtool app has a "library" and an
>>>> "application" part, i think you should be able to move it out of the
>>>> library and into the sample app entirely without too much trouble,
>>>> as code looks to be fairly self-contained.
>>>>
>>>
>>> Agreed, that's a great idea. I could have a common lib under
>>> examples/vm_power_manager, then two apps, vm_power_manager and
>>> guest_cli. That would keep everything nicely local, and not expose
>>> the channel API publicly. The only reason we were making it public
>>> was to allow "make" to work, so that's not a good enought reason,
>>> tbh. I'll throw a prototype together today.
>>
>> Yep, IIRC Make works perfectly fine with ethtool, so i don't see why
>> it wouldn't work for your sample app as well. Thanks!
>
>
> Hi Anatoly,
>
> OK, so I was investigating this, and have come across a blocker on this
> method.
>
> There are three methods for managing frequency, acpi, pstate and vm.
> It's the third method that's causing the problem with moving the channel
> functionality out into a sample library alongside vm_power_manger. VM's
> can call channel functions in the power library to affect frequency for
> their cores, and these functions use api function calls and several
> structures and #defines in their code, which is currently part of the
> power management library. These function declarations, structs and
> #defines ere needed in both the examples lib/apps and the power library
> itself, and the prototype changes I made ended up looking very much like
> the patch set that's already on the mailing list.
>
> So, while I would have liked to have a solution along the lines of what
> you've proposed, it's not possible based on the dependencies on common
> structues and #defines.
>
> Thanks for the suggestion, though.
>
> Rgds,
> Dave.
>
OK, i guess we can live with that. I wonder if there's another way to do
this, but since i can't think of anything that doesn't involve serious
API/ABI breakages, this is OK IMO.
--
Thanks,
Anatoly
More information about the dev
mailing list