On Fri, Jan 8, 2021 at 5:42 PM Burakov, Anatoly <anatoly.bura...@intel.com> wrote: > > On 17-Dec-20 4:12 PM, David Marchand wrote: > > On Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov > > <anatoly.bura...@intel.com> wrote: > >> > >> This patchset proposes a simple API for Ethernet drivers to cause the > >> CPU to enter a power-optimized state while waiting for packets to > >> arrive. This is achieved through cooperation with the NIC driver that > >> will allow us to know address of wake up event, and wait for writes on > >> it. > >> > >> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They > >> are used in their raw opcode form because there is no widespread > >> compiler support for them yet. Still, the API is made generic enough to > >> hopefully support other architectures, if they happen to implement > >> similar instructions. > >> > >> To achieve power savings, there is a very simple mechanism used: we're > >> counting empty polls, and if a certain threshold is reached, we get the > >> address of next RX ring descriptor from the NIC driver, arm the > >> monitoring hardware, and enter a power-optimized state. We will then > >> wake up when either a timeout happens, or a write happens (or generally > >> whenever CPU feels like waking up - this is platform-specific), and > >> proceed as normal. The empty poll counter is reset whenever we actually > >> get packets, so we only go to sleep when we know nothing is going on. > >> The mechanism is generic which can be used for any write back > >> descriptor. > >> > >> This patchset also introduces a few changes into existing power > >> management-related intrinsics, namely to provide a native way of waking > >> up a sleeping core without application being responsible for it, as well > >> as general robustness improvements. There's quite a bit of locking going > >> on, but these locks are per-thread and very little (if any) contention > >> is expected, so the performance impact shouldn't be that bad (and in any > >> case the locking happens when we're about to sleep anyway, not on a > >> hotpath). > >> > >> Why are we putting it into ethdev as opposed to leaving this up to the > >> application? Our customers specifically requested a way to do it wit > >> minimal changes to the application code. The current approach allows to > >> just flip a switch and automatically have power savings. > >> > >> - Only 1:1 core to queue mapping is supported, meaning that each lcore > >> must at most handle RX on a single queue > >> - Support 3 type policies. Monitor/Pause/Frequency Scaling > >> - Power management is enabled per-queue > >> - The API doesn't extend to other device types > > > > Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this: > > https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082 > > > > We will have to put an exception on driver only ABI. > > > > > > Why does aarch64 build fail there? The functions in question are in the > version map file, but the build complains that they aren't.
>From what I can see, this series puts rte_power_* symbols in a .h. So it will be seen as symbols exported by any library including such a header. The check then complains about this as it sees exported symbols unknown of the library version.map. -- David Marchand
