>From an ODP application standpoint there are several factors to consider. First, power management if fundamentally a concern of the ODP implementation more than then application. The main way a data plane application should manage its workload is by creating and terminating worker threads (probably as instructed by the control/management plane which is managing the overall workload). With isolated cores, if there is no thread to run this is an obvious candidate for the core to enter a low-power state until such time as a thread wants to make use of it. There's no need for an explicit API here--the fact that the thread isolated on that core is terminating should be sufficient.
Beyond this, the proper place for these considerations are in the implementation of the odp scheduler and to a lesser degree the various synchronizers. When a thread calls odp_schedule() the scheduler knows whether it has events to dispatch. If none are available, then it would be reasonable for the scheduler to consider informing the underlying OS that it this thread/core is idle and thus eligible for power management. There's always a tradeoff here between energy savings and responsiveness to wakeups on new events arriving. Such tradeoffs are again the domain of the control/management plane. The advantage of this approach is that ODP itself becomes independent of whether it is running in a real or virtual machine environment, which is important as NFV becomes more of the norm. On Fri, Nov 20, 2015 at 8:51 AM, Hongbo Zhang <hongbo.zh...@linaro.org> wrote: > Hi guys, > https://projects.linaro.org/browse/ODP-242 > I'd like to discuss with you about this issue, hope you can make it > clear about the real requirement, give suggestions and make a > coincident conclusion before we go further on a wrong way. > > First question is what is the original requirement? "core shutdown and > startup" means cpudile or hot plug? or no specific requirement but > just want to save the power? > > I think when odp wants to control the power consumption, a > precondition should be isolation or similar, eg no other else share > the cpu with odp, then when odp load becomes low it can start any > method to save power. > > Basically three mechanisms can be used for saving power, > cpudile,cpufreq and hot plug. > Usually cpuidle is done by kernel, if we want to try it in user space > that will be too complicated to implement, so I give it up firstly. > The cpufreq and hot plug, from my point of view, can be tried. But a > precondition is we know that the cpu isn't fully loaded. While the odp > is always polling, so from legacy point of view the cpu load should be > 100%, in fact the cpu may not handle packets all the time, sometimes > it polls nothing. So we need to create a function to get statistics of > the "real load". > > Then further questions, should we create such a statistics interface? > how is the feasibility? by monitoring the cpu time, or by monitoring > the queues? or others? > (if we put every items in queues, then queues empty means nothing to do?) > > I've already had some comments on that Jira link, and Ivan gave his > valuable comments too, do you have further comments/suggestions? you > can leave them here, or let's discuss at the meeting: > https://collaborate.linaro.org/display/LNG/2015-11-23+ODP+ARCH > Hope we get coincident idea at meeting. > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
