[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <923e103e-b770-163b-f8b6-ff57305f8811@nvidia.com>
Date: Wed, 31 Aug 2022 14:01:10 +0300
From: Gal Pressman <gal@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>
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
On 31/08/2022 00:44, Jakub Kicinski wrote:
> On Tue, 30 Aug 2022 13:09:20 -0700 Jacob Keller wrote:
>> Gal seems against extending uAPI to indicate or support "ignore spec".
>> To be properly correct that would mean changing ice to stop setting the
>> AUTO_FEC flag. As explained above, I believe this will lead to breakage
>> in situations where we used to link and function properly.
> Stop setting the AUTO_FEC flag or start using a new standard compliant
> AUTO flag?
>
> Gal, within the spec do you iterate over modes or pick one mode somehow
> (the spec gives a set, AFAICT)?
When autoneg is enabled (and auto fec enabled), auto negotiation is done
from the link modes according to spec.
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 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.
Looking at the reasons Jacob listed here (unspec switches/modules), it
seems like all this can be resolved by simply setting the fec mode
explicitly, and to me it sounds like a reasonable solution for these
special cases.
Powered by blists - more mailing lists