netdev - Re: [PATCH net-next v5 06/12] net: pse-pd: Add support for budget evaluation strategies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250227192640.20df155d@kmaincent-XPS-13-7390>
Date: Thu, 27 Feb 2025 19:26:40 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 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>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, 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>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v5 06/12] net: pse-pd: Add support for budget
 evaluation strategies

On Thu, 27 Feb 2025 17:40:42 +0100
Oleksij Rempel <o.rempel@...gutronix.de> wrote:

> On Thu, Feb 27, 2025 at 03:57:27PM +0100, Kory Maincent wrote:
> > On Thu, 27 Feb 2025 08:40:25 +0100
> > Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >   
> > > On Wed, Feb 26, 2025 at 06:42:57PM -0800, Jakub Kicinski wrote:  
>  [...]  
>  [...]  
>  [...]  
> > > 
> > > Ok, I see. @Köry, can you please provide regulator_summary with some
> > > inlined comments to regulators related to the PSE components and PSE
> > > related outputs of ethtool (or what ever tool you are using).
> > > 
> > > I wont to use this examples to answer.  
> > 
> > On my side, I am not close to using sysfs. As we do all configurations
> > through ethtool I have assumed we should continue with ethtool.  
> 
> Yes, I agree. But it won't be possible to do it for all components.
> 
> > I think we should set the port priority through ethtool.  
> 
> ack
> 
> > but indeed the PSE  power domain method get and set could be moved to
> > sysfs as it is not something  relative to the port but to a group of
> > ports.  
> 
> I would prefer to have it in the for of devlink or use regulator netlink
> interface. But, we do not need to do this discussion right now.

If we want to report the method we should discuss it now. We shouldn't add
BUDGET_EVAL_STRAT uAPI to ethtool if we use another way to get and set the
method later.

We could also not report the method for now and assume the user knows it for
the two controllers currently supported.
 
> > Ethtool should still report the  PSE power domain ID of a port to know
> > which domain the port is.  
> 
> Exactly.
> 
> @Jakub, at current implementation stage, user need to know the domain
> id, because ports (and priorities) are grouped by the top level
> regulators (pse-regX in the regulator_summary), they are our top-level
> bottlenecks.
> 
> HP and Cisco switch either use different PSE controllers, or just didn't
> exposed this nuance to the user. Let's assume, they have only one
> global power domain.
> 
> So, in current patch set I would expect (not force :) ) implementation for
> following fields:
> - per port:
>   - priority (valid within the power domain)
>   - power reservation/allocation methods. First of all, because all
>     already supported controllers have different implemented/default
>     methods: microchip - dynamic, TI - static, regulator-pse - fixed (no
>     classification is supported).
>     At same time, in the future, we will need be able switch between
>     (static or dynamic) and fixed for LLPD or manual configuration.
>     Yes, at this point all ports show the same information and it seems
>     to be duplicated.
>   - power domain ID.
> 
> @Jakub, did I answered you question, or missed the point? :)
>
> > @Oleksij here it is:  
> 
> Thank you!
> 
> I do not expect it to be the primer user interface, but it can provide
> additional diagnostic information. I wonted to see how it is aligns
> with current ethtool UAPI implementation and if it possible to combine
> it for diagnostics.
> 
> > # cat /sys/kernel/debug/regulator/regulator_summary
> >  regulator                      use open bypass  opmode voltage current
> > min     max
> > ---------------------------------------------------------------------------------------
> > regulator-dummy                  5    4      0 unknown     0mV     0mA
> > 0mV     0mV d00e0000.sata-target          1
> > 0mA     0mV     0mV d00e0000.sata-phy             1
> >         0mA     0mV     0mV d00e0000.sata-ahci            1
> >                 0mA     0mV     0mV spi0.0-vcc                    1
> >                         0mA     0mV     0mV pse-reg
> >  1    4      0 unknown     0mV     0mA     0mV     0mV   
> 
> pse-regX should be attached to the main supply regulator for better full
> picture. And use different name to be better identified as PSE power domains
> with ID?

This is the regulator name set in the devicetree description so we can set
whatever we want.

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