Re: [PATCH net-next 06/12] net: ethtool: Add PSE new port priority support feature

[Oleksij Rempel]

On Mon, Oct 07, 2024 at 11:30:26AM +0200, Kory Maincent wrote:
> On Sat, 5 Oct 2024 08:26:36 +0200
> Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:
> 
> > >  When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is
> > > used @@ -1871,6 +1883,10 @@ various existing products that document power
> > > consumption in watts rather than classes. If power limit configuration
> > > based on classes is needed, the conversion can be done in user space, for
> > > example by ethtool. 
> > > +When set, the optional ``ETHTOOL_A_C33_PSE_PRIO`` attributes is used to
> > > +control the C33 PSE priority. Allowed priority value are between zero
> > > +and the value of ``ETHTOOL_A_C33_PSE_PRIO_MAX`` attribute.  
> >  
> > We need to introduce a new attribute to effectively manage PSE priorities.
> > With the addition of the `ETHTOOL_A_C33_PSE_PRIO` attribute for setting
> > priorities, it's important to know which PSE controller or domain each port
> > belongs to.
> > 
> > Initially, we might consider using a PSE controller index, such as
> > `ETHTOOL_A_PSE_CONTROLLER_ID`, to identify the specific PSE controller
> > associated with each port.
> > 
> > However, using just the PSE controller index is too limiting. Here's why:
> > 
> > - Typical PSE controllers handle priorities only within themselves. They
> > usually can't manage prioritization across different controllers unless they
> > are part of the same power domain. In systems where multiple PSE controllers
> > cooperate—either directly or through software mechanisms like the regulator
> > framework—controllers might share power domains or manage priorities together.
> > This means priorities are not confined to individual controllers but are
> > relevant within shared power domains.
> > 
> > - As systems become more complex, with controllers that can work together,
> > relying solely on a controller index won't accommodate these cooperative
> > scenarios.
> > 
> > To address these issues, we should use a power domain identifier instead. I
> > suggest introducing a new attribute called `ETHTOOL_A_PSE_POWER_DOMAIN_ID`.
> > 
> > - It specifies the power domain to which each port belongs, ensuring that
> > priorities are managed correctly within that domain.
> > 
> > - It accommodates systems where controllers cooperate and share power
> > resources, allowing for proper coordination of priorities across controllers
> > within the same power domain.
> > 
> > - It provides flexibility for future developments where controllers might work
> > together in new ways, preventing limitations that would arise from using a
> > strict controller index.
> > 
> > However, to provide comprehensive information, it would be beneficial to use
> > both attributes:
> > 
> > - `ETHTOOL_A_PSE_CONTROLLER_ID` to identify the specific PSE controller
> > associated with each port.
> > 
> > - `ETHTOOL_A_PSE_POWER_DOMAIN_ID` to specify the power domain to which each
> > port belongs.
> 
> Currently the priority is managed by the PSE controller so the port is the only
> information needed. The user interface is ethtool, and I don't see why he would
> need such things like controller id or power domain id. Instead, it could be
> managed by the PSE core depending on the power domains described in the
> devicetree. The user only wants to know if he can allow a specific power budget
> on a Ethernet port and configure port priority in case of over power-budget
> event.

Budget is important but different topic. If user do not know how much
the budget is, there is nothing usable user can configure. Imagine you
do not know how much money can spend and the only way to find it out is
by baying things.

But, budget is the secondary topic withing context of this patch set.
The primer topic here is the prioritization, so the information user
need to know it the context: do A has higher prio in relation to B? Do A
and B actually in the same domain?


> I don't have hardware with several PSE controllers. Is there already such
> hardware existing in the market?

Please correct me if i'm wrong, but in case of pd692x0 based devices,
every manager (for example PD69208M) is own power domain. There are
following limiting factors:
                          PI 1
                   L4    /
		 PD69208M - PI 2
              L3 //      \
 L1      L2     //        PI 3
PSU ============'
                \\        PI 4
                 \\      /
		 PD69208M - PI 5
                         \
			  PI 6

L1 - limits defined by Power Supply Unit
L2 - Limits defined by main supply rail ob PCB
L3 - Limits defined by rail attached to one specific manager
L4 - Limits defined by manager. In case of PD69208M it is Max 0.627A
(for all or per port?)

Assuming PSU provides enough budget to covert Max supported current for
every manager, then the limiting factor is actual manager. It means,
setting prio for PI 4 in relation to PI 1 makes no real sense, because
it is in different power domain.

User will not understand why devices fail to provide enough power by
attaching two device to one domain and not failing by attaching to
different domains. Except we provide this information to the user space.

Regards,
Oleksij
-- 
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 |