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
| ||
|
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