From: "Tummala, Sivaprasad" <Sivaprasad.Tummala@amd.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "harry.van.haaren@intel.com" <harry.van.haaren@intel.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Yigit, Ferruh" <Ferruh.Yigit@amd.com>,
"david.hunt@intel.com" <david.hunt@intel.com>
Subject: RE: [PATCH v1 5/6] power: add eventdev support for power management
Date: Wed, 18 Oct 2023 07:08:42 +0000 [thread overview]
Message-ID: <DM3PR12MB9286BAD1C77BEEE73ECCFD9386D5A@DM3PR12MB9286.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1Oot07_d0DqmZ=Kkxm+VP6koZWHN0tE_AdK3+SX4diZTA@mail.gmail.com>
[AMD Official Use Only - General]
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 17, 2023 8:53 AM
> To: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
> Cc: harry.van.haaren@intel.com; anatoly.burakov@intel.com; dev@dpdk.org; Yigit,
> Ferruh <Ferruh.Yigit@amd.com>; david.hunt@intel.com
> Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> 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)
Thanks for the clarification. Will incorporate the changes in next version of the patch (to support power management on event port).
With the time constraints, I will defer the power management support on event port to next release. However to avoid ABI breakage,
I will split the Patchset and push the patches to support callbacks in this release, so we don't have to wait for next stable release to
get these changes integrated.
Please let me know your thoughts.
Thanks & Regards,
Sivaprasad
next prev parent reply other threads:[~2023-10-18 7:08 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
2023-10-18 7:08 ` Tummala, Sivaprasad [this message]
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=DM3PR12MB9286BAD1C77BEEE73ECCFD9386D5A@DM3PR12MB9286.namprd12.prod.outlook.com \
--to=sivaprasad.tummala@amd.com \
--cc=Ferruh.Yigit@amd.com \
--cc=anatoly.burakov@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=jerinjacobk@gmail.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).