[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1d57b80-2e62-8799-ce36-bb944ea85ed9@nvidia.com>
Date: Thu, 1 Sep 2022 14:51:55 +0300
From: Gal Pressman <gal@...dia.com>
To: Jacob Keller <jacob.e.keller@...el.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
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).
>> 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?
Powered by blists - more mailing lists