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: <bcdfe60a-0eb7-b1cf-15c8-5be7740716a1@intel.com> Date: Thu, 25 Aug 2022 17:38:14 -0700 From: Jacob Keller <jacob.e.keller@...el.com> To: Jakub Kicinski <kuba@...nel.org> CC: Gal Pressman <gal@...dia.com>, Saeed Mahameed <saeedm@...dia.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [PATCH net-next 0/2] ice: support FEC automatic disable On 8/25/2022 1:34 PM, Jakub Kicinski wrote: > Hard to get consensus if we still don't know what the FW does... > But if there's no new uAPI, just always enabling OFF with AUTO > then I guess I'd have nothing to complain about as I don't know > what other drivers do either. > Ok. I think I have a basic summary of the situation and whats going on in the firmware. I'll try to summarize here: Firmware has a state machine that we call the Link Establishment State Machine. This is the state machine which will attempt to establish link. This state machine only applies when auto-negotiation is not used. If auto-negotation is used it will perform the standard auto-negotiation flow and set FEC through that method. The way this works follows this flow: 1) driver sends a set PHY capabilities request. This includes various bits including whether to automatically select FEC, and which FEC modes to select from. When we enable ETHTOOL_FEC_AUTO, the driver always sets all FEC modes with the auto FEC bit. 2) the firmware receives this request and begins the LESM. This starts with the firmware generating a list of configurations to attempt. Each configuration is a possible link mode combined with a bitwise AND of the FEC modes requested above in set PHY capabiltiies and the set of FEC modes supported by that link mode. The example I gave was if you plugged in a CA-L cable, it would try: 100G-CAUI4 50G-LAUI2 25G-AUI-C2C 10G-SFI-DA I'm still not 100% sure how it decides which link modes to choose for which cable, but I believe this is in a table stored within the firmware module we call the netlist. 2a) for older firmware, the set PHY capabiltiies interface does not have a bit to set for requesting No FEC. Instead, each media type has a determination made about whether it needed FEC of not. I was told for example that CA-N cables would enable No FEC as an option, but CA-L cables would not (even though No FEC is supported for the link modes in question). 2b) on newer firmware, the set PHY capabilities interface does have a bit to request No FEC. In this case, if we set the No FEC bit, then the firmware will be able to select No FEC as an option for cables that otherwise wouldn't have selected it in the old firmware (such as CA-L cables mentioned above). 3) once the firmware has generated the list of possible configurations, it will iterate through them in a loop. Each configuration is applied, and then we wait some time (the timeout is also stored in the netlist module). If link establishes at one of these phases, we stop and use that configuration. Otherwise we move to the next configuration and try that. Each FEC mode is tried in sequence. (Unless the automatic FEC selection bit is *not* set. In that case, only one of the FEC modes is tried instead, and it is expected that software only set one bit to try. That would perform forced FEC selection instead). This process will repeat as it iterates through the configurations until link is established. As a side note, the first stage is to try auto-negotiation if enabled. So in the case where auto-negotiation is enabled it will first try auto-negotiation, then the set of forced configurations, and then loop back to trying auto-negotiation before trying the forced configs again. So from the software programming state, we currently translate ETHTOOL_FEC_AUTO by setting the automatic bit as well as setting every FEC mode bit, except the "No FEC" bit. This is a new bit which is only available on newer firmware. With the proposed change, we would add the "No FEC" bit when user requested both ETHTOOL_FEC_AUTO and ETHTOOL_FEC_OFF simultaneously. >From reading your previous replies, you would prefer to just have the driver set the "No FEC" bit always for ETHTOOL_FEC_AUTO when its available/supported by firmware?
Powered by blists - more mailing lists