netdev - RE: [PATCH net-next 0/2] ice: support FEC automatic disable

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: <CO1PR11MB5089F9D77077B9EF91FA77D8D67B9@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Thu, 1 Sep 2022 17:59:53 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Gal Pressman <gal@...dia.com>, Jakub Kicinski <kuba@...nel.org>
CC:     Saeed Mahameed <saeedm@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Simon Horman <horms@...ge.net.au>,
        Andy Gospodarek <andy@...yhouse.net>
Subject: RE: [PATCH net-next 0/2] ice: support FEC automatic disable

> -----Original Message-----
> From: Gal Pressman <gal@...dia.com>
> Sent: Thursday, September 01, 2022 4:52 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; Jakub Kicinski <kuba@...nel.org>
> Cc: Saeed Mahameed <saeedm@...dia.com>; netdev@...r.kernel.org; Simon
> Horman <horms@...ge.net.au>; Andy Gospodarek <andy@...yhouse.net>
> Subject: Re: [PATCH net-next 0/2] ice: support FEC automatic disable
> 
> On 31/08/2022 23:15, Jacob Keller wrote:
> > On 8/31/2022 4:01 AM, Gal Pressman wrote:
> >> When autoneg is disabled (and auto fec enabled), the firmware chooses
> >> one of the supported modes according to the spec. As far as I
> >> understand, it doesn't try anything, just picks a supported mode.
> >>
> > This is how ice works if we don't set the ICE_AQC_PHY_EN_FEC_AUTO flag
> > when configuring our firmware.
> 
> If auto fec is off, whatever mode the user chose explicitly should be used.
> What I'm referring to is when auto fec is on, then our firmware picks
> one of the spec modes it sees fit (according to spec).

Correct. I'm referring to a firwamre bit we set, not the ETHTOOL_FEC_AUTO here. Sorry for the confusion, the names are similar but not strictly related. That is definitely a point of confusion here :(

Currently, when ETHTOOL_FEC_AUTO is  set, we always set ICE_AQC_PHY_EN_FEC_AUTO, but if we opted not to do that, then we would have similar behavior to what you describe.

We would choose a single FEC mode to try for the various media types that get tried. We still perform the link state machine, but with fewer FEC options and none of them outside spec. We don't currently have a driver implemented this way.

> 
> >> This whole thing revolves around customers who don't use auto
> >> negotiation, but it sounds like ice is still trying to do auto
> >> negotiation for fec under the hood.
> > It's not really auto negotiation as it is more like auto-retry, its a
> > simple state machine that iterates through a series of possible
> > configurations. The goal being to reduce cognitive burden on users and
> > just try to establish link.
> 
> Cognitive burden can be reduced by using auto negotiation?

I'm not sure what situations result in autonegotiation vs when we have it disabled. For example, if autonegotiation fails we then the link state machine falls back to the series of forced configurations it tries.

The auto selection makes the device attempt to get link, and by enabling more modes we are more likely to achieve link. By having this happen without need for significant user interaction means that users simply see the device link up and function without the need to make a choice.

Thanks,
Jake