[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRQ2RBfOGQKiDOlt@lunn.ch>
Date: Wed, 11 Aug 2021 22:42:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ido Schimmel <idosch@...sch.org>
Cc: Jakub Kicinski <kuba@...nel.org>,
"Keller, Jacob E" <jacob.e.keller@...el.com>,
netdev@...r.kernel.org, davem@...emloft.net, mkubecek@...e.cz,
pali@...nel.org, vadimp@...dia.com, mlxsw@...dia.com,
Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 1/8] ethtool: Add ability to control
transceiver modules' low power mode
> For the policy we can have these values:
>
> 1. low: Always transition the module to low power mode
> 2. high: Always transition the module to high power mode
> 3. high-on-up: Transition the module to high power mode when a port
> using it is administratively up. Otherwise, low
>
> A different policy for up/down seems like an overkill for me.
O.K. The current kernel SFP driver is going to default to high-on-up,
which is what kernel driven copper PHYs also do.
> After a module was connected:
>
> $ ethtool --show-module swp11
> Module parameters for swp11:
> power-mode-policy high-on-up
> power-mode low
>
> # ip link set dev swp11 up
>
> $ ethtool --show-module swp11
> Module parameters for swp11:
> power-mode-policy high-on-up
> low-power high
>
> # ip link set dev swp11 down
You missed a show here. I expect it to be:
> $ ethtool --show-module swp11
> Module parameters for swp11:
> power-mode-policy high-on-up
> power-mode low
since it is now down.
I suppose we should consider the bigger picture. Is this feature
limited to just SFP modules, or does it make sense to any other sort
of network technology? CAN, bluetooth, 5G, IPoAC?
Andrew
Powered by blists - more mailing lists