All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch,
	mkubecek@suse.cz, pali@kernel.org, jacob.e.keller@intel.com,
	jiri@nvidia.com, vadimp@nvidia.com, mlxsw@nvidia.com,
	Ido Schimmel <idosch@nvidia.com>
Subject: Re: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control transceiver modules' power mode
Date: Thu, 19 Aug 2021 10:47:03 +0300	[thread overview]
Message-ID: <YR4Md0MJeAPOuuQw@shredder> (raw)
In-Reply-To: <20210818153241.7438e611@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, Aug 18, 2021 at 03:32:41PM -0700, Jakub Kicinski wrote:
> On Wed, 18 Aug 2021 18:51:57 +0300 Ido Schimmel wrote:
> > +MODULE_SET
> > +==========
> > +
> > +Sets transceiver module parameters.
> > +
> > +Request contents:
> > +
> > +  ======================================  ======  ==========================
> > +  ``ETHTOOL_A_MODULE_HEADER``             nested  request header
> > +  ``ETHTOOL_A_MODULE_POWER_MODE_POLICY``  u8      power mode policy
> > +  ======================================  ======  ==========================
> > +
> > +When set, the optional ``ETHTOOL_A_MODULE_POWER_MODE_POLICY`` attribute is used
> > +to set the transceiver module power policy enforced by the host. Possible
> > +values are:
> > +
> > +.. kernel-doc:: include/uapi/linux/ethtool.h
> > +    :identifiers: ethtool_module_power_mode_policy
> > +
> > +For SFF-8636 modules, low power mode is forced by the host according to table
> > +6-10 in revision 2.10a of the specification.
> > +
> > +For CMIS modules, low power mode is forced by the host according to table 6-12
> > +in revision 5.0 of the specification.
> > +
> > +To avoid changes to the operational state of the device, power mode policy can
> > +only be set when the device is administratively down.
> 
> Would you mind explaining why?

Yes, it is more restrictive than it should be. The check can be relaxed
to only disallow transition to low power mode when the device is
administratively up.

> 
> > +/**
> > + * enum ethtool_module_power_mode_policy - plug-in module power mode policy
> > + * @ETHTOOL_MODULE_POWER_MODE_POLICY_LOW: Module is always in low power mode.
> 
> Did you have a use case for this one or is it for completeness? Seems
> like user can just bring the port down if they want no carrier? My
> understanding was you primarily wanted the latter two, and those can
> be freely changed when netdev is running, right?

In all the implementations I could find (3), the user interface is
high/low (on/off). The proposed interface is more flexible as it
contains both the 'high' / 'low' policies in addition to the more user
friendly 'high-on-up' ('auto') policy.

Given that keeping the 'low' policy does not complicate the
implementation / maintenance and that it provides users with a similar
interface to what they are used to from other implementations, I would
like to keep it in addition to the other two policies.

> 
> > + * @ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH: Module is always in high power mode.
> > + * @ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH_ON_UP: Module is transitioned by the
> > + *	host to high power mode when the first port using it is put
> > + *	administratively up and to low power mode when the last port using it
> > + *	is put administratively down.
> 
> s/HIGH_ON_UP/AUTO/ ?

OK

> high on up == low on down, right, seems arbitrary to pick one over the
> other

  parent reply	other threads:[~2021-08-19  7:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 15:51 [RFC PATCH net-next v2 0/6] ethtool: Add ability to control transceiver modules' power mode Ido Schimmel
2021-08-18 15:51 ` [RFC PATCH net-next v2 1/6] " Ido Schimmel
2021-08-18 22:32   ` Jakub Kicinski
2021-08-18 22:55     ` Andrew Lunn
2021-08-19  7:50       ` Ido Schimmel
2021-08-19 13:13         ` Andrew Lunn
2021-08-19 14:34           ` Ido Schimmel
2021-08-19 14:42             ` Jakub Kicinski
2021-08-19 22:38               ` Keller, Jacob E
2021-08-19  7:47     ` Ido Schimmel [this message]
2021-08-19 14:38       ` Jakub Kicinski
2021-08-18 15:51 ` [RFC PATCH net-next v2 2/6] mlxsw: reg: Add Port Module Memory Map Properties register Ido Schimmel
2021-08-18 15:51 ` [RFC PATCH net-next v2 3/6] mlxsw: reg: Add Management Cable IO and Notifications register Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 4/6] mlxsw: Add ability to control transceiver modules' power mode Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 5/6] ethtool: Add transceiver module extended states Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 6/6] mlxsw: Add support for " Ido Schimmel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YR4Md0MJeAPOuuQw@shredder \
    --to=idosch@idosch.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=idosch@nvidia.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=vadimp@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.