netdev - Re: [PATCH ethtool] ethtool: support combinations of FEC modes

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:   Fri, 28 Sep 2018 18:45:53 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Ariel Almog <arielalmogworkemails@...il.com>,
        linville@...driver.com, Linux Netdev List <netdev@...r.kernel.org>,
        ganeshgr@...lsio.com, jakub.kicinski@...ronome.com,
        dustin@...ulusnetworks.com, dirk.vandermerwe@...ronome.com,
        shayag@...lanox.com, ariela@...lanox.com
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes

> I see where you're coming from, but if people start needing to manually
>  configure FEC on their consumer devices, possibly we have bigger
>  problems.

Yes, i agree with that. For the consumer market, SFPs needs to grow up
and start doing full and reliable auto-neg, just like copper Ethernet.

However, there is often an intermediate step after the really niche
market like TOR routers. Industrial applications start using this
stuff. There are a lot of planes flying today using SFPs for the
inflight entertainment systems. Fibre weights less than copper. It is
a somewhat specialist market, so you probably can still force them to
read the hardware manual, but i think they would prefer not to. And
i'm sure they are not the only industrial users. There are likely to
be more industrial users than TOR users.

In general, it is hard to know which APIs are going to remain Unix
Wizard level, and which are going to be used by mere mortals. So
ideally, we want consistency everywhere.

> I think the alternative, of finding a set of semantics that fits
>  everyone's hardware and covers everyone's requirements, is likely to
>  be difficult (and probably require changing the ethtool API).

Now is a good time to change the API, since we are moving to a netlink
socket. Which is why these questions were asked in the first place...

	Andrew