I think work for ODP PM can be focused on following:
Let's imagine example 10Gb link can be processes on 4 cores on about
100% cpu load on top speed. Or it can be
on 8 cores with 50% load on top speed. Or 8 cores and 100% cpu load on
half core speed. Or 2 cores on top speed
and other of half speed. So question is which state is more power
efficient and supports long live for hardware
(less fan rotating, less heating and etc.)? (Plus add Bit-Little cores
question).
Logically right answer depends on platform and application itself. But
application can give hints to the platform which
mode it needs: power saving or top speed. Or even switch cpu to top
speed mode when processing some heavy function.
For NICs dpdk looks at rx pktio queue and changes C state if queue is
close to full:
http://dpdk.org/doc/guides/prog_guide/power_man.html
SoCs should be a little bit complex and should allow to change clk for
different things. It might be better to talk with our HW vendors
and ask what they can do. I.e. what do they need from API point of view
to be more efficient.
Best regards,
Maxim.
On 11/20/2015 23:56, Bill Fischofer wrote:
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
<mailto: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 <mailto: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
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
