[dpdk-dev] [0/9] examples/vm_power: 100% Busy Polling

[Hunt, David]

On 13/7/2018 9:33 AM, Thomas Monjalon wrote:
> 13/07/2018 10:31, Hunt, David:
>> Hi Thomas,
>>
>> On 12/7/2018 8:09 PM, Thomas Monjalon wrote:
>>> 26/06/2018 11:23, David Hunt:
>>>> This patch set adds the capability to do out-of-band power
>>>> monitoring on a system. It uses a thread to monitor the branch
>>>> counters in the targeted cores, and calculates the branch ratio
>>>> if the running code.
>>>>
>>>> If the branch ratop is low (0.01), then
>>>> the code is most likely running in a tight poll loop and doing
>>>> nothing, i.e. receiving no packets. In this case we scale down
>>>> the frequency of that core.
>>>>
>>>> If the branch ratio is higher (>0.01), then it is likely that
>>>> the code is receiving and processing packets. In this case, we
>>>> scale up the frequency of that core.
>>>>
>>>> The cpu counters are read via /dev/cpu/x/msr, so requires the
>>>> msr kernel module to be loaded. Because this method is used,
>>>> the patch set is implemented with one file for x86 systems, and
>>>> another for non-x86 systems, with conditional compilation in
>>>> the Makefile. The non-x86 functions are stubs, and do not
>>>> currently implement any functionality.
>>>>
>>>> The vm_power_manager app has been modified to take a new parameter
>>>>      --core-list or -l
>>>> which takes a list of cores in a comma-separated list format,
>>>> e.g. 1,3,5-7,9, which resolvest to a core list of 1,3,5,6,7,9
>>>> These cores will then be enabled for oob monitoring. When the
>>>> OOB monitoring thread starts, it reads the branch hits/miss
>>>> counters of each monitored core, and scales up/down accordingly.
>>> It looks to be a feature which could be integrated in DPDK libs.
>>> Why choosing to implement it fully in an example?
>> I needed to set up a thread that looped tightly (~100uS interval) and
>> run it on it's
>> own core. From what I have seen in other cases, it is usually the
>> application that
>> allocates cores and decides what to run on them. I did think about putting
>> some of it in a library, but for this case I thought it made more sense
>> to keep
>> it purely as a sample app.
> I feel some code deserves to be in a library.
> For instance, having different implementations per CPU is a good reason
> to make a library.
>

Sure, I can look at moving some of the code into the library in a future 
release. However, I
believe it's OK as it is for the current merge window.

Regards,
Dave.