Message-ID: <20241007113026.39c4a8c2@kmaincent-XPS-13-7390>
Date: Mon, 7 Oct 2024 11:30:26 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "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>, 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
Subject: Re: [PATCH net-next 06/12] net: ethtool: Add PSE new port priority
 support feature

On Sat, 5 Oct 2024 08:26:36 +0200
Oleksij Rempel <o.rempel@...gutronix.de> 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.

I don't have hardware with several PSE controllers. Is there already such
hardware existing in the market?
This seems like an interesting idea but I think it would belong in another patch
series.
Still, it is good to talk about it for future development idea.

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

Powered by blists - more mailing lists