On 4/19/2023 11:15 AM, Jerin Jacob wrote: > On Wed, Apr 19, 2023 at 3:24 PM Sivaprasad Tummala > <sivaprasad.tumm...@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.tumm...@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? For the PMDs benefit from HW event manager, just not implementing .get_monitor_addr() dev_ops will make them free from power related APIs.