On Tue, Nov 05, 2024 at 02:49:13PM +0100, Kory Maincent wrote: > On Thu, 31 Oct 2024 18:32:39 +0100 > Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > * @PSE_DISCON_STATIC_CLASS_BUDGET_MATCH: Disconnect based on static > > allocation > > * class, targeting devices that release enough allocated power to meet the > > * current power requirement. > > * - Relevant for: ETHTOOL_PSE_PORT_PRIO_STATIC > > * - Behavior: Searches for the lowest-priority device that can release > > * sufficient allocated power to meet the current budget requirement. > > * Ensures that disconnection occurs only when enough power is freed. > > * - Rationale: This strategy is useful when the goal is to balance power > > * budget requirements while minimizing the number of disconnected > > devices. > > * It ensures that the system does not needlessly disconnect multiple > > * devices if a single disconnection is sufficient to meet the power > > needs. > > * - Use Case: Ideal for systems where precise power budget management is > > * necessary, and disconnections must be efficient in terms of freeing > > * enough power with minimal impact on the system. > > Not sure about this one. PSE_DISCON_STATIC_CLASS_HIGHEST_FIRST would be > sufficient for that case. ack > > * @PSE_DISCON_LOWEST_AVG_POWER: Disconnect device with the lowest average > > * power draw, minimizing impact on dynamic power allocation. > > * - Relevant for: ETHTOOL_PSE_PORT_PRIO_DYNAMIC > > * - Behavior: Among devices with the same priority level, the system > > * disconnects the device with the lowest average power draw. > > * - If multiple devices have the same average power draw and priority, > > * further tie-breaking mechanisms can be applied, such as disconnecting > > * the least recently connected device. > > * - Rationale: Minimizes disruption across dynamic devices, keeping as many > > * active as possible by removing the lowest-power ones. > > * - Use Case: Suitable for dynamic-priority systems where maximizing the > > * number of connected devices is more important than individual device > > * power requirements. > > > > * @PSE_DISCON_LONGEST_IDLE: Disconnect device with the longest idle time > > * (low or no recent active power usage). > > * - Relevant for: ETHTOOL_PSE_PORT_PRIO_DYNAMIC > > * - Behavior: Disconnects the device with the longest period of inactivity, > > * where "idle" is defined as low current draw or absence of recent data > > * transmission. > > * - If multiple devices have the same idle time and priority, a > > tie-breaking > > * mechanism, such as round-robin based on port index, can be used. > > * - Rationale: Optimizes resource allocation in dynamic-priority setups by > > * maintaining active devices while deprioritizing those with minimal > > * recent usage. > > * - Use Case: Ideal for dynamic environments, like sensor networks, where > > * devices may be intermittently active and can be deprioritized during > > * idle periods. > > * > > * These disconnection policies provide flexibility in handling cases where > > * multiple devices with the same priority exceed the PSE budget, aligning > > * with either static or dynamic port priority modes: > > * - `ETHTOOL_PSE_PORT_PRIO_STATIC` benefits from policies that maintain > > * stable power allocation, favoring longer-standing or higher-class > > * devices (e.g., `PSE_DISCON_LRC`, `PSE_DISCON_ROUND_ROBIN_IDX`, > > * `PSE_DISCON_STATIC_CLASS_HIGHEST_FIRST`, > > `PSE_DISCON_STATIC_CLASS_LOWEST_FIRST`, > > * `PSE_DISCON_STATIC_CLASS_BUDGET_MATCH`). > > * - `ETHTOOL_PSE_PORT_PRIO_DYNAMIC` supports policies that dynamically > > * adjust based on real-time metrics (e.g., `PSE_DISCON_LOWEST_AVG_POWER`, > > * `PSE_DISCON_LONGEST_IDLE`), ideal for setups where usage fluctuates > > * frequently. > > * - Users can define an ordered array of disconnection policies, allowing > > * the system to apply each policy in sequence, providing nuanced control > > * over how power disconnections are handled. > > */ > > I think I can add support for one or two of these modes in this patch series. > Modes relevant for dynamic port priority can't be used for now as nothing > support them. ack > Do you think I should add this full enumeration in ethtool UAPI even if not all > of them are supported yet? No, do not worry, it was just my brain dump. Care only about actually used variants. If some one will need something different, we will already know how to address it. -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
