ON A 25G ETHERNET LINK

CROSS-REFERENCE TO RELATED U.S. PATENT APPLICATION

[0001] The present application claims priority to U.S. Provisional Patent Application

Serial No. 62/085,072, entitled "TECHNOLOGIES FOR RESOLVING FORWARD ERROR CORRECTION (FEC) MODE ON A 25G ETHERNET LINK," which was filed on November 26, 2014.

BACKGROUND

[0002] 25-gigabit Ethernet over copper cable assembly (so-called "25GBASE-CR") is expected to have several potential varieties, including varieties based on host loss budget (e.g., low loss, mid loss, or high loss) and error correction (e.g., RS-FEC, BASE-R FEC, or no FEC encoding). This richness of options creates an interoperability challenge.

[0003] The Forward Error Correction (FEC) mode may be selected using only capability/request (as in the FEC described by clause 74 of the IEEE standard 802.3). Currently, the "request" is a part of a variable mr_adv_ability (the autonegotiation advertisement management register). The desired "request" may depend on cable and hosts budget in a non-obvious manner. Thus, the capability/request may not provide plug-and-play configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The concepts described herein are illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.

[0005] FIG. 1 is a simplified block diagram of at least one embodiment of Ethernet port logic for automatically resolving FEC mode;

[0006] FIG. 2 is a simplified block diagram of at least one embodiment of a computing device that may include the Ethernet port logic of FIGS. 1 and 2;

[0007] FIG. 3 is a simplified flow diagram of at least one embodiment of a method for automatically resolving FEC mode using an autonegotiation protocol that may be executed by the Ethernet port logic of FIGS. 1 and 2; [0008] FIG. 4 is a schematic diagram illustrating at least one embodiment of autonegotiation pages that may be exchanged by the Ethernet port logic of FIGS. 1 and 2;

[0009] FIG. 5 is a table diagram illustrating resolution rules that may be evaluated by the Ethernet port logic of FIGS. 1 and 2;

[0010] FIG. 6 is a simplified flow diagram of at least one embodiment of a method for automatically resolving FEC mode using an autonegotiation protocol that may be executed by the Ethernet port logic of FIGS. 1 and 2;

[0011] FIG. 7 is a simplified flow diagram of at least one embodiment of another method for automatically resolving FEC mode using an autonegotiation protocol that may be executed by the Ethernet port logic of FIGS. 1 and 2;

[0012] FIG. 8 is a simplified flow diagram of at least one embodiment of a method for automatically resolving FEC mode during a link training phase that may be executed by the Ethernet port logic of FIGS. 1 and 2; and

[0013] FIG. 9 is a schematic diagram illustrating at least one embodiment of link training frames that may be exchanged by the Ethernet port logic of FIGS. 1-2.

DETAILED DESCRIPTION OF THE DRAWINGS

[0014] While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

[0015] References in the specification to "one embodiment," "an embodiment," "an illustrative embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of "at least one of A, B, and C" can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of "at least one of A, B, or C" can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).

[0016] The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

[0017] In the drawings, some structural or method features may be shown in specific arrangements and/or ordering s. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.

[0018] Referring now to FIG. 1, an Ethernet port logic 100 is configured to communicate over one or more physical communication lanes 102. In the illustrative embodiment, the Ethernet port logic 100 is configured to automatically resolve forward error correction (FEC) mode with a link partner. The Ethernet port logic 100 may resolve the FEC mode during an autonegotiation process or during a physical-medium dependent link training process. Thus, the Ethernet port logic 100 is able to resolve FEC mode automatically, allowing improved configuration of 25-gigabit Ethernet links. Additionally, in some embodiments, autonegotiation functions or other processes of existing Ethernet logic may be re-used with minimal changes.

[0019] The illustrative Ethernet port logic 100 includes an autonegotiation module 104, a physical medium dependent (PMD) sublayer/physical medium attachment (PMA) sublayer 106, a forward error correction (FEC) sublayer 108, a physical coding sublayer (PCS) module 110, and a reconciliation sublayer/media access control sublayer (MAC) module 112. Each of the modules of the Ethernet port logic 100 may be embodied as hardware, firmware, and/or software of the Ethernet port logic 100. For example, the autonegotiation module 104, the PMD/PMA sublayer 106, the FEC sublayer 108, the PCS module 110, and/or the RS/MAC module 112 may be embodied as a functional block or other component of a microprocessor, microcontroller, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other computer logic component of the Ethernet port logic 100. As another example, in some embodiments the autonegotiation module 104, the PMD/PMA sublayer 106, the FEC sublayer 108, the PCS module 110, and/or the RS/MAC module 112 may be embodied as one or more computer-readable media storing instructions that, when executed by a microprocessor, microcontroller, or other processing resources of the Ethernet port logic 100, perform the described functions. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, part or all of the autonegotiation module 104, the PMD/PMA 106, and/or the FEC 108 may be incorporated in the PCS 110.

[0020] The communication lanes 102 may be embodied as any one or more computer communication links. For example, each communication lane 102 may be embodied as a twinaxial copper cable or as an electrical backplane connection. In some embodiments, each communication lane 102 may be capable of full-duplex operation. For example, each communication lane 102 may include two twinaxial pairs of electrical conductors, one pair for transmitting data and the other pair for receiving data. Illustratively, the communication lanes 102 may include a single communication lane 102 operating at 25 gigabits per second (Gb/s). Although described as operating at a data rate such as 25 Gb/s, it should be understood that in some embodiments each of the communications lanes 102 may operate at a slightly higher signaling rate such as 25.78125 Gb/s, to allow for additional data for line encoding, error correction, and other additional data. Additionally, in some embodiments, each of the communications lanes 102 may operate at a higher data rate, such as 50 Gb/s or higher.

[0021] The autonegotiation module 104 is configured to auto-negotiate line transmission speed, mode of operation, and other communication parameters with a link partner when the communication lane 102 is brought up. Additionally, in some embodiments the autonegotiation module 104 may be configured to automatically resolve FEC mode with the remote link partner. The autonegotiation module 104 may be configured to determine advertised FEC technology abilities based on local host loss characteristics and, in some embodiments, based on cable loss associated with the communication lanes 102. The autonegotiation module 104 may be configured to exchange advertised FEC technology abilities and advertised host loss information with the remote link partner, for example, in a base link codeword or in a next page. The autonegotiation module 104 may be configured to select the highest-priority shared FEC technology ability for the communication link. Although illustrated in FIG. 1 as coupled between the PMD/PMA 106 and the communication lanes 102, in other embodiments the autonegotiation module 104 may be included at different positions in the Ethernet port logic 100. For example, in some embodiments the autonegotiation module 104 may be coupled between the PMD/PMA 106 and the FEC 108.

[0022] The PMD/PMA 106 is configured to transmit and receive serial binary data over the communication lanes 102. The PMD/PMA 106 may be configured to perform a control function, in which equalizers or other transmitter and/or receiver circuits of the Ethernet port logic 100 may be tuned based on channel characteristics of the physical communication lanes 102. When training is complete, more information about the channel is available to the Ethernet port logic 100 than is available during the autonegotiation process. Additionally, in some embodiments the PMD/PMA 106 may be configured to automatically resolve FEC mode with the remote link partner. The PMD/PMA 106 may encode the FEC technology abilities, for example, in a PMD training frame exchanged during the PMD control function. The PMD/PMA 106 may be configured to request certain predefined technology abilities, or to determine the requested technology abilities based on the dynamic characteristics of the communication channel determined during link training. After negotiating a technology ability during link training, the PMD/PMA 106 may communicate the selected FEC choice to the other components of the Ethernet port logic 100 (e.g., the FEC 108 and/or the PCS 110). The PMD/PMA 106 may include one or more transmission and/or receiver circuits used to communicate data over the physical communication lanes 102.

[0023] The FEC 108 is configured to apply a forward error correction code to the data passed between the PMD/PMA 106 and the PCS 110. In other words, the FEC 108 may encode data passed from the PCS 110 to the PMD/PMA 106 and decode data passed from the PMD/PMA 106 to the PCS 110. The forward error correction code may improve the reliability of data transmission at higher line speeds. The FEC 108 may support multiple FEC technology abilities, such as a Reed-Solomon forward error correction code (RS-FEC) similar to the one described by clause 91 of the IEEE standard 802.3bj or a FEC code similar to the one described by clause 74 of the IEEE standard 802.3 (2012) (known as BASE-R FEC, KR FEC, or the "Fire code"). In some embodiments, the FEC 108 may apply no FEC code at all (NO FEC). As described further below, each of the FEC technology abilities may have a different priority.

[0024] The PCS 110 is configured to encode Ethernet frame data received from the

MAC 112 into encoded data blocks that may be transmitted by the PMD/PMA 106, and to decode data received from the PMD/PMA 106 into decoded Ethernet frame data that may be processed by the MAC 112. The PCS 110 may encode and distribute the data blocks over one or more logical PCS lanes. The PCS 110 may encode data for transmission over the communication lanes 102 for example, to improve communication efficiency. For example, encoding the data may add timing or synchronization symbols, align the data, add state transitions to the encoded data to improve clock recovery, adjust the DC balance of the data signal, or otherwise prepare the encoded data for serial transmission.

[0025] The MAC 112 is configured to transmit Ethernet frame data to the PCS 110 to be encoded and transmitted, and to receive data from the PCS 110 to produce Ethernet frame data. The MAC 112 may perform Ethernet frame detection and validation, packet reception and transmission, cyclic redundancy check (CRC) validation, CRC computation, and other media access control sublayer operations.

[0026] Referring now to FIG. 2, in an illustrative embodiment, a computing device 200 may include the Ethernet port logic 100. The computing device 200 may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a smartphone, a tablet computer, a laptop computer, a notebook computer, a mobile computing device, a wearable computing device, a multiprocessor system, a server, a rack-mounted server, a blade server, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. As shown in FIG. 1, the computing device 200 illustratively includes a processor 220, an input/output subsystem 222, a memory 224, a data storage device 226, and a network interface controller (NIC) 228. Of course, the computing device 200 may include other or additional components, such as those commonly found in a computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory 224, or portions thereof, may be incorporated in the processor 220 in some embodiments.

[0027] The processor 220 may be embodied as any type of processor capable of performing the functions described herein. For example, the processor 220 may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. Similarly, the memory 224 may be embodied as any type of volatile or non- volatile memory or data storage capable of performing the functions described herein. In operation, the memory 224 may store various data and software used during operation of the computing device 200 such as operating systems, applications, programs, libraries, and drivers. The memory 224 is communicatively coupled to the processor 220 via the I/O subsystem 222, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor 220, the memory 224, and other components of the computing device 200. For example, the I/O subsystem 222 may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. In some embodiments, the I/O subsystem 222 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor 220, the memory 224, and other components of the computing device 200, on a single integrated circuit chip. The data storage device 226 may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices.

[0028] The NIC 228 may connect the computing device 200 to one or more computing devices, network devices, switches, remote hosts, or other devices. The NIC 228 may be embodied as one or more add-in-boards, daughtercards, controller chips, chipsets, circuits, or other devices that may be used by the computing device 200 for network communications with remote devices. For example, the NIC 228 may be embodied as an expansion card coupled to the I/O subsystem 222 over an expansion bus such as PCI Express. As another example, in some embodiments the NIC 228 may be embodied as a network controller integrated with the I/O subsystem 222, the processor 220, a system-on-a-chip, and/or one or more other components of the computing device 200. In the illustrative embodiment, the NIC 228 includes a single Ethernet port logic 100 to connect to the remote devices. Of course, in other embodiments the computing device 200 may include additional or fewer Ethernet port logics 100 to support a different number of communication lanes 102.

[0029] In some embodiments, the computing device 200 may also include one or more peripheral devices 230. The peripheral devices 230 may include any number of additional input/output devices, interface devices, and/or other peripheral devices. For example, in some embodiments, the peripheral devices 230 may include a display, touch screen, graphics circuitry, keyboard, mouse, speaker system, network interface, and/or other input/output devices, interface devices, and/or peripheral devices.

[0030] Referring now to FIG. 3, in use, the Ethernet port logic 100 may execute a method 300 for automatically resolving FEC mode with a remote link partner. The method 300 begins in block 302, in which the Ethernet port logic 100 starts an autonegotiation protocol. The autonegotiation protocol may be started, for example, when the Ethernet port logic 100 is initialized or when the physical communication lane 102 is connected. As described further below, the autonegotiation protocol performed by the Ethernet port logic 100 may be similar to the autonegotiation protocol defined in clause 73 of the IEEE standard 802.3, with support for additional FEC technology abilities.

[0031] In block 304, the Ethernet port logic 100 determines the locally supported FEC technology abilities. For example, the Ethernet port logic 100 may determine whether the FEC 108 is capable of communicating using the Reed-Solomon forward error correction code (RS- FEC) similar to the one described by clause 91 of the IEEE standard 802.3bj, using the BASE- R FEC code similar to the one described by clause 74 of the IEEE standard 802.3 (2012) (defined for backplane Ethernet), or using no FEC code at all (NO FEC). The Ethernet port logic 100 may include built-in or otherwise preconfigured support for various FEC technology abilities. In some embodiments, the locally supported FEC technology abilities may be configured using a management interface or other configuration feature of the Ethernet port logic 100. The Ethernet port logic 100 may rank or otherwise assign increasing priories to the technology abilities based on performance and/or latency. For example, RS-FEC may have the lowest priority, followed by BASE-R FEC, and then NO FEC.

[0032] In block 306, the Ethernet port logic 100 determines a local host loss characteristic of the local host (e.g., the local computing device 200). The local host may be classified as, for example, a low-loss host, a mid-loss host, or a high-loss host. The Ethernet port logic 100 may use any technique to determine the local host loss characteristic. For example, the Ethernet port logic 100 may be configured with a predefined local host loss. In some embodiments, the Ethernet port logic 100 may determine the local host loss characteristic based on a host insertion loss value at the Nyquist frequency (e.g., 12.8906 GHz). The mid-loss host characteristic may be based on clause 92 of the IEEE standard 802.3.

[0033] In block 308, the Ethernet port logic 100 applies one or more resolution rules to determine one or more technology abilities to be advertised to the remote link partner. The Ethernet port logic 100 determines the advertised technology abilities based on available information concerning the local host as well as information concerning the overall channel connecting the local host and the remote link partner. In block 310, the Ethernet port logic 100 determines the advertised technology abilities based on the characteristics of the Ethernet port logic 100. For example, the Ethernet port logic 100 may only select technology abilities that are supported by the FEC 108. As another example, the Ethernet port logic 100 may select technology abilities based on the host loss classification of the local host (e.g., low-loss, mid- loss, or high-loss). In some embodiments, in block 312, the Ethernet port logic 100 may determine the supported technology abilities based on a cable loss characteristic for the physical communication lane 102 (e.g., a classifying the cable loss as a low-loss cable or a high-loss cable. The Ethernet port logic 100 may determine the cable loss using a cable management interface or assume that the cable is high loss.

[0034] Referring now to FIG. 5, a diagram 500 illustrates one potential embodiment of resolution rules that may be used to determine advertised technology abilities. Each table of the diagram 500 illustrates compatible advertised technology abilities that may be selected based on a combination of local host loss category, cable loss category, and remote host loss category. Table 502 illustrates advertised technology abilities for a mid-loss remote host or an unknown remote host loss (which is assumed to be mid-loss). Thus, the table 502 may be used to resolve the advertised technology abilities when remote host loss information is unknown, as described above in connection with block 308 of FIG. 3. For example, the combination of a low local host loss and a low cable loss may select advertisement of any of RS-FEC, BASE-R FEC, and NO FEC; a combination of a low local host loss and a high cable loss (or unknown cable loss) may select advertisement of RS-FEC, and so on.

[0035] It should be understood that although the diagram 500 illustrates one potential embodiment of resolution rules, other sets of rules are possible. For example, as shown in the diagram 500, the combination of low local host loss, low cable loss, and mid/unknown remote host loss selects advertisement of any of RS-FEC, BASE-R FEC, and NO FEC. In some embodiments, that combination of low local host loss, low cable loss, and mid/unknown remote host loss may select advertisement of any of RS-FEC and BASE-R FEC (i.e., does not select advertisement of NO FEC).

[0036] Referring back to FIG. 3, in block 314, the Ethernet port logic 100 exchanges the advertised technology abilities and host loss information with the remote link partner. In other words, the Ethernet port logic 100 transmits the local advertised FEC technology abilities to the remote link partner and receives advertised remote FEC technology abilities from the remote link partner. Additionally, the Ethernet port logic 100 may transmit local host loss information to the remote link partner and receive remote host loss information from the remote link partner. In some embodiments, in block 316, the Ethernet port logic 100 may transmit the advertised technologies and host loss information in an autonegotiation base link codeword. In some embodiments, in block 318 the Ethernet port logic 100 may transmit the advertised technologies and host loss information in an autonegotiation next page.

[0037] Referring now to FIG. 4, diagram 400 illustrates potential embodiments of autonegotiation pages that may be exchanged by the Ethernet port logic 100. Diagram 400 illustrates a base page 402, which includes 48 bits organized into several bits and groups of bits called fields. In particular, the base page 402 includes a selector field S, an echoed nonce field E, a capability field C, a remote fault bit RF, an ACK bit, a next page bit NP, a transmitted nonce field T, a technology ability field A, and a forward error correction capability field F. The advertised FEC technology abilities and the host loss information may be encoded as one or more bits of the technology ability field A. For example, one bit may indicate RS-FEC, another bit may indicate BASE-R FEC, and a third bit may indicate NO FEC. Similarly, one or two bits may be used to indicate a host loss class. Of course, any other appropriate encoding may be used.

[0038] The diagram 400 also illustrates a message next page 404. The autonegotiation protocol described in clause 73 of the IEEE 802.3 defines encodings for 48-bit "next pages" that may be transmitted after transmission of the base page, including message next pages and unformatted next pages. As shown, the message next page 404 includes 48 bits organized into several bits and groups of bits called fields (not to scale). The message next page 404 includes both a message code field M and an unformatted code field U. In particular, the message next page includes the message code field M, a toggle bit T, an acknowledge 2 bit ACK 2, a message page bit MP (always set for message next pages 404), an acknowledge bit ACK, a next page bit NP, and the unformatted code field U. The message code field M may include a unique identifier, and the advertised FEC technology abilities and the host loss information may be encoded as one or more bits of the unformatted code field U.

[0039] Referring back to FIG. 3, in block 320, the Ethernet port logic 100 selects the highest-priority common FEC technology ability. In other words, the Ethernet port logic 100 selects the highest-priority FEC technology ability that is common to the advertised FEC technologies of the Ethernet port logic 100 and the remote link partner. The FEC technology ability having the lowest latency may be defined as having the highest priority. For example, the Ethernet port logic 100 may select NO FEC if that technology is supported by both link partners, BASE-R FEC if that technology is supported by both link partners, and RS-FEC if that technology is supported by both link partners, in that order of priority. If no common technology exists for the link partners, the autonegotiation process may fail or restart.

[0040] In some embodiments, in block 322, the Ethernet port logic 100 may repeat the advertisement of technology abilities one or more times based on remote host loss information received from the remote link partner. For example, if the remote link partner is identified as a low-loss host, the Ethernet port logic 100 may restart the autonegotiation process and advertise one or more higher-priority technology abilities. Referring again to FIG. 5, table 504 illustrates resolution rules that may be applied if the remote link partner is known to be a low-loss host. One potential embodiment of a method for automatically determining technology abilities including repeated advertisement of technology abilities is described below in connection with FIG. 6.

[0041] In some embodiments, in block 324 the Ethernet port logic 100 may upgrade the selected technology ability from the highest-priority common advertised FEC technology ability based on remote host loss information received from the remote link partner. For example, the Ethernet port logic 100 may execute a method for autonegotiation that includes upgrading the technology ability as described below in connection with FIG. 7. Upgrading the selected technology ability without repeating advertisement of technology abilities may require the remote link partner to perform the same upgrade process.

[0042] In block 326, the Ethernet port logic 100 brings up the communication link using the negotiated FEC technology ability. After bringing up the communication link, the Ethernet port logic 100 may perform a link training procedure as described further below in connection with FIG. 8.

[0043] Referring now to FIG. 6, in use, the Ethernet port logic 100 may execute a method 600 for automatically resolving FEC mode with a remote link partner. The method 600 begins in block 602, in which the Ethernet port logic 100 starts an autonegotiation protocol. As described above, the autonegotiation protocol may be started, for example, when the Ethernet port logic 100 is initialized or when the physical communication lane 102 is connected. The autonegotiation protocol performed by the Ethernet port logic 100 may be similar to the autonegotiation protocol defined in clause 73 of the IEEE standard 802.3, with support for additional FEC technology abilities.

[0044] In block 604, the Ethernet port logic 100 determines the locally supported FEC technology abilities. For example, the Ethernet port logic 100 may determine whether the FEC 108 is capable of communicating using the Reed-Solomon forward error correction code (RS- FEC) similar to the one described by clause 91 of the IEEE standard 802.3bj, using the BASE- R FEC code similar to the one described by clause 74 of the IEEE standard 802.3 (2012) (defined for backplane Ethernet), or using no FEC code at all (NO FEC). The Ethernet port logic 100 may include built-in or otherwise preconfigured support for various FEC technology abilities. In some embodiments, the locally supported FEC technology abilities may be configured using a management interface or other configuration feature of the Ethernet port logic 100. The Ethernet port logic 100 may rank or otherwise assign increasing priories to the technology abilities based on performance and/or latency. For example, RS-FEC may have the lowest priority, followed by BASE-R FEC, and then NO FEC. [0045] In block 606, the Ethernet port logic 100 determines a local host loss characteristic of the local host (e.g., the local computing device 200). The local host may be classified as, for example, a low-loss host, a mid-loss host, or a high-loss host. The Ethernet port logic 100 may use any technique to determine the local host loss characteristic. For example, the Ethernet port logic 100 may be configured with a predefined local host loss. In some embodiments, the Ethernet port logic 100 may determine the local host loss characteristic based on a host insertion loss value at the Nyquist frequency (e.g., 12.8906 GHz). The mid-loss host characteristic may be based on clause 92 of the IEEE standard 802.3.

[0046] In block 608, the Ethernet port logic 100 determines a cable loss characteristic for the physical communication lane 102. The cable loss may be classified as a low-loss cable or a high-loss cable. For example, the Ethernet port logic 100 may determine whether it is connected to a "low loss" (e.g. up to 3 m) or "high loss" (e.g. 3 to 5 m) cable. In some embodiments, the Ethernet port logic 100 may determine the cable loss using a cable management interface coupled to the Ethernet port logic 100 or other technique outside the scope of the IEEE standard 802.3. For example, the Ethernet port logic 100 may read the cable loss information from a small memory embedded in the physical connector of the attached cable. If cable loss information is not available, the Ethernet port logic 100 may assume that the cable is high loss.

[0047] In block 610, the Ethernet port logic 100 assigns an assumed value to the remote host loss associated with the remote link partner. At this point in the autonegotiation process, the Ethernet port logic 100 has little information concerning the remote link partner. Therefore, the Ethernet port logic 100 assigns a predefined assumed remote host loss value (e.g., low-loss host, mid-loss host, or high-loss host). In the illustrative embodiment, the remote link partner is assumed to be a mid-loss host.

[0048] In block 612, the Ethernet port logic 100 determines one or more advertised FEC technology abilities based on the local host loss, the cable loss, and the remote host loss (which is initially set to the assumed value). As further described below, the remote host loss information may be updated in subsequent iterations of the autonegotiation process. The Ethernet port logic 100 may advertise a technology ability only if that technology ability is supported by the Ethernet port logic 100 and if the Ethernet port logic 100 has a sufficient indication that the overall channel supports the technology ability. In particular, the Ethernet port logic 100 may apply one or more rules as illustrated in tables 502, 504 of FIG. 5 to determine the technologies to advertise. For example, if the local host is a low-loss host, the cable is a low-loss cable, and the remote host loss is assumed to be mid-loss, based on the rules of table 502, the Ethernet port logic 100 may advertise RS-FEC, BASE-R FEC, and NO FEC. As another example, if the local host is a high-loss host, the cable is a high-loss cable, and the remote host loss is assumed to be mid-loss, based on the rules of table 502, the Ethernet port logic 100 may not advertise any supported technology abilities.

[0049] In block 614, the Ethernet port logic 100 determines whether the local host is a low-loss host and whether the local host supports the next higher-priority FEC technology ability compared to the advertised FEC technology abilities. For example, if the advertised technology ability is RS-FEC, the Ethernet port logic 100 may determine whether BASE-R FEC is supported, if the advertised technology ability is BASE-R FEC, the Ethernet port logic 100 may determine whether NO FEC is supported, and so on.

[0050] In block 616, the Ethernet port logic 100 determines whether to advertise as a low-loss host. The Ethernet port logic 100 may advertise as a low loss host if it is low loss and if it supports the next FEC technology ability, as described above in connection with block 614. An Ethernet port logic 100 that does not support the next FEC mode (having a priority one level higher than the top one it advertises, up to NO FEC) may not advertise as a low-loss host. If the Ethernet port logic 100 determines not to advertise as a low-loss host, the method 600 branches ahead to block 620. If the Ethernet port logic 100 determines to advertise as a low-loss host, the method 600 advances to block 618, in which the Ethernet port logic 100 advertises as a low- loss host. For example, the Ethernet port logic 100 may advertise as a low-loss host by setting one or more bits of a host loss field, which may be encoded using one or more bits of an autonegotiation next page or an autonegotiation base page.

[0051] In block 620, the Ethernet port logic 100 exchanges advertised technology abilities and the host loss field with the remote link partner. In other words, the Ethernet port logic 100 transmits the local advertised FEC technology abilities and host loss field to the remote link partner and receives advertised remote FEC technology abilities and a remote host loss field from the remote link partner. As described above in connection with FIG. 3, the Ethernet port logic 100 may exchange the advertised technologies and the host loss field in an autonegotiation base link codeword or in an autonegotiation next page.

[0052] In block 622, the Ethernet port logic 100 determines to retry autonegotiation if the local host is not low-loss (e.g., if the local host is a mid-loss or a high-loss host) and the remote link partner advertises that it is a low-loss host. In block 624, the Ethernet port logic 100 checks whether to retry the autonegotiation. If not, the method 600 branches ahead to block 628, described below. If the Ethernet port logic 100 determines to retry autonegotiation, the method 600 branches to block 626. [0053] In block 626, the Ethernet port logic 100 assigns a low-loss value to the remote host loss. After assigning low loss to the remote host loss, the method 600 loops back to block 612 to repeat determining and exchanging the advertised technology abilities. As described above, the Ethernet port logic 100 may advertise higher-priority technology abilities after determining that the remote link partner is low-loss. In other words, if a host that isn't low-loss detects a low-loss advertisement by the remote link partner, the Ethernet port logic 100 may avoid bringing up the negotiated technology ability and then re-run autonegotiation with the advertisement modified based on this new information. For example, if the local host is a high- loss host, the cable is a high-loss cable, and the remote host loss is determined to be low-loss, based on the rules of table 504, the Ethernet port logic 100 may advertise RS-FEC.

[0054] Referring back to block 624, if the Ethernet port logic 100 determines not to retry autonegotiation, the method 600 advances to block 628, in which the Ethernet port logic 100 selects the highest-priority common FEC technology ability. In other words, the Ethernet port logic 100 selects the highest-priority FEC technology ability that is common to the advertised FEC technologies of the Ethernet port logic 100 and the remote link partner. The FEC technology ability having the lowest latency may be defined as having the highest priority. For example, the Ethernet port logic 100 may select NO FEC if that technology is supported by both link partners, BASE-R FEC if that technology is supported by both link partners, and RS- FEC if that technology is supported by both link partners, in that order of priority. If no common technology exists for the link partners, the autonegotiation process may fail or restart.

[0055] In block 630, the Ethernet port logic 100 brings up the communication link using the negotiated FEC technology ability. After bringing up the communication link, the Ethernet port logic 100 may perform a link training procedure as described further below in connection with FIG. 8.

[0056] Referring now to FIG. 7, in use, the Ethernet port logic 100 may execute a method 700 for automatically resolving FEC mode with a remote link partner. The method 700 begins in block 702, in which the Ethernet port logic 100 starts an autonegotiation protocol. As described above, the autonegotiation protocol may be started, for example, when the Ethernet port logic 100 is initialized or when the physical communication lane 102 is connected. The autonegotiation protocol performed by the Ethernet port logic 100 may be similar to the autonegotiation protocol defined in clause 73 of the IEEE standard 802.3, with support for additional FEC technology abilities.

[0057] In block 704, the Ethernet port logic 100 determines the locally supported FEC technology abilities. For example, the Ethernet port logic 100 may determine whether the FEC 108 is capable of communicating using the Reed-Solomon forward error correction code (RS- FEC) similar to the one described by clause 91 of the IEEE standard 802.3bj, using the BASE- R FEC code similar to the one described by clause 74 of the IEEE standard 802.3 (2012) (defined for backplane Ethernet), or using no FEC code at all (NO FEC). The Ethernet port logic 100 may include built-in or otherwise preconfigured support for various FEC technology abilities. In some embodiments, the locally supported FEC technology abilities may be configured using a management interface or other configuration feature of the Ethernet port logic 100. The Ethernet port logic 100 may rank or otherwise assign increasing priories to the technology abilities based on performance and/or latency. For example, RS-FEC may have the lowest priority, followed by BASE-R FEC and then NO FEC.

[0058] In block 706, the Ethernet port logic 100 determines a local host loss characteristic of the local host (e.g., the local computing device 200). The local host may be classified as, for example, a low-loss host, a mid-loss host, or a high-loss host. The Ethernet port logic 100 may use any technique to determine the local host loss characteristic. For example, the Ethernet port logic 100 may be configured with a predefined local host loss. In some embodiments, the Ethernet port logic 100 may determine the local host loss characteristic based on a host insertion loss value at the Nyquist frequency (e.g., 12.8906 GHz). The mid-loss host characteristic may be based on clause 92 of the IEEE standard 802.3.

[0059] In block 708, the Ethernet port logic 100 determines a cable loss characteristic for the physical communication lane 102. The cable loss may be classified as a low-loss cable or a high-loss cable. For example, the Ethernet port logic 100 may determine whether it is connected to a "low loss" (e.g. up to 3 m) or "high loss" (e.g. 3 to 5 m) cable. In some embodiments, the Ethernet port logic 100 may determine the cable loss using a cable management interface coupled to the Ethernet port logic 100 or other technique outside the scope of the IEEE standard 802.3. For example, the Ethernet port logic 100 may read the cable loss information from a small memory embedded in the physical connector of the attached cable. If cable loss information is not available, the Ethernet port logic 100 may assume that the cable is high loss.

[0060] In block 710, the Ethernet port logic 100 determines one or more advertised FEC technology abilities based on the local host loss and the cable loss. Unlike the method 600 of FIG. 6, described above, the Ethernet port logic 100 does not determine the advertised FEC technology abilities based on any remote host loss associated with the remote link partner. The Ethernet port logic 100 may advertise a technology ability only if that technology ability is supported by the Ethernet port logic 100 and if the Ethernet port logic 100 has a sufficient indication that the overall channel supports the technology ability. In particular, the Ethernet port logic 100 may apply one or more rules as illustrated in the table 502 of FIG. 5 to determine the technologies to advertise. For example, if the local host is a low-loss host and the cable is a low-loss cable, the Ethernet port logic 100 may advertise RS-FEC, BASE-R FEC, and NO FEC. As another example, if the local host is a high-loss host and the cable is a high-loss cable, the Ethernet port logic 100 may not advertise any supported technology abilities.

[0061] In block 712, the Ethernet port logic 100 the Ethernet port logic 100 determines whether to advertise that the Ethernet port logic 100 has extra link budget in the host loss field based on the local host loss and the local FEC 108 capabilities. A low-loss host may advertise that it has extra budget in the host loss field if the Ethernet port logic 100 supports the next- higher priority FEC technology ability. For example, an Ethernet port logic 100 that supports BASE-R FEC and has low host loss may advertise extra budget when advertising RS-FEC, an Ethernet port logic 100 that supports NO FEC and has low host loss may advertise extra budget when advertising BASE-R FEC, and so on. The Ethernet port logic 100 may advertise that is has extra link budget as a positive credit value in the host loss field (for example, +1).

[0062] In block 714, the Ethernet port logic 100 determines whether to advertise that it needs extra budget in the host loss field based on the local host loss and the local FEC 108 capabilities. For example, a mid-loss or high-loss device that supports a FEC technology ability of higher priority than the advertised technology ability may advertise that it needs extra budget. Continuing that example, a mid-loss or high-loss device that supports BASE-R FEC may advertise that it needs extra budget when advertising RS-FEC, a mid-loss or high-loss device that supports NO FEC may advertise that it needs extra budget when advertising BASE- R FEC, and so on. The Ethernet port logic 100 may advertise that is needs extra link budget as a negative credit value in the host loss field (for example, -1). An Ethernet port logic 100 that does not support the next-higher priority FEC technology ability may not advertise that it has extra budget or that it needs extra budget.

[0063] In block 716, the Ethernet port logic 100 exchanges advertised technology abilities and the host loss field with the remote link partner. In other words, the Ethernet port logic 100 transmits the local advertised FEC technology abilities and host loss field to the remote link partner and receives advertised remote FEC technology abilities and a remote host loss field from the remote link partner. As described above in connection with FIG. 3, the Ethernet port logic 100 may exchange the advertised technologies and the host loss field in an autonegotiation base link codeword or in an autonegotiation next page. [0064] In block 718, the Ethernet port logic 100 selects the highest-priority common

FEC technology ability as the tentative technology. In other words, the Ethernet port logic 100 selects the highest-priority FEC technology ability that is common to the advertised FEC technologies of the Ethernet port logic 100 and the remote link partner. The FEC technology having the lowest latency may be defined as having the highest priority. For example, the Ethernet port logic 100 may select NO FEC if that technology is supported by both link partners, BASE-R FEC if that technology is supported by both link partners, and RS-FEC if that technology is supported by both link partners, in that order of priority.

[0065] In block 720, the Ethernet port logic 100 determines whether an advertised "has extra budget" is paired with an advertised "needs extra budget." For example, the Ethernet port logic 100 may determine whether the local host has advertised that it needs extra budget and the remote link partner has advertised that it has extra budget, or whether the local host has advertised that it has extra budget and the remote link partner has advertised that it needs extra budget. The Ethernet port logic 100 may make this determination, for example, by determining whether the exchanged host loss fields include both a positive credit value and a negative credit value (e.g., a pair of +1 and -1 credit values). In block 722, the Ethernet port logic 100 determines whether a pairing exists. If not, the method 700 branches ahead to block 726. If a pairing exists, the method 700 advances to block 724.

[0066] In block 724, the Ethernet port logic 100 upgrades the tentative FEC technology ability to the technology ability having the next-higher priority. For example, if the tentative link technology is RS-FEC, the Ethernet port logic 100 may upgrade to BASE-R FEC, if the tentative link technology is BASE-R FEC, the Ethernet port logic 100 may upgrade to NO FEC, and so on. In some embodiments, if no connectivity was tentatively available after exchanging advertised technology abilities, the Ethernet port logic 100 may upgrade to RS-FEC. The selection of the upgraded technology may be aligned with the compatibility matrices described above in connection with FIG. 5. Thus, resolution of the FEC technology ability may occur after the host loss field has been exchanged, and may resolve within a single autonegotiation cycle. In block 726, the Ethernet port logic 100 brings up the communication link using the negotiated FEC technology ability. If no common technology exists for the link partners after negotiation and determining whether to upgrade the technology, the autonegotiation process may fail or restart. After bringing up the communication link, the Ethernet port logic 100 may perform a link training procedure as described further below in connection with FIG. 8.

[0067] Referring now to FIG. 8, in use, the Ethernet port logic 100 may execute a method 800 for automatically resolving FEC mode with a remote link partner. The method 800 begins in block 802, in which the Ethernet port logic 100 completes an autonegotiation protocol and brings up the link. During the autonegotiation process, the Ethernet port logic 100 may advertise a single 25GBASE-CR technology ability, without performing automatic FEC mode resolution as described above in connection with FIGS. 3-7. In some embodiments, the autonegotiation protocol may be performed as defined in clause 73 of the IEEE standard 802.3. After bringing up the link, the Ethernet port logic 100 and the remote link partner may communicate at full link speed, e.g., at 25 Gb/s.

[0068] In block 804, the Ethernet port logic 100 builds a FEC request field, that is, a field identifying FEC technology abilities requested by the Ethernet port logic 100. For example, the FEC request field may be embodied as a two-bit value, with value '00' corresponding to NO FEC, ΌΓ corresponding to BASE-R FEC, ' 10' corresponding to RS- FEC, and Ί reserved. In some embodiments, in block 806 the Ethernet port logic 100 may set the outgoing FEC request field statically, for example using a management interface. In some embodiments, in block 808 the Ethernet port logic 100 may set the outgoing FEC request dynamically based on the signal or other channel characteristics. For example, the Ethernet port logic 100 may set the outgoing FEC request based on a measured bit error rate (BER) of the link, a link margin, or other implementation-dependent capability.

[0069] In block 810, the Ethernet port logic 100 exchanges PMD training frames with the remote link partner. As described in clause 72.6.10 of the IEEE standard 802.3 (2012), during startup the PMD/PMA 106 may continuously transmit training frames including a control channel. In block 812, the Ethernet port logic 100 transmits a training frame to the link partner that includes the outgoing FEC request and an outgoing FEC response. The outgoing FEC response may be determined as described below in connection with block 818, and may initially be set to an invalid value (e.g., a "not applicable" or similar value). The outgoing FEC request and response may be encoded in one or more bits of the control channel of the PMD frame, such as cells 7:6 of the coefficient update field and cells 7:6 of the status report field, respectively. In block 814, the Ethernet port logic 100 receives a training frame from the link partner that includes an incoming FEC request and an incoming FEC response. The incoming FEC request and the incoming FEC response may be similarly encoded in the control channel (e.g., as cells 7:6 of the coefficient update field and cells 7:6 of the status report field, respectively).

[0070] Referring now to FIG. 9, diagram 900 illustrates one potential embodiment of the FEC request and FEC response. The diagram 900 illustrates a PMD training frame 902. As shown, the PMD training frame includes 548 octets, organized as a frame marker, a coefficient update 904, a status report 906, and a training pattern. Each of the coefficient update 904 and the status report 906 includes 16 octets or cells, and each cell encodes a single bit. As shown, the coefficient update 904 includes a FEC request 908 encoded in cells 7:6, and the status report 906 includes a FEC response 910 encoded in cells 7:6.

[0071] Referring back to FIG. 8, in block 816, the Ethernet port logic 100 sets a local receiver ready field (e..g, a local_rx_ready field) if the incoming FEC request matches the outgoing FEC response. The Ethernet port logic 100 may determine whether the local receiver is ready based on the values of the training frames exchanged above in connection with block 810. The Ethernet port logic 100 may output the local_rx_ready field to the remote link partner, for example in the PMD control frame as part of the status report field.

[0072] In block 818, the Ethernet port logic 100 determines the outgoing FEC response based on the incoming FEC request received from the remote link partner. The outgoing FEC response determines the FEC technology ability that will be used by the Ethernet port logic 100 in the transmit direction. The outgoing FEC response may be embodied as a two-bit value, with value '00' corresponding to acknowledging NO FEC, '01 ' corresponding to acknowledging BASE-R FEC, ' 10' corresponding to acknowledging RS-FEC, and Ί corresponding to the requested technology ability is unavailable. The outgoing FEC response may be set to match the incoming request if the technology ability of the incoming request is supported. Otherwise, the outgoing FEC response may be set to unavailable. The outgoing FEC response shall not change when it matches the incoming request.

[0073] In block 820, the Ethernet port logic 100 determines whether the local receiver is ready. For example, the Ethernet port logic 100 may examine the local_rx_ready flag. If the local receiver is not ready, the method 800 loops back to block 804 to continue building FEC requests and exchanging training frames with the remote link partner. If the local receiver is ready, the method 800 advances to block 822.

[0074] In block 822, the Ethernet port logic 100 continues to exchange training frames with the remote link partner as described above in connection with block 810. In block 822, the training frames may indicate that the Ethernet port logic 100 is ready to receive, for example by providing the value of local_rx_ready in the PMD training frame. The exchanged training frames include an outgoing FEC request, an outgoing FEC response, an incoming FEC request, and an incoming FEC response. The outgoing FEC request shall not be changed when local_rx_ready is true.

[0075] In block 824, the Ethernet port logic 100 determines whether the remote link partner is ready to receive data, that is, whether a remote_rx_ready variable is non-zero or otherwise true. The remote_rx_ready variable may be considered as zero or otherwise false when an incoming "receiver ready" value in the PMD training frame received from the remote link partner is zero (false), when the incoming FEC request is invalid or unsupported, or when the incoming FEC response is different from the outgoing FEC request (including when the incoming FEC response is "requested mode unavailable"). Therefore, the remote link partner may be ready to receive when the incoming FEC response matches the outgoing FEC request, indicating the remote link partner is capable of using the requested FEC mode.

[0076] In block 826, the Ethernet port logic 100 checks whether the remote link partner is ready to receive data. If not, the method 800 loops back to block 822 to continue exchanging training frames. If the remote link partner is ready, the method 800 advances to block 828. In block 828, the selected FEC technology ability in both transmit and receive directions may be communicated from the PMD 106 to the PCS 110 and/or FEC 108 sublayers. The selected FEC technology ability may be communicated using management variables. Thus, the Ethernet port logic 100 may activate a higher-priority FEC technology ability after autonegotiation is complete based on information exchanged during link training. In block 830, the Ethernet port logic 100 communicates data using the selected FEC mode.

EXAMPLES

[0077] Illustrative examples of the technologies disclosed herein are provided below.

An embodiment of the technologies may include any one or more, and any combination of, the examples described below.

[0078] Example 1 includes a network interface controller for forward error correction

(FEC) autonegotiation, the network interface controller including a data storage device having stored therein a plurality of instructions that, when executed by the network interface controller, causes the network interface controller to: determine a local host loss characteristic, a cable loss characteristic, and one or more local FEC technology abilities of the network interface controller, wherein the cable loss characteristic is associated with a communication channel between a local host and a remote link partner; determine one or more advertised technology abilities and an advertised host loss field based on the local host loss characteristic, the cable loss characteristic, and the local FEC technology abilities; transmit the advertised technology abilities and the advertised host loss field to the remote link partner; receive advertised remote technology abilities of the remote link partner and a remote advertised host loss field from the remote link partner; and select a highest-priority common technology ability from the advertised technology abilities and the advertised remote technology abilities. [0079] Example 2 includes the subject matter of Example 1, and wherein to transmit the advertised technology abilities and the advertised host loss field to the remote link partner comprises to: encode the advertised technology abilities and the advertised host loss field in an autonegotiation base page; and transmit the autonegotiation base page to the remote link partner.

[0080] Example 3 includes the subject matter of any of Examples 1 and 2, and wherein to transmit the advertised technology abilities and the advertised host loss field to the remote link partner comprises to: encode the advertised technology abilities and the advertised host loss field in an autonegotiation next page; and transmit the autonegotiation next page to the remote link partner.

[0081] Example 4 includes the subject matter of any of Examples 1-3, and wherein: the plurality of instructions further causes the network interface controller to determine a remote host loss characteristic associated with the remote link partner based on an assumed host loss characteristic; and wherein to determine the advertised technology abilities further comprises to determine the advertised technology abilities based on the remote host loss characteristic.

[0082] Example 5 includes the subject matter of any of Examples 1-4, and wherein the assumed host loss characteristic indicates medium loss.

[0083] Example 6 includes the subject matter of any of Examples 1-5, and wherein to determine the cable loss characteristic associated with the communication channel comprises to determine the cable loss characteristic based on an assumed cable loss, wherein the assumed cable loss indicates high loss.

[0084] Example 7 includes the subject matter of any of Examples 1-6, and wherein to determine the cable loss characteristic associated with the communication channel comprises to determine the cable loss characteristic with a cable management interface.

[0085] Example 8 includes the subject matter of any of Examples 1-7, and wherein the plurality of instructions further causes the network interface controller to: determine whether the local host loss characteristic is low loss and whether the remote advertised host loss field indicates that the remote host is low loss in response to receipt of the remote advertised host loss field; and re-determine the advertised technology abilities based on the local host characteristic, the cable loss characteristic, and the remote host loss characteristic in response to a determination that the local host loss characteristic is low loss and that the remote advertised host loss field indicates that the remote host is low loss.

[0086] Example 9 includes the subject matter of any of Examples 1-8, and wherein: the plurality of instructions further causes the network interface controller to determine whether the local host loss characteristic is low loss and whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and to transmit the advertised host loss field to the remote link partner further comprises to transmit an advertised host loss field that indicates low loss in response to a determination that the local host loss characteristic is low loss and that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[0087] Example 10 includes the subject matter of any of Examples 1-9, and wherein: the plurality of instructions further causes the network interface controller to (i) determine whether the local host loss characteristic is low loss, and (ii) determine whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; to transmit the advertised host loss field to the remote link partner comprises to transmit an advertised host loss field that indicates positive credit in response to a determination that the local host loss characteristic is low loss and a determination that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and to transmit the advertised host loss field to the remote link partner further comprises to transmit an advertised host loss field that indicates negative credit in response to a determination that the local host loss characteristic is not low loss and the determination that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[0088] Example 11 includes the subject matter of any of Examples 1-10, and wherein: to receive the remote advertised host loss field from the remote link partner comprises to receive a remote advertised host loss field that may indicate positive credit or negative credit; and the plurality of instructions further causes the network interface controller to (i) determine whether the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or whether the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, and (ii) select the higher-priority technology ability in response to a determination that the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or that the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, wherein the higher-priority technology ability has a higher priority that the highest-priority common technology ability selected from the advertised technology abilities and the advertised remote technology abilities. [0089] Example 12 includes the subject matter of any of Examples 1-11, and wherein the communication channel between the local host and the remote link partner comprises a 25- gigabit copper cable link.

[0090] Example 13 includes a network interface controller for selecting forward error correction (FEC) mode, the network interface controller including a data storage device having stored therein a plurality of instructions that, when executed by the network interface controller, causes the network interface controller to: determine an outgoing FEC request field indicative of a requested FEC technology ability; transmit the outgoing FEC request field to a remote link partner in a PMD training frame; receive an incoming FEC request field from the remote link partner in a PMD training frame; determine an outgoing FEC response field based on the incoming FEC request field; transmit the outgoing FEC response field to the remote link partner in a PMD training frame; receive an incoming FEC response field from the remote link partner in a PMD training frame; determine whether the local receiver is ready based on whether the incoming FEC request field matches the outgoing FEC response field; and determine whether the remote receiver is ready based on whether the incoming FEC response field matches the outgoing FEC request field.

[0091] Example 14 includes the subject matter of Example 13, and wherein the plurality of instructions further causes the network interface controller to select a FEC technology ability indicated by the outgoing FEC response field in response to a determination that the remote receiver is ready.

[0092] Example 15 includes the subject matter of any of Examples 13 and 14, and wherein to determine the outgoing FEC request field comprises to set the outgoing FEC request field based on a predefined technology ability of a local host.

[0093] Example 16 includes the subject matter of any of Examples 13-15, and wherein to determine the outgoing FEC request field comprises to set the outgoing FEC request field based on one or more dynamic characteristics of a communication channel that couples a local host and the remote link partner.

[0094] Example 17 includes the subject matter of any of Examples 13-16, and wherein to determine the outgoing FEC response field based on the incoming FEC request field comprises to: determine whether a technology ability indicated by the incoming FEC request is supported by the network interface controller; set the outgoing FEC response field to match the incoming FEC request field in response to a determination that the technology ability indicated by the incoming FEC request is supported by the network interface controller; and set the outgoing FEC response field to indicate unavailable in response to a determination that the technology ability indicated by the incoming FEC request is not supported by the network interface controller.

[0095] Example 18 includes a method for forward error correction (FEC) autonegotiation, the method comprising: determining, by a network port logic, a local host loss characteristic, a cable loss characteristic, and one or more local FEC technology abilities of the network port logic, wherein the cable loss characteristic is associated with a communication channel between a local host and a remote link partner; determining, by the network port logic, one or more advertised technology abilities and an advertised host loss field based on the local host loss characteristic, the cable loss characteristic, and the local FEC technology abilities; transmitting, by the network port logic, the advertised technology abilities and the advertised host loss field to the remote link partner; receiving, by the network port logic, advertised remote technology abilities of the remote link partner and a remote advertised host loss field from the remote link partner; and selecting, by the network port logic, a highest-priority common technology ability from the advertised technology abilities and the advertised remote technology abilities.

[0096] Example 19 includes the subject matter of Example 18, and wherein transmitting the advertised technology abilities and the advertised host loss field to the remote link partner comprises: encoding the advertised technology abilities and the advertised host loss field in an autonegotiation base page; and transmitting the autonegotiation base page to the remote link partner.

[0097] Example 20 includes the subject matter of any of Examples 18 and 19, and wherein transmitting the advertised technology abilities and the advertised host loss field to the remote link partner comprises: encoding the advertised technology abilities and the advertised host loss field in an autonegotiation next page; and transmitting the autonegotiation next page to the remote link partner.

[0098] Example 21 includes the subject matter of any of Examples 18-20, and further comprising: determining, by the network port logic, a remote host loss characteristic associated with the remote link partner based on an assumed host loss characteristic; wherein determining the advertised technology abilities further comprises determining the advertised technology abilities based on the remote host loss characteristic.

[0099] Example 22 includes the subject matter of any of Examples 18-21, and wherein the assumed host loss characteristic indicates medium loss.

[00100] Example 23 includes the subject matter of any of Examples 18-22, and wherein determining the cable loss characteristic associated with the communication channel comprises determining the cable loss characteristic based on an assumed cable loss, wherein the assumed cable loss indicates high loss.

[00101] Example 24 includes the subject matter of any of Examples 18-23, and wherein determining the cable loss characteristic associated with the communication channel comprises determining the cable loss characteristic using a cable management interface.

[00102] Example 25 includes the subject matter of any of Examples 18-24, and further comprising: determining, by the network port logic, whether the local host loss characteristic is low loss and whether the remote advertised host loss field indicates that the remote host is low loss in response to receiving the remote advertised host loss field; and re-determining, by the network port logic, the advertised technology abilities based on the local host characteristic, the cable loss characteristic, and the remote host loss characteristic in response to determining that the local host loss characteristic is low loss and that the remote advertised host loss field indicates that the remote host is low loss.

[00103] Example 26 includes the subject matter of any of Examples 18-25, and further comprising: determining, by the network port logic, whether the local host loss characteristic is low loss and whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; wherein transmitting the advertised host loss field to the remote link partner further comprises transmitting an advertised host loss field that indicates low loss in response to determining that the local host loss characteristic is low loss and that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[00104] Example 27 includes the subject matter of any of Examples 18-26, and further comprising: determining, by the network port logic, whether the local host loss characteristic is low loss; and determining, by the network port logic, whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; wherein transmitting the advertised host loss field to the remote link partner comprises transmitting an advertised host loss field that indicates positive credit in response to determining that the local host loss characteristic is low loss and determining that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and wherein transmitting the advertised host loss field to the remote link partner comprises transmitting an advertised host loss field that indicates negative credit in response to determining that the local host loss characteristic is not low loss and determining that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities. [00105] Example 28 includes the subject matter of any of Examples 18-27, and wherein receiving the remote advertised host loss field from the remote link partner comprises receiving a remote advertised host loss field that may indicate positive credit or negative credit, wherein the method further comprises: determining, by the network port logic, whether the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or whether the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit; and selecting, by the network port logic, the higher-priority technology ability in response to determining that the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or that the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, wherein the higher-priority technology ability has a higher priority that the highest-priority common technology ability selected from the advertised technology abilities and the advertised remote technology abilities.

[00106] Example 29 includes the subject matter of any of Examples 18-28, and wherein the communication channel between the local host and the remote link partner comprises a 25- gigabit copper cable link.

[00107] Example 30 includes a method for selecting forward error correction (FEC) mode, the method comprising: determining, by the network port logic, an outgoing FEC request field indicative of a requested FEC technology ability; transmitting, by the network port logic, the outgoing FEC request field to a remote link partner in a physical medium dependent (PMD) training frame; receiving, by the network port logic, an incoming FEC request field from the remote link partner in a PMD training frame; determining, by the network port logic, an outgoing FEC response field based on the incoming FEC request field; transmitting, by the network port logic, the outgoing FEC response field to the remote link partner in a PMD training frame; receiving, by the network port logic, an incoming FEC response field from the remote link partner in a PMD training frame; determining, by the network port logic, whether the local receiver is ready based on whether the incoming FEC request field matches the outgoing FEC response field; and determining, by the network port logic, whether the remote receiver is ready based on whether the incoming FEC response field matches the outgoing FEC request field.

[00108] Example 31 includes the subject matter of Example 30, and further comprising selecting, by the network port logic, a FEC technology ability indicated by the outgoing FEC response field in response to determining that the remote receiver is ready. [00109] Example 32 includes the subject matter of any of Examples 30 and 31, and wherein determining the outgoing FEC request field comprises setting the outgoing FEC request field based on a predefined technology ability of a local host.

[00110] Example 33 includes the subject matter of any of Examples 30-32, and wherein determining the outgoing FEC request field comprises setting the outgoing FEC request field based on one or more dynamic characteristics of a communication channel coupling a local host and the remote link partner.

[00111] Example 34 includes the subject matter of any of Examples 30-33, and wherein determining the outgoing FEC response field based on the incoming FEC request field comprises: determining whether a technology ability indicated by the incoming FEC request is supported by the network port logic; setting the outgoing FEC response field to match the incoming FEC request field in response to determining that the technology ability indicated by the incoming FEC request is supported by the network port logic; and setting the outgoing FEC response field to indicate unavailable in response to determining that the technology ability indicated by the incoming FEC request is not supported by the network port logic.

[00112] Example 35 includes a computing device comprising: a processor; and a memory having stored therein a plurality of instructions that when executed by the processor cause the computing device to perform the method of any of Examples 18-34.

[00113] Example 36 includes one or more machine readable storage media comprising a plurality of instructions stored thereon that in response to being executed result in a computing device performing the method of any of Examples 18-34.

[00114] Example 37 includes a computing device comprising means for performing the method of any of Examples 18-34.

[00115] Example 38 includes a network interface controller for forward error correction

(FEC) autonegotiation, the network interface controller comprising a network port logic to: determine a local host loss characteristic, a cable loss characteristic, and one or more local FEC technology abilities of the network interface controller, wherein the cable loss characteristic is associated with a communication channel between a local host and a remote link partner; determine one or more advertised technology abilities and an advertised host loss field based on the local host loss characteristic, the cable loss characteristic, and the local FEC technology abilities; transmit the advertised technology abilities and the advertised host loss field to the remote link partner; receive advertised remote technology abilities of the remote link partner and a remote advertised host loss field from the remote link partner; and select a highest- priority common technology ability from the advertised technology abilities and the advertised remote technology abilities.

[00116] Example 39 includes the subject matter of Example 38, and wherein to transmit the advertised technology abilities and the advertised host loss field to the remote link partner comprises to: encode the advertised technology abilities and the advertised host loss field in an autonegotiation base page; and transmit the autonegotiation base page to the remote link partner.

[00117] Example 40 includes the subject matter of any of Examples 38 and 39, and wherein to transmit the advertised technology abilities and the advertised host loss field to the remote link partner comprises to: encode the advertised technology abilities and the advertised host loss field in an autonegotiation next page; and transmit the autonegotiation next page to the remote link partner.

[00118] Example 41 includes the subject matter of any of Examples 38-40, and wherein: the network port logic is further to determine a remote host loss characteristic associated with the remote link partner based on an assumed host loss characteristic; wherein to determine the advertised technology abilities further comprises to determine the advertised technology abilities based on the remote host loss characteristic.

[00119] Example 42 includes the subject matter of any of Examples 38-41, and wherein the assumed host loss characteristic indicates medium loss.

[00120] Example 43 includes the subject matter of any of Examples 38-42, and wherein to determine the cable loss characteristic associated with the communication channel comprises to determine the cable loss characteristic based on an assumed cable loss, wherein the assumed cable loss indicates high loss.

[00121] Example 44 includes the subject matter of any of Examples 38-43, and wherein to determine the cable loss characteristic associated with the communication channel comprises to determine the cable loss characteristic with a cable management interface.

[00122] Example 45 includes the subject matter of any of Examples 38-44, and wherein the network port logic is further to: determine whether the local host loss characteristic is low loss and whether the remote advertised host loss field indicates that the remote host is low loss in response to receipt of the remote advertised host loss field; and re-determine the advertised technology abilities based on the local host characteristic, the cable loss characteristic, and the remote host loss characteristic in response to a determination that the local host loss characteristic is low loss and that the remote advertised host loss field indicates that the remote host is low loss. [00123] Example 46 includes the subject matter of any of Examples 38-45, and wherein: the network port logic is further to determine whether the local host loss characteristic is low loss and whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and to transmit the advertised host loss field to the remote link partner further comprises to transmit an advertised host loss field that indicates low loss in response to a determination that the local host loss characteristic is low loss and that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[00124] Example 47 includes the subject matter of any of Examples 38-46, and wherein: the network port logic is further to (i) determine whether the local host loss characteristic is low loss, and (ii) determine whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; to transmit the advertised host loss field to the remote link partner comprises to transmit an advertised host loss field that indicates positive credit in response to a determination that the local host loss characteristic is low loss and a determination that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and to transmit the advertised host loss field to the remote link partner further comprises to transmit an advertised host loss field that indicates negative credit in response to a determination that the local host loss characteristic is not low loss and the determination that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[00125] Example 48 includes the subject matter of any of Examples 38-47, and wherein: to receive the remote advertised host loss field from the remote link partner comprises to receive a remote advertised host loss field that may indicate positive credit or negative credit; and the network port logic is further to (i) determine whether the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or whether the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, and (ii) select the higher-priority technology ability in response to a determination that the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or that the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, wherein the higher-priority technology ability has a higher priority that the highest-priority common technology ability selected from the advertised technology abilities and the advertised remote technology abilities. [00126] Example 49 includes the subject matter of any of Examples 38-48, and wherein the communication channel between the local host and the remote link partner comprises a 25- gigabit copper cable link.

[00127] Example 50 includes a network interface controller for selecting forward error correction (FEC) mode, the network interface controller comprising a network port logic to: determine an outgoing FEC request field indicative of a requested FEC technology ability; transmit the outgoing FEC request field to a remote link partner in a PMD training frame; receive an incoming FEC request field from the remote link partner in a PMD training frame; determine an outgoing FEC response field based on the incoming FEC request field; transmit the outgoing FEC response field to the remote link partner in a PMD training frame; receive an incoming FEC response field from the remote link partner in a PMD training frame; determine whether the local receiver is ready based on whether the incoming FEC request field matches the outgoing FEC response field; and determine whether the remote receiver is ready based on whether the incoming FEC response field matches the outgoing FEC request field.

[00128] Example 51 includes the subject matter of Example 50, and wherein the network port logic is further to select a FEC technology ability indicated by the outgoing FEC response field in response to a determination that the remote receiver is ready.

[00129] Example 52 includes the subject matter of any of Examples 50 and 51, and wherein to determine the outgoing FEC request field comprises to set the outgoing FEC request field based on a predefined technology ability of a local host.

[00130] Example 53 includes the subject matter of any of Examples 50-52, and wherein to determine the outgoing FEC request field comprises to set the outgoing FEC request field based on one or more dynamic characteristics of a communication channel that couples a local host and the remote link partner.

[00131] Example 54 includes the subject matter of any of Examples 50-53, and wherein to determine the outgoing FEC response field based on the incoming FEC request field comprises to: determine whether a technology ability indicated by the incoming FEC request is supported by the network interface controller; set the outgoing FEC response field to match the incoming FEC request field in response to a determination that the technology ability indicated by the incoming FEC request is supported by the network interface controller; and set the outgoing FEC response field to indicate unavailable in response to a determination that the technology ability indicated by the incoming FEC request is not supported by the network interface controller. [00132] Example 55 includes a network interface controller for forward error correction

(FEC) autonegotiation, the network interface controller comprising: means for determining a local host loss characteristic, a cable loss characteristic, and one or more local FEC technology abilities of the network port logic, wherein the cable loss characteristic is associated with a communication channel between a local host and a remote link partner; means for determining one or more advertised technology abilities and an advertised host loss field based on the local host loss characteristic, the cable loss characteristic, and the local FEC technology abilities; means for transmitting the advertised technology abilities and the advertised host loss field to the remote link partner; means for receiving advertised remote technology abilities of the remote link partner and a remote advertised host loss field from the remote link partner; and means for selecting a highest-priority common technology ability from the advertised technology abilities and the advertised remote technology abilities.

[00133] Example 56 includes the subject matter of Example 55, and wherein the means for transmitting the advertised technology abilities and the advertised host loss field to the remote link partner comprises: means for encoding the advertised technology abilities and the advertised host loss field in an autonegotiation base page; and means for transmitting the autonegotiation base page to the remote link partner.

[00134] Example 57 includes the subject matter of any of Examples 55 and 56, and wherein the means for transmitting the advertised technology abilities and the advertised host loss field to the remote link partner comprises: means for encoding the advertised technology abilities and the advertised host loss field in an autonegotiation next page; and means for transmitting the autonegotiation next page to the remote link partner.

[00135] Example 58 includes the subject matter of any of Examples 55-57, and further comprising: means for determining a remote host loss characteristic associated with the remote link partner based on an assumed host loss characteristic; wherein the means for determining the advertised technology abilities further comprises means for determining the advertised technology abilities based on the remote host loss characteristic.

[00136] Example 59 includes the subject matter of any of Examples 55-58, and wherein the assumed host loss characteristic indicates medium loss.

[00137] Example 60 includes the subject matter of any of Examples 55-59, and wherein the means for determining the cable loss characteristic associated with the communication channel comprises means for determining the cable loss characteristic based on an assumed cable loss, wherein the assumed cable loss indicates high loss. [00138] Example 61 includes the subject matter of any of Examples 55-60, and wherein the means for determining the cable loss characteristic associated with the communication channel comprises means for determining the cable loss characteristic using a cable management interface.

[00139] Example 62 includes the subject matter of any of Examples 55-61, and further comprising: means for determining whether the local host loss characteristic is low loss and whether the remote advertised host loss field indicates that the remote host is low loss in response to receiving the remote advertised host loss field; and means for re-determining the advertised technology abilities based on the local host characteristic, the cable loss characteristic, and the remote host loss characteristic in response to determining that the local host loss characteristic is low loss and that the remote advertised host loss field indicates that the remote host is low loss.

[00140] Example 63 includes the subject matter of any of Examples 55-62, and further comprising: means for determining whether the local host loss characteristic is low loss and whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; wherein the means for transmitting the advertised host loss field to the remote link partner further comprises means for transmitting an advertised host loss field that indicates low loss in response to determining that the local host loss characteristic is low loss and that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities.

[00141] Example 64 includes the subject matter of any of Examples 55-63, and further comprising: means for determining whether the local host loss characteristic is low loss; and means for determining whether the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; wherein the means for transmitting the advertised host loss field to the remote link partner comprises means for transmitting an advertised host loss field that indicates positive credit in response to determining that the local host loss characteristic is low loss and determining that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities; and wherein the means for transmitting the advertised host loss field to the remote link partner comprises means for transmitting an advertised host loss field that indicates negative credit in response to determining that the local host loss characteristic is not low loss and determining that the local FEC technology abilities include a higher-priority technology ability than the advertised technology abilities. [00142] Example 65 includes the subject matter of any of Examples 55-64, and wherein the means for receiving the remote advertised host loss field from the remote link partner comprises means for receiving a remote advertised host loss field that may indicate positive credit or negative credit, wherein the network interface controller further comprises: means for determining whether the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or whether the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit; and means for selecting the higher-priority technology ability in response to determining that the advertised host loss field indicates positive credit and the remote advertised host loss field indicates negative credit or that the advertised host loss field indicates negative credit and the remote advertised host loss field indicates positive credit, wherein the higher-priority technology ability has a higher priority that the highest-priority common technology ability selected from the advertised technology abilities and the advertised remote technology abilities.

[00143] Example 66 includes the subject matter of any of Examples 55-65, and wherein the communication channel between the local host and the remote link partner comprises a 25- gigabit copper cable link.

[00144] Example 67 includes a network interface controller for selecting forward error correction (FEC) mode, the network interface controller comprising: means for determining an outgoing FEC request field indicative of a requested FEC technology ability; means for transmitting the outgoing FEC request field to a remote link partner in a physical medium dependent (PMD) training frame; means for receiving an incoming FEC request field from the remote link partner in a PMD training frame; means for determining an outgoing FEC response field based on the incoming FEC request field; means for transmitting the outgoing FEC response field to the remote link partner in a PMD training frame; means for receiving an incoming FEC response field from the remote link partner in a PMD training frame; means for determining whether the local receiver is ready based on whether the incoming FEC request field matches the outgoing FEC response field; and means for determining whether the remote receiver is ready based on whether the incoming FEC response field matches the outgoing FEC request field.

[00145] Example 68 includes the subject matter of Example 67, and further comprising means for selecting a FEC technology ability indicated by the outgoing FEC response field in response to determining that the remote receiver is ready. [00146] Example 69 includes the subject matter of any of Examples 67 and 68, and wherein the means for determining the outgoing FEC request field comprises means for setting the outgoing FEC request field based on a predefined technology ability of a local host.

[00147] Example 70 includes the subject matter of any of Examples 67-69, and wherein the means for determining the outgoing FEC request field comprises means for setting the outgoing FEC request field based on one or more dynamic characteristics of a communication channel coupling a local host and the remote link partner.

[00148] Example 71 includes the subject matter of any of Examples 67-70, and wherein the means for determining the outgoing FEC response field based on the incoming FEC request field comprises: means for determining whether a technology ability indicated by the incoming FEC request is supported by the network port logic; means for setting the outgoing FEC response field to match the incoming FEC request field in response to determining that the technology ability indicated by the incoming FEC request is supported by the network port logic; and means for setting the outgoing FEC response field to indicate unavailable in response to determining that the technology ability indicated by the incoming FEC request is not supported by the network port logic.