On 18-Jan-21 3:24 PM, David Marchand wrote:
On Thu, Jan 14, 2021 at 3:46 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. There are multiple proposed mechanisms to achieve said power
savings: simple frequency scaling, idle loop, and monitoring the Rx
queue for incoming packages. The latter is achieved through cooperation
with the NIC driver that will allow us to know address of wake up event,
and wait for writes on that address.
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 employ
one of the suggested power management schemes automatically, from within
a Rx callback inside the PMD. Once there's traffic again, the empty poll
counter is reset.
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).
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 with
minimal changes to the application code. The current approach allows to
just flip a switch and automatically have power savings.
Things of note:
- 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
v17:
- Added exception for ethdev driver-only ABI
- Added memory barriers for monitor/wakeup (Konstantin)
- Fixed compiled issues on non-x86 platforms (hopefully!)
SPDK build is still broken.
http://mails.dpdk.org/archives/test-report/2021-January/174840.html
==== 20 line log output for Ubuntu 18.04 (dpdk_compile_spdk): ====
rte_power_pmd_mgmt.c:(.text.experimental+0x1cc): undefined reference
to `rte_eth_add_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x1f8): undefined reference
to `rte_eth_get_monitor_addr'
rte_power_pmd_mgmt.c:(.text.experimental+0x37f): undefined reference
to `rte_eth_dev_logtype'
/dpdk/build/lib/librte_power.a(librte_power_rte_power_pmd_mgmt.c.o):
In function `rte_power_pmd_mgmt_queue_disable':
rte_power_pmd_mgmt.c:(.text.experimental+0x42a): undefined reference
to `rte_eth_dev_is_valid_port'
rte_power_pmd_mgmt.c:(.text.experimental+0x4e7): undefined reference
to `rte_eth_remove_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x536): undefined reference
to `rte_eth_remove_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x54d): undefined reference
to `rte_eth_dev_logtype'
collect2: error: ld returned 1 exit status
/spdk/mk/spdk.app.mk:65: recipe for target 'iscsi_fuzz' failed
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'iscsi_fuzz' failed
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'fuzz' failed
make[4]: *** [iscsi_fuzz] Error 1
make[3]: *** [iscsi_fuzz] Error 2
make[2]: *** [fuzz] Error 2
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'app' failed
make[1]: *** [app] Error 2
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'test' failed
make: *** [test] Error 2
[2] Error running command.
I guess this is because of the added dependency of rte_ethdev to rte_power.
Afaics, SPDK does not use pkg-config:
https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
Sooo... this is an SPDK issue then? Because i can't see any way of
fixing the issue on DPDK side.
--
Thanks,
Anatoly
