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

[Thomas Monjalon <thomas@monjalon.net>]

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.