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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 26, 2025 at 06:59:45AM +0100, Oleksij Rempel wrote:
> On Tue, Feb 25, 2025 at 05:47:52PM -0800, Jakub Kicinski wrote:
> > On Tue, 25 Feb 2025 10:25:58 +0100 Kory Maincent wrote:
> > > On Mon, 24 Feb 2025 13:45:22 -0800
> > > Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
> > > 
> > > > > No they can't for now. Even different PSE power domains within the same PSE
> > > > > controller. I will make it explicit.    
> > > > 
> > > > Sounds like the property is placed at the wrong level of the hierarchy,
> > > > then.  
> > > 
> > > When a PSE controller appears to be able to support mixed budget strategy and
> > > could switch between them it will be better to have it set at the PSE power
> > > domain level. As the budget is per PSE power domain, its strategy should also
> > > be per PSE power domain.
> > > For now, it is simply not configurable and can't be mixed. It is hard-coded by
> > > the PSE driver.
> > 
> > Yes, but uAPI is forever. We will have to live with those domain
> > attributes duplicated on each port. Presumably these port attributes
> > will never support a SET operation, since the set should be towards 
> > the domain? The uAPI does not inspire confidence. If we need more
> > drivers to define a common API maybe a local sysfs API in the driver
> > will do?
> 
> I tend to disagree here. The evaluation/allocation methods should be
> per port.  
> 
> At this step, we support only "hardware"(firmware)-based methods:  
> 1. Static – Plain hardware classification-based power allocation per
> port.  
> 2. Dynamic – Hardware classification with constant measurement for
> optimization.  
> 
> For some devices, the dynamic method may not work reliably enough,
> so we will need to switch to a fixed allocation method, which is
> currently not implemented but will be set via user space. This
> should be configurable per port.  
> 
> At some point, we will need to introduce LLDP-based allocation from
> user space. This will be managed by a daemon.
> 
> For testing, here’s an example of how LLDP-based power negotiation can
> be analyzed:
> https://telecomtest.com.au/wp-content/uploads/2016/12/PDA-LLDP-Powered-Device-LLDP-Analyzer.pdf

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

-- 
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 |




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux