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  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:   Tue, 20 Oct 2020 07:39:13 +0000
From:   Danielle Ratson <danieller@...dia.com>
To:     Michal Kubecek <mkubecek@...e.cz>, Jiri Pirko <jiri@...nulli.us>
CC:     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



> -----Original Message-----
> From: Michal Kubecek <mkubecek@...e.cz>
> Sent: Monday, October 19, 2020 4:25 PM
> To: Jiri Pirko <jiri@...nulli.us>
> Cc: Danielle Ratson <danieller@...dia.com>; Andrew Lunn
> <andrew@...n.ch>; Jakub Kicinski <kuba@...nel.org>; Ido Schimmel
> <idosch@...sch.org>; netdev@...r.kernel.org; davem@...emloft.net; Jiri
> Pirko <jiri@...dia.com>; f.fainelli@...il.com; mlxsw <mlxsw@...dia.com>;
> Ido Schimmel <idosch@...dia.com>; johannes@...solutions.net
> Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI
> with lanes
> 
> On Mon, Oct 19, 2020 at 02:26:43PM +0200, Jiri Pirko wrote:
> > Mon, Oct 19, 2020 at 01:04:22PM CEST, mkubecek@...e.cz wrote:
> > >
> > >It would be quite easy to extend the ethtool command line parser to
> > >allow also
> > >
> > >  ethtool -s <dev> advertise <mode> ...
> > >
> > >in addition to already supported
> > >
> > >  ethtool -s <dev> advertise <mask>
> > >  ethtool -s <dev> advertise <mask>/<mask>  ethtool -s { <mode> { on
> > > | off } } ...
> 
> This should have been
> 
>   ethtool -s <dev> advertise { <mode> { on | off } } ...
> 
> > >Parser converting simple list of values into a maskless bitset is
> > >already there so it would be only matter of checking if there are at
> > >least two arguments and second is "on" or "off" and using
> > >corresponding parser. I think it would be useful independently of this
> series.
> >
> > Understood. So basically you will pass some selectors on cmdline and
> > the uapi would stay intact.
> > How do you imagine the specific lane number selection should look like
> > on the cmdline?
> 
> 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? 

Thanks.

Powered by blists - more mailing lists