From: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
Jerin Jacob <jerinjacobk@gmail.com>,
Sivaprasad Tummala <sivaprasad.tummala@amd.com>
Cc: "david.hunt@intel.com" <david.hunt@intel.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"harry.van.haaren@intel.com" <harry.van.haaren@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Pavan Nikhilesh <pbhagavatula@marvell.com>,
"McDaniel, Timothy" <timothy.mcdaniel@intel.com>,
Shijith Thotton <sthotton@marvell.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Sachin Saxena <sachin.saxena@oss.nxp.com>,
Peter Mccarthy <peter.mccarthy@intel.com>,
Liang Ma <liangma@liangbit.com>
Subject: Re: [RFC PATCH 1/5] eventdev: add power monitoring API on event port
Date: Tue, 25 Apr 2023 06:19:31 +0000 [thread overview]
Message-ID: <85c59de2-d7b1-85d2-fab6-42c145fd9470@ericsson.com> (raw)
In-Reply-To: <324d5201-da95-f926-5580-f74ca5c09799@amd.com>
On 2023-04-24 18:06, Ferruh Yigit wrote:
> On 4/19/2023 11:15 AM, Jerin Jacob wrote:
>> On Wed, Apr 19, 2023 at 3:24 PM Sivaprasad Tummala
>> <sivaprasad.tummala@amd.com> wrote:
>>>
>>> A new API to allow power monitoring condition on event port to
>>> optimize power when no events are arriving on an event port for
>>> the worker core to process in an eventdev based pipelined application.
>>>
>>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
>>> + *
>>> + * @param dev_id
>>> + * Eventdev id
>>> + * @param port_id
>>> + * Eventdev port id
>>> + * @param pmc
>>> + * The pointer to power-optimized monitoring condition structure.
>>> + *
>>> + * @return
>>> + * - 0: Success.
>>> + * -ENOTSUP: Operation not supported.
>>> + * -EINVAL: Invalid parameters.
>>> + * -ENODEV: Invalid device ID.
>>> + */
>>> +__rte_experimental
>>> +int
>>> +rte_event_port_get_monitor_addr(uint8_t dev_id, uint8_t port_id,
>>> + struct rte_power_monitor_cond *pmc);
>>
>> + eventdev driver maintainers
>>
>> I think, we don't need to expose this application due to applications
>> 1)To make applications to be transparent whether power saving is enabled or not?
>> 2)Some HW and Arch already supports power managent in driver and in HW
>> (Not using CPU architecture directly)
>>
>> If so, that will be translated to following,
>> a) Add rte_event_port_power_saving_ena_dis(uint8_t dev_id, uint8_t
>> port_id, bool ena) for controlling power saving in slowpath.
>> b) Create reusable PMD private function based on the CPU architecture
>> power saving primitive to cover the PMD don't have native power saving
>> support.
>> c)Update rte_event_dequeue_burst() burst of PMD callback to use (b).
>>
>>
>
> Hi Jerin,
>
> ethdev approach seems applied here.
>
> In ethdev, 'rte_event_port_get_monitor_addr()' equivalent is
> 'rte_eth_get_monitor_addr()'.
>
> Although 'rte_eth_get_monitor_addr()' is public API, it is currently
> only called from Rx/Tx callback functions implemented in the power library.
> But I assume intention to make it public is to enable users to implement
> their own callback functions that has custom algorithm for the power
> management.
>
> And probably same is true for the 'rte_event_port_get_monitor_addr()'.
>
>
> Also instead of implementing power features for withing PMDs, isn't it
> better to have a common eventdev layer for it?
>
To allow that question to be answered, I think you need to be more
specific what are "power features".
From what it seems to me, the get_monitor_addr() family of functions
address the pretty narrow case of allowing umwait (or the non-x86
equivalent) to be used to wait for new events. It leaves all the heavy
lifting to the app, which needs to figure out how loaded each CPU core
is, what backlog of work there is, how to shuffle work around to get the
most out of the power, how to translate wall-clock latency requirements
into the equation, what CPU (and/or accelerator/NIC-level) power
features to employ (e.g., DVFS, sleep states, umwait), etc.
In the context of Eventdev, optimizing for power may include packing
more flows into the same port, in low-load situations. Keeping a few
cores relatively busy, and the rest in some deep sleep state may well be
the best solution for certain (most?) systems. For such a feature to
work, the event device must be in the loop, but the mechanics could (and
should) be generic. Eventdev could also control DVFS.
A reasonably generic power management mechanism could go into Eventdev a
combination of the event device drivers, and some generic functions).
(Various policies would still need to come from the app.)
I think keeping this kind of functionality in Eventdev works well
provided the only source of work is Eventdev events (i.e., most or all
fast path lcores are "pure" event-based lcores). No non-eventdev timer
wheels, no non-eventdev lookaside accelerator or I/O device access, no
control plane rings to poll, etc.
If such a model is too limiting, another option is to put the central
power management function in the service framework (with a lot of help
from Eventdev, RTE timer, and other sources of work as well).
> For the PMDs benefit from HW event manager, just not implementing
> .get_monitor_addr() dev_ops will make them free from power related APIs.
>
>
>
next prev parent reply other threads:[~2023-04-25 6:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 9:54 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 [this message]
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
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=85c59de2-d7b1-85d2-fab6-42c145fd9470@ericsson.com \
--to=mattias.ronnblom@ericsson.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=liangma@liangbit.com \
--cc=pbhagavatula@marvell.com \
--cc=peter.mccarthy@intel.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=sivaprasad.tummala@amd.com \
--cc=sthotton@marvell.com \
--cc=timothy.mcdaniel@intel.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).