netdev - Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Oct 2020 09:08:20 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Danielle Ratson <danieller@...dia.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <kuba@...nel.org>,
        Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        mlxsw <mlxsw@...dia.com>, Ido Schimmel <idosch@...dia.com>,
        "johannes@...solutions.net" <johannes@...solutions.net>
Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI
 with lanes

On Tue, Oct 20, 2020 at 07:39:13AM +0000, Danielle Ratson wrote:
> > -----Original Message-----
> > From: Michal Kubecek <mkubecek@...e.cz>
> > Sent: Monday, October 19, 2020 4:25 PM
> > 
> > As I said, I meant the extension suggested in my mail as independent of what
> > this series is about. For lanes count selector, I find proposed
> > 
> >   ethtool -s <dev> ... lanes <lanes_num> ...
> > 
> > the most natural.
> > 
> > From purely syntactic/semantic point of view, there are three types of
> > requests:
> > 
> >   (1) enable specific set of modes, disable the rest
> >   (2) enable/disable specific modes, leave the rest as they are
> >   (3) enable modes matching a condition (and disable the rest)
> > 
> > What I proposed was to allow the use symbolic names instead of masks
> > (which are getting more and more awful with each new mode) also for (1),
> > like they can already be used for (2).
> > 
> > The lanes selector is an extension of (3) which I would prefer not to mix with
> > (1) or (2) within one command line, i.e. either "advertise" or "speed / duplex
> > / lanes".
> > 
> > IIUC Jakub's and Andrew's comments were not so much about the syntax
> > and semantic (which is quite clear) but rather about the question if the
> > requests like "advertise exactly the modes with (100Gb/s speed and) two
> > lanes" would really address a real life need and wouldn't be more often used
> > as shortcuts for "advertise 100000baseKR2/Full". (On the other hand, I
> > suspect existing speed and duplex selectors are often used the same way.)
> > 
> > Michal
> 
> So, do you want to change the current approach somehow or we are good
> to go with this one, keeping in mind the future extension you have
> suggested? 

As far as I'm concerned, it makes sense as it is. The only thing I'm not
happy about is ETHTOOL_A_LINKMODES_LANES being a "write only" attribute
(unlike _SPEED and _DUPLEX) but being able to query this information
would require extensive changes far beyond the scope of this series.

Michal