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@xxxxxxxxxxxxxx> wrote: > > > On Wed, Feb 26, 2025 at 06:42:57PM -0800, Jakub Kicinski wrote: > > > On Wed, 26 Feb 2025 07:06:55 +0100 Oleksij Rempel wrote: > > > > Here is one example how it is done by HP switches: > > > > https://arubanetworking.hpe.com/techdocs/AOS-CX/10.08/HTML/monitoring_6200/Content/Chp_PoE/PoE_cmds/pow-ove-eth-all-by.htm > > > > > > > > switch(config)# interface 1/1/1 <---- per interface > > > > switch(config-if)# power-over-ethernet allocate-by usage > > > > switch(config-if)# power-over-ethernet allocate-by class > > > > > > > > Cisco example: > > > > https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/power-over-ethernet/configuration/configuring-power-over-ethernet/m-configuring-power-over-ethernet.html > > > > > > > > switch(config)# interface ethernet1/1 <---- per interface > > > > switch(config-if)# power inline auto > > > > > > I don't see any mention of a domain in these docs. > > > This patchset is creating a concept of "domain" but does > > > not expose it as an object. > > > > 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. > 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? > pse-0-0020_pi0 0 1 0 unknown 53816mV 2369mA 0mV 0mV > 0-0020-pse-0-0020_pi0 0 0mA 0mV 0mV > pse-0-0020_pi2 0 1 0 unknown 53816mV 2369mA 0mV 0mV > 0-0020-pse-0-0020_pi2 0 0mA 0mV 0mV > pse-0-0020_pi7 0 1 0 unknown 53816mV 2369mA 0mV 0mV > 0-0020-pse-0-0020_pi7 0 0mA 0mV 0mV > pse-reg2 1 2 0 unknown 0mV 0mA 0mV 0mV > pse-0-0020_pi1 0 0 0 unknown 53816mV 4738mA 0mV 0mV > vcc_sd1 2 1 0 unknown 1800mV 0mA 1800mV 3300mV > d00d0000.mmc-vqmmc 1 0mA 1800mV 1950mV > > # ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-get --json > '{"header":{"dev-name":"wan"}}' > {'c33-pse-admin-state': 2, > 'c33-pse-avail-pw-limit': 127500, > 'c33-pse-pw-d-status': 2, > 'c33-pse-pw-limit-ranges': [{'max': 99900, 'min': 2000}], > 'header': {'dev-index': 4, 'dev-name': 'wan'}, > 'pse-budget-eval-strat': 2, > 'pse-prio': 0, > 'pse-prio-max': 8, > 'pse-pw-d-id': 1} > > # ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-set --json > '{"header":{"dev-name":"wan"}, "pse-prio":1}' > None > # ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-set --json > '{"header":{"dev-name":"wan"}, "c33-pse-avail-pw-limit":15000}' Best 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 |
