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:   Tue, 1 Dec 2020 16:52:13 -0800
From:   Edwin Peer <edwin.peer@...adcom.com>
To:     Danielle Ratson <danieller@...dia.com>
Cc:     Michal Kubecek <mkubecek@...e.cz>, 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 Wed, Nov 25, 2020 at 10:35:35AM +0000, Danielle Ratson wrote:

> > > In ethtool, for speed 100G and 4 lanes for example, there are few link modes that fits:
> > > ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT
> > > ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT
> > > ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT
> > > ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT
> > >

> The suggestions I have are:
> 1. Add a bit that for unknown media for each link (something like
> ETHTOOL_LINK_MODE_100000unknown_Full_BIT). I am not sure it is even
> possible or makes sense.

The number of lanes would still need to be specified. You would need at least:

ETHTOOL_LINK_MODE_100000xR2_FULL

and

ETHTOOL_LINK_MODE_100000xR4_FULL

to distinguish between PAM4 and NRZ at 100G respectively. And, there's still
the cost of maintaining a different enum to ethtool_link_mode_bit_indices.

> 2. Pass the link mode as bitmap.

The user only wants to specify link speed and encoding, not media. The
bitmap has the same problem to solve. Or, should user space set the bits
for all possible media types that satisfy the desired speed and encoding?
Eeek. Alternatively, the driver would need to accept any bit that implies the
desired speed and encoding, ignoring what media the bit specifies (to do
so would require maintaining a map of equivalences, yuck).

> Do you see any other option?

As stated in another sub-thread, I think the encoding can be implied by the
speed if the number of lanes is a property of the port configuration. In which
case the existing ethtool interface is sufficient.

Regards,
Edwin Peer

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)

Powered by blists - more mailing lists