Message-ID: <20241105144913.3c25b476@kmaincent-XPS-13-7390>
Date: Tue, 5 Nov 2024 14:49:13 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Donald Hunter
 <donald.hunter@...il.com>, Rob Herring <robh@...nel.org>, Andrew Lunn
 <andrew+netdev@...n.ch>, Simon Horman <horms@...nel.org>, Heiner Kallweit
 <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, linux-doc@...r.kernel.org, Kyle Swenson
 <kyle.swenson@....tech>, Dent Project <dentproject@...uxfoundation.org>,
 kernel@...gutronix.de, Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH RFC net-next v2 15/18] net: pse-pd: Add support for
 getting and setting port priority

On Thu, 31 Oct 2024 18:32:39 +0100
Oleksij Rempel <o.rempel@...gutronix.de> wrote:
 
> > >  *
> > >  * Handling scenarios where power budget is exceeded:
> > >  * - Hot-plug behavior: If a new device is added that causes the total
> > > power
> > >  *   demand to exceed the PSE budget, the newly added device is
> > > de-prioritized
> > >  *   and shut down to maintain stability for previously connected devices.
> > >  *   This behavior ensures that existing connections are not disrupted,
> > > though
> > >  *   it may lead to inconsistent behavior if the device is disconnected
> > > and
> > >  *   reconnected (hot-plugged).  
> > 
> > Do we want this behavior even if the new device has an highest priority than
> > other previously connected devices?  
> 
> Huh... good question. I assume, if we go with policy in kernel, then it
> is ok to implement just some one. But, I assume, we will need this kind of
> interface soon or later: 
> 
> Warning! this is discussion, i'm in process of understanding :D
> 
> /**
>  * enum pse_disconnection_policy - Disconnection strategies for same-priority
>  *   devices when power budget is exceeded, tailored to specific priority
> modes. *
>  * Each device can have multiple disconnection policies set as an array of
>  * priorities. When the power budget is exceeded, the policies are executed
>  * in the order defined by the user. This allows for a more nuanced and 
>  * flexible approach to handling power constraints across a range of devices
>  * with similar priorities or attributes.
>  *
>  * Example Usage:
>  *   - Users can specify an ordered list of policies, such as starting with
>  *     `PSE_DISCON_STATIC_CLASS_HIGHEST_FIRST` to prioritize based on class,
>  *     followed by `PSE_DISCON_LRC` to break ties based on connection time.
>  *     This ordered execution ensures that power disconnections align closely
>  *     with the system’s operational requirements and priorities.
 
...

>  * @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.
 
>  * @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.
Do you think I should add this full enumeration in ethtool UAPI even if not all
of them are supported yet? 


> PD692x0 seems to use @PSE_DISCON_ROUND_ROBIN_IDX_HIGHEST_FIRST disconnection
> policy.

Yes.

> ETHTOOL_PSE_PORT_PRIO_DYNAMIC and ETHTOOL_PSE_PORT_PRIO_STATIC seems to be the
> source of information which should be used to trigger the disconnection
> policy. Correct?

Yes.
The management of disconnection in ETHTOOL_PSE_PORT_PRIO_DYNAMIC case is
managed directly by the PSE firmware on the PD692x0.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Powered by blists - more mailing lists