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:   Thu, 29 Jun 2017 18:49:58 +0300
From:   Gal Pressman <galp@...lanox.com>
To:     Dustin Byford <dustin@...ulusnetworks.com>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>, davem@...emloft.net,
        linville@...driver.com, netdev@...r.kernel.org,
        vidya.chowdary@...il.com, olson@...ulusnetworks.com,
        leedom@...lsio.com, manojmalviya@...lsio.com, santosh@...lsio.com,
        yuval.mintz@...gic.com, odedw@...lanox.com, ariela@...lanox.com,
        jeffrey.t.kirsher@...el.com
Subject: Re: [PATCH net-next 1/3] net: ethtool: add support for forward error
 correction modes

> Hi Gal,
>
> ...
>> What is the difference between the information in ethtool DEVNAME and ethtool --show-fec DEVNAME?
> I think there are two questions there.  First, how does the FEC-related
> information from glinksettings differ from what's retrieved via
> gfecparam.  Second, how is that expressed through the ethtool UI.
>
> Regarding the uapi (as we imagined it), glinksettings returns FEC
> information through three fields:
>
> @supported: the complete set of FEC modes the hardware supports, at any
> speed, medium, or autoneg combination.
>
> @advertising: the set of modes advertised to the link partner through
> the relevant autoneg mechanism.
>
> @lp_advertising: the set of modes the link partner is advertising
> through autoneg.
>
>
> gfecparam is used to fetch a couple more important facts about the FEC
> configuration:
>
> 1) What FEC mode is currently active, either as a result of the autoneg
> process, or a previous call to sfecparam.  This is returned in
> sfecparam->active_fec
>
> 2) If autoneg is off, what is the currently configured FEC mode.  This
> is a bitmask returned in gfecparam->fec.  I imagine it's typically a
> single mode, but a mask makes it easier to implement a "don't care" policy,
> or otherwise allow the NIC/driver to pick between a set of modes.
>
>
> Regarding the UI.  ethtool DEVNAME gets most of its info from
> glinksettings and it's easy to represent the FEC parameters affected by
> autoneg there.  ethtool --show-fec simply reports the output of
> gfecparam.  I agree the difference is subtle, perhaps it makes sense to
> combine all the FEC information into ethtool DEVNAME?
IMHO it does, but the current UI is fine too.
Thanks for the explanation.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ