netdev - RE: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control transceiver modules' power mode

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: <CO1PR11MB5089D735601C260783142DD5D6C09@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Thu, 19 Aug 2021 22:38:41 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, Ido Schimmel <idosch@...sch.org>
CC:     Andrew Lunn <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "pali@...nel.org" <pali@...nel.org>,
        "jiri@...dia.com" <jiri@...dia.com>,
        "vadimp@...dia.com" <vadimp@...dia.com>,
        "mlxsw@...dia.com" <mlxsw@...dia.com>,
        Ido Schimmel <idosch@...dia.com>
Subject: RE: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control
 transceiver modules' power mode



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, August 19, 2021 7:43 AM
> To: Ido Schimmel <idosch@...sch.org>
> Cc: Andrew Lunn <andrew@...n.ch>; netdev@...r.kernel.org;
> davem@...emloft.net; mkubecek@...e.cz; pali@...nel.org; Keller, Jacob E
> <jacob.e.keller@...el.com>; jiri@...dia.com; vadimp@...dia.com;
> mlxsw@...dia.com; Ido Schimmel <idosch@...dia.com>
> Subject: Re: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control
> transceiver modules' power mode
> 
> On Thu, 19 Aug 2021 17:34:46 +0300 Ido Schimmel wrote:
> > > That is kind of my question. Do you want the default driver defined,
> > > and varying between implementations, or do we want a clearly defined
> > > default?
> > >
> > > The stack has a mixture of both. An interface is admin down by
> > > default, but it is anybody guess how pause will be configured?
> > >
> > > By making it driver undefined, you cannot assume anything, and you
> > > require user space to always configure it.
> > >
> > > I don't have too strong an opinion, i'm more interested in what others
> > > say, those who have to live with this.
> >
> > I evaluated the link up times using a QSFP module [1] connected to my
> > system. There is a 36% increase in link up times when using the 'auto'
> > policy compared to the 'high' policy (default on all Mellanox systems).
> > Very noticeable and very measurable.
> >
> > Couple the above with the fact that despite shipping millions of ports
> > over the years, we are only now getting requests to control the power
> > mode of transceivers and from a small number of users.
> >
> > In addition, any user space that is interested in changing the behavior,
> > has the ability to query the default policy and override it in a
> > vendor-agnostic way.
> >
> > Therefore, I'm strictly against changing the existing behavior.
> >
> > [1] https://www.mellanox.com/related-docs/prod_cables/PB_MFS1S00-
> VxxxE_200GbE_QSFP56_AOC.pdf
> 
> Fine by me FWIW. Obviously in an ideal world we'd have uniform presets
> as part of 'what it means to be upstream Linux' but from practical
> standpoint where most features start out of tree having the requirement
> of uniformity will be an impediment preventing vendors from switching to
> upstream APIs. That's my personal opinion or should I say 'gut feeling',
> I could well be wrong.

I think it makes sense to push for uniform presets where we can. But in some cases where we already have a variety of differing behaviors this becomes difficult.

I would agree in pushing for uniform defaults in cases where we're clearly adding new functionality. However in cases like this where there exists a wide spectrum of behaviors, it makes more sense to allow individual drivers to maintain the same behavior while reporting that up with the option to configure or change it. It's not ideal if we did everything from scratch, but it's the current reality.

Thanks,
Jake