From: Jerin Jacob <jerinjacobk@gmail.com>
To: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Cc: harry.van.haaren@intel.com, anatoly.burakov@intel.com,
dev@dpdk.org, ferruh.yigit@amd.com, david.hunt@intel.com
Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management
Date: Tue, 17 Oct 2023 08:52:57 +0530 [thread overview]
Message-ID: <CALBAE1Oot07_d0DqmZ=Kkxm+VP6koZWHN0tE_AdK3+SX4diZTA@mail.gmail.com> (raw)
In-Reply-To: <20231016205715.970999-5-sivaprasad.tummala@amd.com>
On Tue, Oct 17, 2023 at 2:27 AM Sivaprasad Tummala
<sivaprasad.tummala@amd.com> wrote:
>
> Add eventdev support to enable power saving when no events
> are arriving. It is based on counting the number of empty
> polls and, when the number reaches a certain threshold, entering
> an architecture-defined optimized power state that will either wait
> until a TSC timestamp expires, or when events arrive.
>
> This API mandates a core-to-single-port mapping (i.e. one core polling
> multiple ports of event device is not supported). This should be ok
> as the general use case will have one CPU core using one port to
> enqueue/dequeue events from an eventdev.
>
> This design is using Eventdev PMD Dequeue callbacks.
>
> 1. MWAITX/MONITORX:
>
> When a certain threshold of empty polls is reached, the core will go
> into a power optimized sleep while waiting on an address of next RX
> descriptor to be written to.
>
> 2. Pause instruction
>
> This method uses the pause instruction to avoid busy polling.
>
> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Hi Siva,
It does not look it is aligned with previous discussion.
I spend a couple of minutes to draft semantics. Please treat as reference.
# IMO, only following public SLOW PATH eventdev API required.(Just
share the concept)
enum rte_event_pmgmt_modes {
/** Default power management scheme */
RTE_EVENT_POWER_MGMT_TYPE_DEFAULT;
/** Use power-optimized monitoring to wait for incoming traffic */
RTE_EVENT_POWER_MGMT_TYPE_F_CPU_MONITOR = RTE_BIT(0),
/** Use power-optimized sleep to avoid busy polling */
RTE_EVENT_POWER_MGMT_TYPE_F_CPU_PAUSE = RTE_BIT(1),
/** HW based power management scheme found in ARM64 machines,
where core goes to sleep state till event available on dequeue */
RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE = RTE_BIT(2),
};
int rte_event_port_pmgmt_type_supported_get(uint8_t dev_id, enum
rte_event_pmgmt_modes *mode_flags)
/** Device must be in stop state */
int rte_event_port_pmgmt_enable(uint8_t dev_id, uint8_t port_id, enum
rte_event_pmgmt_modes mode);
int rte_event_port_pmgmt_disable(uint8_t dev_id, uint8_t port_id);
# It should be self-contained, No need to add to rte_power as it is
CPU only power mgmt.(See RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE
above)
# Add: lib/eventdev/eventdev_pmd_pmgmt.c or so and have CPU based on
power management helper functions
so that all SW PMD can be reused.
example:
eventdev_pmd_pmgmt_handle_monitor(uint8_t dev_id, uint8_t port_id,
struct rte_event ev[], uint16_t nb_events);
eventdev_pmd_pmgmt_handle_pause(uint8_t dev_id, uint8_t port_id,
struct rte_event ev[], uint16_t nb_events);
# In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based
power management is applicable,and it is selected.
ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst +
eventdev_pmd_pmgmt_handle_.. (based on power management mode selected)
next prev parent reply other threads:[~2023-10-17 3:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 9:54 [RFC PATCH 1/5] eventdev: add power monitoring API on event port Sivaprasad Tummala
2023-04-19 9:54 ` [RFC PATCH 2/5] event/sw: support power monitor Sivaprasad Tummala
2023-04-19 9:54 ` [RFC PATCH 3/5] eventdev: support optional dequeue callbacks Sivaprasad Tummala
2023-04-24 16:06 ` Ferruh Yigit
2023-05-17 14:22 ` Burakov, Anatoly
2023-04-19 9:54 ` [RFC PATCH 4/5] power: add eventdev support for power management Sivaprasad Tummala
2023-05-17 14:43 ` Burakov, Anatoly
2023-05-24 12:34 ` Tummala, Sivaprasad
2023-04-19 9:54 ` [RFC PATCH 5/5] examples/eventdev_p: add eventdev " Sivaprasad Tummala
2023-04-19 10:15 ` [RFC PATCH 1/5] eventdev: add power monitoring API on event port Jerin Jacob
2023-04-24 16:06 ` Ferruh Yigit
2023-04-25 4:09 ` Jerin Jacob
2023-05-02 11:19 ` Ferruh Yigit
2023-05-03 7:58 ` Jerin Jacob
2023-05-03 8:13 ` Ferruh Yigit
2023-05-03 8:26 ` Jerin Jacob
2023-05-03 15:11 ` Tummala, Sivaprasad
2023-04-25 6:19 ` Mattias Rönnblom
2023-05-02 10:43 ` Ferruh Yigit
2023-05-17 14:48 ` Burakov, Anatoly
2023-10-16 20:57 ` [PATCH v1 1/6] " Sivaprasad Tummala
2023-10-16 20:57 ` [PATCH v1 2/6] event/sw: support power monitor Sivaprasad Tummala
2023-10-16 23:41 ` Tyler Retzlaff
2023-10-16 20:57 ` [PATCH v1 3/6] eventdev: support optional dequeue callbacks Sivaprasad Tummala
2023-10-16 23:47 ` Tyler Retzlaff
2023-10-16 20:57 ` [PATCH v1 4/6] event/sw: " Sivaprasad Tummala
2023-10-16 20:57 ` [PATCH v1 5/6] power: add eventdev support for power management Sivaprasad Tummala
2023-10-16 23:51 ` Tyler Retzlaff
2023-10-17 3:03 ` Tummala, Sivaprasad
2023-10-17 3:22 ` Jerin Jacob [this message]
2023-10-18 7:08 ` Tummala, Sivaprasad
2023-10-18 7:13 ` Jerin Jacob
2023-10-16 20:57 ` [PATCH v1 6/6] examples/eventdev_p: add eventdev " Sivaprasad Tummala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1Oot07_d0DqmZ=Kkxm+VP6koZWHN0tE_AdK3+SX4diZTA@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=anatoly.burakov@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=harry.van.haaren@intel.com \
--cc=sivaprasad.tummala@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).