Power-optimized RX for Ethernet devices

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Signed-off-by Liang J. Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

---
 .../include/generic/rte_power_intrinsics.h    |  64 +++++++++
 lib/librte_eal/include/meson.build            |   1 +
 lib/librte_eal/x86/include/meson.build        |   1 +
 lib/librte_eal/x86/include/rte_cpuflags.h     |   1 +
 .../x86/include/rte_power_intrinsics.h        | 134 ++++++++++++++++++
 lib/librte_eal/x86/rte_cpuflags.c             |   2 +
 6 files changed, 203 insertions(+)
 create mode 100644 lib/librte_eal/include/generic/rte_power_intrinsics.h
 create mode 100644 lib/librte_eal/x86/include/rte_power_intrinsics.h

lib/librte_eal/include/generic/rte_power_intrinsics.h new file +64 -0

new file mode 100644
index 0000000000..8646c4ac16
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#ifndef _RTE_POWER_INTRINSIC_H_
+#define _RTE_POWER_INTRINSIC_H_
+
+#include <inttypes.h>
+
+/**
+ * @file
+ * Advanced power management operations.
+ *
+ * This file define APIs for advanced power management,
+ * which are architecture-dependent.
+ */
+
+/**
+ * Monitor specific address for changes. This will cause the CPU to enter an
+ * architecture-defined optimized power state until either the specified
+ * memory address is written to, or a certain TSC timestamp is reached.
+ *
+ * Additionally, an `expected` 64-bit value and 64-bit mask are provided. If
+ * mask is non-zero, the current value pointed to by the `p` pointer will be
+ * checked against the expected value, and if they match, the entering of
+ * optimized power state may be aborted.
+ *
+ * @param p
+ *   Address to monitor for changes. Must be aligned on an 8-byte boundary.
+ * @param expected_value
+ *   Before attempting the monitoring, the `p` address may be read and compared
+ *   against this value. If `value_mask` is zero, this step will be skipped.
+ * @param value_mask
+ *   The 64-bit mask to use to extract current value from `p`.
+ * @param state
+ *   Architecture-dependent optimized power state number
+ * @param tsc_timestamp
+ *   Maximum TSC timestamp to wait for. Note that the wait behavior is
+ *   architecture-dependent.
+ *
+ * @return
+ *   Architecture-dependent return value.
+ */
+static inline int rte_power_monitor(const volatile void *p,
+		const uint64_t expected_value, const uint64_t value_mask,
+		const uint32_t state, const uint64_t tsc_timestamp);
+
+/**
+ * Enter an architecture-defined optimized power state until a certain TSC
+ * timestamp is reached.
+ *
+ * @param state
+ *   Architecture-dependent optimized power state number
+ * @param tsc_timestamp
+ *   Maximum TSC timestamp to wait for. Note that the wait behavior is
+ *   architecture-dependent.
+ *
+ * @return
+ *   Architecture-dependent return value.
+ */
+static inline int rte_power_pause(const uint32_t state,
+		const uint64_t tsc_timestamp);
+
+#endif /* _RTE_POWER_INTRINSIC_H_ */

lib/librte_eal/include/meson.build +1 -0

index bc73ec2c5c..b54a2be4f6 100644
@@ -59,6 +59,7 @@ generic_headers = files(
 	'generic/rte_memcpy.h',
 	'generic/rte_pause.h',
 	'generic/rte_prefetch.h',
+	'generic/rte_power_intrinsics.h',
 	'generic/rte_rwlock.h',
 	'generic/rte_spinlock.h',
 	'generic/rte_ticketlock.h',

lib/librte_eal/x86/include/meson.build +1 -0

index f0e998c2fe..494a8142a2 100644
@@ -13,6 +13,7 @@ arch_headers = files(
 	'rte_io.h',
 	'rte_memcpy.h',
 	'rte_prefetch.h',
+	'rte_power_intrinsics.h',
 	'rte_pause.h',
 	'rte_rtm.h',
 	'rte_rwlock.h',

lib/librte_eal/x86/include/rte_cpuflags.h +1 -0

index c1d20364d1..94d6a43763 100644
@@ -110,6 +110,7 @@ enum rte_cpu_flag_t {
 	RTE_CPUFLAG_RDTSCP,                 /**< RDTSCP */
 	RTE_CPUFLAG_EM64T,                  /**< EM64T */
 
+	RTE_CPUFLAG_WAITPKG,                 /**< UMINITOR/UMWAIT/TPAUSE */
 	/* (EAX 80000007h) EDX features */
 	RTE_CPUFLAG_INVTSC,                 /**< INVTSC */
 

lib/librte_eal/x86/include/rte_power_intrinsics.h new file +134 -0

new file mode 100644
index 0000000000..a0522400fb
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#ifndef _RTE_POWER_INTRINSIC_X86_64_H_
+#define _RTE_POWER_INTRINSIC_X86_64_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_atomic.h>
+#include <rte_common.h>
+
+#include "generic/rte_power_intrinsics.h"
+
+/**
+ * Monitor specific address for changes. This will cause the CPU to enter an
+ * architecture-defined optimized power state until either the specified
+ * memory address is written to, or a certain TSC timestamp is reached.
+ *
+ * Additionally, an `expected` 64-bit value and 64-bit mask are provided. If
+ * mask is non-zero, the current value pointed to by the `p` pointer will be
+ * checked against the expected value, and if they match, the entering of
+ * optimized power state may be aborted.
+ *
+ * This function uses UMONITOR/UMWAIT instructions. For more information about
+ * their usage, please refer to Intel(R) 64 and IA-32 Architectures Software
+ * Developer's Manual.
+ *
+ * @param p
+ *   Address to monitor for changes. Must be aligned on an 8-byte boundary.
+ * @param expected_value
+ *   Before attempting the monitoring, the `p` address may be read and compared
+ *   against this value. If `value_mask` is zero, this step will be skipped.
+ * @param value_mask
+ *   The 64-bit mask to use to extract current value from `p`.
+ * @param state
+ *   Architecture-dependent optimized power state number. Can be 0 (C0.2) or
+ *   1 (C0.1).
+ * @param tsc_timestamp
+ *   Maximum TSC timestamp to wait for.
+ *
+ * @return
+ *   - 1 if wakeup was due to TSC timeout expiration.
+ *   - 0 if wakeup was due to memory write or other reasons.
+ */
+static inline int rte_power_monitor(const volatile void *p,
+		const uint64_t expected_value, const uint64_t value_mask,
+		const uint32_t state, const uint64_t tsc_timestamp)
+{
+	const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+	const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+	uint64_t rflags;
+
+	/*
+	 * we're using raw byte codes for now as only the newest compiler
+	 * versions support this instruction natively.
+	 */
+
+	/* set address for UMONITOR */
+	asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+			:
+			: "D"(p));
+	rte_mb();
+	if (value_mask) {
+		const uint64_t cur_value = *(const volatile uint64_t *)p;
+		const uint64_t masked = cur_value & value_mask;
+		/* if the masked value is already matching, abort */
+		if (masked == expected_value)
+			return 0;
+	}
+	/* execute UMWAIT */
+	asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;\n"
+		/*
+		 * UMWAIT sets CF flag in RFLAGS, so PUSHF to push them
+		 * onto the stack, then pop them back into `rflags` so that
+		 * we can read it.
+		 */
+		"pushf;\n"
+		"pop %0;\n"
+		: "=r"(rflags)
+		: "D"(state), "a"(tsc_l), "d"(tsc_h));
+
+	/* we're interested in the first bit (the carry flag) */
+	return rflags & 0x1;
+}
+
+/**
+ * Enter an architecture-defined optimized power state until a certain TSC
+ * timestamp is reached.
+ *
+ * This function uses TPAUSE instruction. For more information about its usage,
+ * please refer to Intel(R) 64 and IA-32 Architectures Software Developer's
+ * Manual.
+ *
+ * @param state
+ *   Architecture-dependent optimized power state number. Can be 0 (C0.2) or
+ *   1 (C0.1).
+ * @param tsc_timestamp
+ *   Maximum TSC timestamp to wait for.
+ *
+ * @return
+ *   - 1 if wakeup was due to TSC timeout expiration.
+ *   - 0 if wakeup was due to other reasons.
+ */
+static inline int rte_power_pause(const uint32_t state,
+		const uint64_t tsc_timestamp)
+{
+	const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+	const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+	uint64_t rflags;
+
+	/* execute TPAUSE */
+	asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;\n"
+		     /*
+		      * TPAUSE sets CF flag in RFLAGS, so PUSHF to push them
+		      * onto the stack, then pop them back into `rflags` so that
+		      * we can read it.
+		      */
+		     "pushf;\n"
+		     "pop %0;\n"
+		     : "=r"(rflags)
+		     : "D"(state), "a"(tsc_l), "d"(tsc_h));
+
+	/* we're interested in the first bit (the carry flag) */
+	return rflags & 0x1;
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_POWER_INTRINSIC_X86_64_H_ */

lib/librte_eal/x86/rte_cpuflags.c +2 -1

index 30439e7951..0325c4b93b 100644
@@ -110,6 +110,8 @@ const struct feature_entry rte_cpu_feature_table[] = {
 	FEAT_DEF(AVX512F, 0x00000007, 0, RTE_REG_EBX, 16)
 	FEAT_DEF(RDSEED, 0x00000007, 0, RTE_REG_EBX, 18)
 
+	FEAT_DEF(WAITPKG, 0x00000007, 0, RTE_REG_ECX, 5)
+
 	FEAT_DEF(LAHF_SAHF, 0x80000001, 0, RTE_REG_ECX,  0)
 	FEAT_DEF(LZCNT, 0x80000001, 0, RTE_REG_ECX,  4)
 
--

2.17.1

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Recently ARM guys introduced new generic API
for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Quoted 15 lines · Konstantin

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Quoted 5 lines

Recently ARM guys introduced new generic API
for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value. The "expected" value is there as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

Quoted 16 lines

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Quoted 5 lines

Recently ARM guys introduced new generic API
for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value.

The "expected" value is there
as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

Quoted 23 lines

Quoted 17 lines

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Quoted 5 lines

Recently ARM guys introduced new generic API
for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Quoted 4 lines

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value.

I understand that.

Quoted 4 lines

The "expected" value is there
as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

AFAIK, current rte_wait_until_equal_* does pretty much the same thing:

LDXR memaddr, $reg // an address to monitor for
if ($reg != expected_value)
SEVL // arm monitor
do {
WFE // waits for write to that memory address
LDXR memaddr, $reg
} while ($reg != expected_value);

Looks pretty similar to what rte_power_monitor() does, except you don't have a loop for checking the new value. Plus rte_power_monitor() provides extra options to the user - timestamp and power save mode to enter.
Also I don't know what is the granularity of such events on ARM, is it a cache-line or more/less.

Might be ARM people can comment/correct me here.
Konstantin

Quoted 45 lines · Konstantin

Quoted 23 lines

Quoted 17 lines

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more writes are expected.

Quoted 5 lines

Recently ARM guys introduced new generic API
for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Quoted 4 lines

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value.

I understand that.

Quoted 4 lines

The "expected" value is there
as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

AFAIK, current rte_wait_until_equal_* does pretty much the same thing:

LDXR memaddr, $reg // an address to monitor for
if ($reg != expected_value)
SEVL // arm monitor
do {
WFE // waits for write to that memory address
LDXR memaddr, $reg
} while ($reg != expected_value);

Quoted 6 lines

Looks pretty similar to what rte_power_monitor() does, except you don't have a loop for checking the new value. Plus rte_power_monitor() provides extra options to the user - timestamp and power save mode to enter.
Also I don't know what is the granularity of such events on ARM, is it a cache-line or more/less.

As I understand it, Granularity is per the cache-line. ie. Load-exclusive(LDXR) followed by WFE will wait in a low-power state until the cache line is written.

But I see UMONITOR bit different, Where _without_ other core signaling to wakeup from wait state,
it can wake on TSC expiry. I think, that's is the main primitive on this feature. Right?

WFE can also wake based on Timer stream events(kind of TSC in x86 analogy) but it has a configuration
bit that needs to allow for this scheme in userspace(EL0) or not? defined by EL1(Linux kernel).
I am planning to spend time on this after understanding the value addition of the feature/usecase[1]
[1]
http://mails.dpdk.org/archives/dev/2020-May/168888.html

Quoted 10 lines · Konstantin

Quoted 10 lines

Quoted 10 lines

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more

writes are expected.

Quoted 29 lines

Quoted 11 lines

Quoted 6 lines

Recently ARM guys introduced new generic API for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value.

I understand that.

Quoted 4 lines

The "expected" value is there
as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

AFAIK, current rte_wait_until_equal_* does pretty much the same thing:

LDXR memaddr, $reg // an address to monitor for if ($reg != expected_value)
SEVL // arm monitor
do {
WFE // waits for write to that memory address
LDXR memaddr, $reg
} while ($reg != expected_value);

Quoted 6 lines

Looks pretty similar to what rte_power_monitor() does, except you don't have a loop for checking the new value.
Plus rte_power_monitor() provides extra options to the user - timestamp and power save mode to enter.
Also I don't know what is the granularity of such events on ARM, is it a cache-line or more/less.

As I understand it, Granularity is per the cache-line.
ie. Load-exclusive(LDXR) followed by WFE will wait in a low-power state until the cache line is written.

But I see UMONITOR bit different, Where _without_ other core signaling to wakeup from wait state, it can wake on TSC expiry. I think, that's is the main primitive on this feature. Right?

WFE can also wake based on Timer stream events(kind of TSC in x86 analogy) but it has a configuration
bit that needs to allow for this scheme in userspace(EL0) or not? defined by EL1(Linux kernel).

I am planning to spend time on this after understanding the value addition of the feature/usecase[1] [1] http://mails.dpdk.org/archives/dev/2020-
May/168888.html

Quoted 2 lines

Might be ARM people can comment/correct me here.
Konstantin

<snip>

Quoted 56 lines

Quoted 10 lines · Konstantin

Quoted 10 lines

Quoted 10 lines

Hi Anatoly,

Quoted 6 lines

Add two new power management intrinsics, and provide an implementation in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions are implemented as raw byte opcodes because there is not yet widespread compiler support for these instructions.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

The power management instructions provide an architecture-specific function to either wait until a specified TSC timestamp is reached, or optionally wait until either a TSC timestamp is reached or a memory location is written to. The monitor function also provides an optional comparison, to avoid sleeping when the expected write has already happened, and no more

writes are expected.

Quoted 29 lines

Quoted 11 lines

Quoted 6 lines

Recently ARM guys introduced new generic API for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). Probably would make sense to unite both APIs into something common and HW transparent.
Konstantin

Hi Konstantin,

That's not really similar purpose. This is monitoring a cacheline for writes, not waiting on a specific value.

I understand that.

Quoted 4 lines

The "expected" value is there
as basically a hack to get around the race condition due to the fact that by the time you enter monitoring state, the write you're waiting for may have already happened.

AFAIK, current rte_wait_until_equal_* does pretty much the same thing:

LDXR memaddr, $reg // an address to monitor for if ($reg != expected_value)
SEVL // arm monitor
do {
WFE // waits for write to that memory address
LDXR memaddr, $reg
} while ($reg != expected_value);

Quoted 6 lines

Looks pretty similar to what rte_power_monitor() does, except you don't have a loop for checking the new value.
Plus rte_power_monitor() provides extra options to the user - timestamp and power save mode to enter.
Also I don't know what is the granularity of such events on ARM, is it a cache-line or more/less.

Quoted 3 lines

As I understand it, Granularity is per the cache-line.
ie. Load-exclusive(LDXR) followed by WFE will wait in a low-power state until the cache line is written.

Architecture allows for 16B to 2048B space. Typically, implementations use cache-line granularity.

Quoted 5 lines

But I see UMONITOR bit different, Where _without_ other core signaling to wakeup from wait state, it can wake on TSC expiry. I think, that's is the main primitive on this feature. Right?

Quoted 4 lines

WFE can also wake based on Timer stream events(kind of TSC in x86 analogy) but it has a configuration
bit that needs to allow for this scheme in userspace(EL0) or not? defined by EL1(Linux kernel).

Timer stream events are not per CPU core. They are system wide streams.

Quoted 11 lines

I am planning to spend time on this after understanding the value addition of the feature/usecase[1] [1] http://mails.dpdk.org/archives/dev/2020-
May/168888.html

Quoted 2 lines

Might be ARM people can comment/correct me here.
Konstantin

Add a simple API to allow getting address of getting notification information from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

Notes:
v11:
- Rework the API Doxygen documentation

v10:
- Address minor issue on comments and release notes

v8:
- Rename version map file name

v7:
- Fixed race condition (Konstantin)
- Slight rework of the structure of monitor code
- Added missing inline for wakeup

v6:
- Added wakeup mechanism for UMWAIT
- Removed memory allocation (everything is now allocated statically)
- Fixed various typos and comments
- Check for invalid queue ID
- Moved release notes to this patch

v5:
- Make error checking more robust
- Prevent initializing scaling if ACPI or PSTATE env wasn't set
- Prevent initializing UMWAIT path if PMD doesn't support get_wake_addr
- Add some debug logging
- Replace x86-specific code path to generic path using the intrinsic check
---

int
rte_eth_dev_set_mc_addr_list(uint16_t port_id,
struct rte_ether_addr *mc_addr_set,

lib/librte_ethdev/rte_ethdev.h +2 -0

index e341a08817..d208fe99ca 100644
@@ -4364,6 +4364,47 @@ __rte_experimental
  int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
  	struct rte_eth_burst_mode *mode);
 
+/**
+ * In order to make use of some PMD Power Management schemes, the user might

lib/librte_ethdev/rte_ethdev.h +4 -0

+ *
+ * @param[in] port_id
+ *  The port identifier of the Ethernet device.
+ * @param[in] queue_id

lib/librte_ethdev/rte_ethdev.h +12 -0

+ *
+ * @return
+ *  - 0: Success.
+ *  -ENOTSUP: Operation not supported.
+ *  -EINVAL: Invalid parameters.
+ *  -ENODEV: Invalid port ID.
+ */
+__rte_experimental
+int rte_eth_get_wake_addr(uint16_t port_id, uint16_t queue_id,
+		volatile void **wake_addr, uint64_t *expected, uint64_t *mask,
+		uint8_t *data_sz);
+
  /**
   * Retrieve device registers and register attributes (number of registers and
   * register size)

lib/librte_ethdev/rte_ethdev_driver.h +28 -0

index c63b9f7eb7..e7ce1e261d 100644
@@ -752,6 +752,32 @@ typedef int (*eth_hairpin_queue_peer_unbind_t)
  	(struct rte_eth_dev *dev, uint16_t cur_queue, uint32_t direction);
  /**< @internal Unbind peer queue from the current queue. */
 
+/**
+ * @internal
+ * Get address of memory location whose contents will change whenever there is
+ * new data to be received.
+ *
+ * @param rxq
+ *   Ethdev queue pointer.
+ * @param tail_desc_addr
+ *   The pointer point to where the address will be stored.
+ * @param expected
+ *   The pointer point to value to be expected when descriptor is set.
+ * @param mask
+ *   The pointer point to comparison bitmask for the expected value.
+ * @param data_sz
+ *   Data size for the expected value (can be 1, 2, 4, or 8 bytes)
+ * @return
+ *   Negative errno value on error, 0 on success.
+ *
+ * @retval 0
+ *   Success
+ * @retval -EINVAL
+ *   Invalid parameters
+ */
+typedef int (*eth_get_wake_addr_t)(void *rxq, volatile void **tail_desc_addr,
+		uint64_t *expected, uint64_t *mask, uint8_t *data_sz);
+
  /**
   * @internal A structure containing the functions exported by an Ethernet driver.
   */

@@ -910,6 +936,8 @@ struct eth_dev_ops {
  	/**< Set up the connection between the pair of hairpin queues. */
  	eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
  	/**< Disconnect the hairpin queues of a pair from each other. */
+	eth_get_wake_addr_t get_wake_addr;
+	/**< Get next RX queue ring entry address. */
  };
 
  /**

lib/librte_ethdev/version.map +1 -0

index 8ddda2547f..f9ce4e3c8d 100644
@@ -235,6 +235,7 @@ EXPERIMENTAL {
  	rte_eth_fec_get_capability;
  	rte_eth_fec_get;
  	rte_eth_fec_set;
+	rte_eth_get_wake_addr;
  	rte_flow_shared_action_create;
  	rte_flow_shared_action_destroy;
  	rte_flow_shared_action_query;

From: Liang Ma <[email protected]>

Add a simple API to allow getting the monitor conditions for power-optimized monitoring of the RX queues from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

Notes:
v6:
- Rebase on top of latest main
- Ensure the API checks queue ID (Konstantin)
- Removed accidental inclusion of unrelated release notes
v5:
- Bring function format in line with other functions in the file
- Ensure the API is supported by the driver before calling it (Konstantin)

 doc/guides/rel_notes/release_21_02.rst |  4 ++++
 lib/librte_ethdev/rte_ethdev.c         | 28 ++++++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev.h         | 25 +++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev_driver.h  | 22 ++++++++++++++++++++
 lib/librte_ethdev/version.map          |  3 +++
 5 files changed, 82 insertions(+)

doc/guides/rel_notes/release_21_02.rst +0 -0

index 638f98168b..feb3ff4f06 100644

doc/guides/rel_notes/release_21_02.rst +0 -0

 Removed Items
 -------------

lib/librte_ethdev/rte_ethdev.c +4 -0

index 17ddacc78d..58f68321ea 100644
@@ -5115,6 +5115,34 @@ rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
 		       dev->dev_ops->tx_burst_mode_get(dev, queue_id, mode));
 }
 
+int
+rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+		struct rte_power_monitor_cond *pmc)
+{

lib/librte_ethdev/rte_ethdev.c +14 -0

+		return -EINVAL;
+	}
+
+	if (pmc == NULL) {
+		RTE_ETHDEV_LOG(ERR, "Invalid power monitor condition=%p\n",
+				pmc);
+		return -EINVAL;
+	}
+
+	return eth_err(port_id,
+		dev->dev_ops->get_monitor_addr(dev->data->rx_queues[queue_id],
+			pmc));
+}
+
 int
 rte_eth_dev_set_mc_addr_list(uint16_t port_id,
 			     struct rte_ether_addr *mc_addr_set,

lib/librte_ethdev/rte_ethdev.h +25 -0

index f5f8919186..ca0f91312e 100644
@@ -157,6 +157,7 @@ extern "C" {
 #include <rte_common.h>
 #include <rte_config.h>
 #include <rte_ether.h>
+#include <rte_power_intrinsics.h>
 
 #include "rte_ethdev_trace_fp.h"
 #include "rte_dev_info.h"

@@ -4334,6 +4335,30 @@ __rte_experimental
 int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
 	struct rte_eth_burst_mode *mode);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the monitor condition for a given receive queue.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param queue_id
+ *   The Rx queue on the Ethernet device for which information
+ *   will be retrieved.
+ * @param pmc
+ *   The pointer point to power-optimized monitoring condition structure.
+ *
+ * @return
+ *   - 0: Success.
+ *   -ENOTSUP: Operation not supported.
+ *   -EINVAL: Invalid parameters.
+ *   -ENODEV: Invalid port ID.
+ */
+__rte_experimental
+int rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+		struct rte_power_monitor_cond *pmc);
+
 /**
  * Retrieve device registers and register attributes (number of registers and
  * register size)

lib/librte_ethdev/rte_ethdev_driver.h +0 -0

index 0eacfd8425..ae4f152cf0 100644

lib/librte_ethdev/rte_ethdev_driver.h +16 -0

+ *
+ * @param rxq
+ *   Ethdev queue pointer.
+ * @param pmc
+ *   The pointer to power-optimized monitoring condition structure.
+ * @return
+ *   Negative errno value on error, 0 on success.
+ *
+ * @retval 0
+ *   Success
+ * @retval -EINVAL
+ *   Invalid parameters
+ */
+typedef int (*eth_get_monitor_addr_t)(void *rxq,
+		struct rte_power_monitor_cond *pmc);
+
 /**
  * @internal A structure containing the functions exported by an Ethernet driver.
  */

lib/librte_ethdev/rte_ethdev_driver.h +0 -0

 };
 
 /**

lib/librte_ethdev/version.map +3 -0

index d3f5410806..a124e1e370 100644
@@ -240,6 +240,9 @@ EXPERIMENTAL {
 	rte_flow_get_restore_info;
 	rte_flow_tunnel_action_decap_release;
 	rte_flow_tunnel_item_release;
+
+	# added in 21.02
+	rte_eth_get_monitor_addr;
 };
 
 INTERNAL {

Quoted 10 lines · Anatoly Burakov

From: Liang Ma <[email protected]>

Add a simple API to allow getting the monitor conditions for power-optimized monitoring of the RX queues from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

doc/guides/rel_notes/release_21_02.rst New Features · line 58

Quoted 5 lines

doc/guides/rel_notes/release_21_02.rst +1 -0

@@ -55,6 +55,10 @@ New Features
       Also, make sure to start the actual text at the margin.
       =======================================================
 
+* **ethdev: added 1 new API for PMD power management**

"1 new API" sounds a bit confusing. May be just "a new API"?

doc/guides/rel_notes/release_21_02.rst New Features · line 61

Quoted 3 lines

doc/guides/rel_notes/release_21_02.rst +3 -0

+
+  * ``rte_eth_get_monitor_addr()``, to be used in conjunction with
+    ``rte_power_monitor()`` to enable automatic power management for PMD's.

Missing extra empty line here.

Quoted 15 lines

doc/guides/rel_notes/release_21_02.rst +0 -0

  Removed Items
  -------------

lib/librte_ethdev/rte_ethdev.c +4 -0

index 17ddacc78d..58f68321ea 100644
@@ -5115,6 +5115,34 @@ rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
  		       dev->dev_ops->tx_burst_mode_get(dev, queue_id, mode));
  }
 
+int
+rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+		struct rte_power_monitor_cond *pmc)
+{

lib/librte_ethdev/rte_ethdev.c rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id, · line 5131

Quoted 10 lines

lib/librte_ethdev/rte_ethdev.c +10 -0

+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_monitor_addr, -ENOTSUP);
+
+	if (queue_id >= dev->data->nb_tx_queues) {
+		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);

Why is Tx queue checked and logged here, but Rx queue is used below? I guess Rx should be used here as well.

I.e. TX -> Rx

Quoted 68 lines

lib/librte_ethdev/rte_ethdev.c +14 -0

+		return -EINVAL;
+	}
+
+	if (pmc == NULL) {
+		RTE_ETHDEV_LOG(ERR, "Invalid power monitor condition=%p\n",
+				pmc);
+		return -EINVAL;
+	}
+
+	return eth_err(port_id,
+		dev->dev_ops->get_monitor_addr(dev->data->rx_queues[queue_id],
+			pmc));
+}
+
  int
  rte_eth_dev_set_mc_addr_list(uint16_t port_id,
  			     struct rte_ether_addr *mc_addr_set,

lib/librte_ethdev/rte_ethdev.h +25 -0

index f5f8919186..ca0f91312e 100644
@@ -157,6 +157,7 @@ extern "C" {
  #include <rte_common.h>
  #include <rte_config.h>
  #include <rte_ether.h>
+#include <rte_power_intrinsics.h>
 
  #include "rte_ethdev_trace_fp.h"
  #include "rte_dev_info.h"

@@ -4334,6 +4335,30 @@ __rte_experimental
  int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
  	struct rte_eth_burst_mode *mode);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the monitor condition for a given receive queue.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param queue_id
+ *   The Rx queue on the Ethernet device for which information
+ *   will be retrieved.
+ * @param pmc
+ *   The pointer point to power-optimized monitoring condition structure.
+ *
+ * @return
+ *   - 0: Success.
+ *   -ENOTSUP: Operation not supported.
+ *   -EINVAL: Invalid parameters.
+ *   -ENODEV: Invalid port ID.
+ */
+__rte_experimental
+int rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+		struct rte_power_monitor_cond *pmc);
+
  /**
   * Retrieve device registers and register attributes (number of registers and
   * register size)

lib/librte_ethdev/rte_ethdev_driver.h +0 -0

index 0eacfd8425..ae4f152cf0 100644
@@ -763,6 +763,26 @@ typedef int (*eth_hairpin_queue_peer_unbind_t)
  	(struct rte_eth_dev *dev, uint16_t cur_queue, uint32_t direction);
  /**< @internal Unbind peer queue from the current queue. */
 

lib/librte_ethdev/rte_ethdev_driver.h typedef int (*eth_hairpin_queue_peer_unbind_t) · line 769

Quoted 4 lines

lib/librte_ethdev/rte_ethdev_driver.h +4 -0

+/**
+ * @internal
+ * Get address of memory location whose contents will change whenever there is
+ * new data to be received on an RX queue.

RX -> Rx

Quoted 19 lines

lib/librte_ethdev/rte_ethdev_driver.h +16 -0

+ *
+ * @param rxq
+ *   Ethdev queue pointer.
+ * @param pmc
+ *   The pointer to power-optimized monitoring condition structure.
+ * @return
+ *   Negative errno value on error, 0 on success.
+ *
+ * @retval 0
+ *   Success
+ * @retval -EINVAL
+ *   Invalid parameters
+ */
+typedef int (*eth_get_monitor_addr_t)(void *rxq,
+		struct rte_power_monitor_cond *pmc);
+
  /**
   * @internal A structure containing the functions exported by an Ethernet driver.
   */

lib/librte_ethdev/rte_ethdev_driver.h struct eth_dev_ops { · line 941

Quoted 6 lines

lib/librte_ethdev/rte_ethdev_driver.h +2 -0

@@ -917,6 +937,8 @@ struct eth_dev_ops {
  	/**< Set up the connection between the pair of hairpin queues. */
  	eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
  	/**< Disconnect the hairpin queues of a pair from each other. */
+	eth_get_monitor_addr_t get_monitor_addr;
+	/**< Get next RX queue ring entry address. */

RX -> Rx

Quoted 18 lines

lib/librte_ethdev/rte_ethdev_driver.h +0 -0

  };
 
  /**

lib/librte_ethdev/version.map +3 -0

index d3f5410806..a124e1e370 100644
@@ -240,6 +240,9 @@ EXPERIMENTAL {
  	rte_flow_get_restore_info;
  	rte_flow_tunnel_action_decap_release;
  	rte_flow_tunnel_item_release;
+
+	# added in 21.02
+	rte_eth_get_monitor_addr;
  };
 
  INTERNAL {

From: Liang Ma <[email protected]>

Add a simple API to allow getting the monitor conditions for power-optimized monitoring of the RX queues from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

Quoted 11 lines · Anatoly Burakov

From: Liang Ma <[email protected]>

Add a simple API to allow getting the monitor conditions for power-optimized monitoring of the RX queues from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

<snip>

Quoted 9 lines

/**
* @internal A structure containing the functions exported by an Ethernet driver. */

lib/librte_ethdev/rte_ethdev_driver.h +2 -0

@@ -917,6 +937,8 @@ struct eth_dev_ops {
         /**< Set up the connection between the pair of hairpin queues. */
         eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
         /**< Disconnect the hairpin queues of a pair from each other. */
+       eth_get_monitor_addr_t get_monitor_addr;
+       /**< Get next RX queue ring entry address. */

Review struct eth_dev_ops { · line 943

Quoted 2 lines

(quoted diff) +0 -0

  };
 

The implementation of get_monitor_addr will have much in common with the rx_descriptor_status API in struct rte_eth_dev, including the property that it will likely not make sense for it to be called concurrently with rx_pkt_burst on a given queue. Might it make more sense to have this API in struct rte_eth_dev instead of struct eth_dev_ops?

Quoted 23 lines

Quoted 11 lines · Anatoly Burakov

From: Liang Ma <[email protected]>

Add a simple API to allow getting the monitor conditions for power-optimized monitoring of the RX queues from the PMD, as well as release notes information.

Signed-off-by Liang Ma <[email protected]>

Signed-off-by Anatoly Burakov <[email protected]>

Acked-by Konstantin Ananyev <[email protected]>

---

<snip>

Quoted 9 lines

/**
* @internal A structure containing the functions exported by an Ethernet driver. */

lib/librte_ethdev/rte_ethdev_driver.h +2 -0

@@ -917,6 +937,8 @@ struct eth_dev_ops {
         /**< Set up the connection between the pair of hairpin queues. */
         eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
         /**< Disconnect the hairpin queues of a pair from each other. */
+       eth_get_monitor_addr_t get_monitor_addr;
+       /**< Get next RX queue ring entry address. */

Quoted 9 lines

Review struct eth_dev_ops { · line 943

Quoted 2 lines

(quoted diff) +0 -0

  };
 

The implementation of get_monitor_addr will have much in common with the rx_descriptor_status API in struct rte_eth_dev, including the property that it will likely not make sense for it to be called concurrently with rx_pkt_burst on a given queue. Might it make more sense to have this API in struct rte_eth_dev instead of struct eth_dev_ops?

I don't have an opinion on this as this code isn't really my area of expertise. I'm fine with wherever the community thinks this code should be. Any other opinions?

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

Quoted 38 lines · Anatoly Burakov

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.

Quoted 5 lines

- 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.

Quoted 49 lines · David Marchand

Quoted 38 lines · Anatoly Burakov

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.

Quoted 5 lines

- 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

Quoted 3 lines

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.

Quoted 2 lines · Anatoly

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.

Quoted 11 lines · David Marchand

Quoted 2 lines · Anatoly

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.

Quick fix:

lib/librte_eal/arm/include/rte_power_intrinsics.h +0 -29

index 39e49cc45b..9e498e9ebf 100644
@@ -13,35 +13,6 @@ extern "C" {
 
  #include "generic/rte_power_intrinsics.h"
 
-/**
- * This function is not supported on ARM.
- */
-void
-rte_power_monitor(const struct rte_power_monitor_cond *pmc,
-               const uint64_t tsc_timestamp)
-{
-       RTE_SET_USED(pmc);
-       RTE_SET_USED(tsc_timestamp);
-}
-
-/**
- * This function is not supported on ARM.
- */
-void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
-       RTE_SET_USED(tsc_timestamp);
-}
-
-/**
- * This function is not supported on ARM.
- */
-void
-rte_power_monitor_wakeup(const unsigned int lcore_id)
-{
-       RTE_SET_USED(lcore_id);
-}
-
  #ifdef __cplusplus
  }
  #endif

lib/librte_eal/arm/meson.build +1 -0

index d62875ebae..6ec53ea03a 100644
@@ -7,4 +7,5 @@ sources += files(
         'rte_cpuflags.c',
         'rte_cycles.c',
         'rte_hypervisor.c',
+       'rte_power_intrinsics.c',
  )

lib/librte_eal/arm/rte_power_intrinsics.c new file +31 -0

new file mode 100644
index 0000000000..998f9898ad
@@ -0,0 +1,31 @@
+#include <rte_common.h>
+#include <rte_power_intrinsics.h>
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor(const struct rte_power_monitor_cond *pmc,
+               const uint64_t tsc_timestamp)
+{
+       RTE_SET_USED(pmc);
+       RTE_SET_USED(tsc_timestamp);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+       RTE_SET_USED(tsc_timestamp);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor_wakeup(const unsigned int lcore_id)
+{
+       RTE_SET_USED(lcore_id);
+}

HTH.

-----Original Message-----
From: Burakov, Anatoly <[email protected]>
Sent: Friday, January 8, 2021 5:42 PM
To: [email protected]
Cc: Jan Viktorin <[email protected]>; Ruifeng Wang <[email protected]>; Jerin Jacob <[email protected]>; David Christensen <[email protected]>; Ray Kinsella <[email protected]>; Neil Horman <[email protected]>; Richardson, Bruce <[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; McDaniel, Timothy <[email protected]>; Hunt, David <[email protected]>; Macnamara, Chris <[email protected]>
Subject: [PATCH v13 01/11] eal: uninline power intrinsics

Currently, power intrinsics are inline functions. Make them part of the ABI so that we can have various internal data associated with them without exposing said data to the outside world.

Signed-off-by Anatoly Burakov <[email protected]>

---

--
2.25.1