netdev - Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters

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]

Message-ID: <20210201122939.09c18efa@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 1 Feb 2021 12:29:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edwin Peer <edwin.peer@...adcom.com>
Cc:     Danielle Ratson <danieller@...dia.com>,
        Michal Kubecek <mkubecek@...e.cz>,
        netdev <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>, Andrew Lunn <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        mlxsw <mlxsw@...dia.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead
 of speed and duplex parameters

On Mon, 1 Feb 2021 10:14:35 -0800 Edwin Peer wrote:
> On Mon, Feb 1, 2021 at 5:49 AM Danielle Ratson <danieller@...dia.com> wrote:
> > Ok, ill send another version with the symmetrical side. Ethtool
> > will try to compose a supported link_mode from the parameters from
> > user space and will choose randomly between the supported ones.
> > Sounds ok?  
> 
> I think it should be deterministic. It should be possible to select
> the appropriate mode either based on the current media type or the
> current link mode (which implies a media type). Alternatively, if the
> user space request only specifies a subset, such as speed, fall back
> to the existing behaviour and don't supply the request to the driver
> in the form of a compound link mode in those cases (perhaps indicating
> this by not setting the capability bit). The former approach has the
> potential to tidy up drivers if we decide that drivers providing the
> capability can ignore the other fields and rely solely on link mode,
> the latter is no worse than what we have today.

The media part is beginning to sound concerning. Every time we
under-specify an interface we end up with #vendors different
interpretations. And since HW is programmed by FW in most high 
speed devices we can't even review the right thing is done.

At least it's clear what setting a number of lanes means.