"Turn" support and implementation of Linux network card driver for Ethtool

One notable feature of Linux is its powerful network capabilities, which support almost all network protocols and provide a wealth of applications based on these protocols. The importance of Linux network management is self-evident, these management relies on network tools, such as the most commonly used Ifconfig,route,ip,ethtool, which Ethtool provides a powerful network card and network card driver management capabilities, Its concrete implementation framework and network driver and network hardware are closely related, easy to modify and expand, can provide Linux network developers and managers with network card hardware, drivers and networking protocol stack settings, view and debugging functions. Speaking from a typical Ethernet controller

The network card works in the last two layers of the OSI network system, the physical layer and the data link layer, which defines the electrical and optical signals, line States, clock benchmarks, data encoding, and circuitry needed for data transmission and reception, and provides a standard interface to the data link layer devices. The physical layer of the chip is called PHY. The data link layer provides the functions of addressing mechanism, data frame construction, data error checking, Transmission control, and providing standard data interface to the network layer. The chip of the data link layer in the Ethernet card is called the MAC controller. Many of these two parts of the NIC are done together. Their relationship is the PCI bus connected to the Mac bus, Mac connected to the Phy,phy network cable (of course, is not directly connected, there is a pressure swing device).

Generally, the basic structure of a typical Ethernet controller is shown in 1:

Figure 1. A typical Ethernet controller architecture that conforms to the IEEE802.3 standard

The data-link-layer MAC is the abbreviation for media access control, which is the sub-layer protocol for medium-to-child. The protocol is located in the lower half of the data link layer in the OSI Seven layer protocol, and is primarily responsible for controlling and connecting physical media to the physical layer. When the data is sent, the MAC protocol can determine in advance whether the data can be sent, if it can be sent to the data with some control information, and finally the data and control information in the specified format sent to the physical layer, when the data is received, the MAC protocol first to determine the information entered and whether transmission error occurred, If there is no error, the control information is removed and sent to the LLC layer. Ethernet MAC is defined by the IEEE-802.3 Ethernet standard.

The physical layer PHY is a physical interface transceiver that implements the physical layer. Includes MII/GMII (media Independent interface) sub-layer, PCS (physically encoded sub-layer), PMA (physical media attached) sub-layer, PMD (physical medium dependent) child layer, MDI child layer.

MII is a media-independent interface, and media independence indicates that any type of PHY device can work correctly without the redesign or replacement of MAC hardware. Includes two separate channels for transmitters and receivers, respectively. Each channel has its own data, clock, and control signals. The MII data interface requires a total of 16 signals, including TX_ER,TXD<3:0>,TX_EN,TX_CLK,COL,RXD<3:0>,RX_EX,RX_CLK,CRS,RX_DV.

RMII (reduced Media independant Interface) is a simplified MII interface that has a signal line less than the MII interface for data transmission, so it typically requires a 50-gigabit bus clock. RMII is generally used in multi-port switch, it is not each port to arrange to collect, send two clock, but all the data port common one clock for all the port transceiver, here save a lot of port number. One port on the RMII requires 7 data lines, one times less than MII, so the switch can access more than one data port. Like MII, the RMII supports 10-gigabit and 100-Gigabit bus interface speeds.

GMII (Gigabit mii) is the MII interface of the gigabit network, which also has a corresponding RGMII interface, which represents a simplified GMII interface. The GMII uses 8-bit interface data with a working clock of 125MHz, so the transfer rate can be up to 1000Mbps. Compatible with the 10/100 Mbps operating mode as defined by MII.

The MII management interface is a two-signal interface, one for the clock signal MDC and the other for the data signal MDIO. Through the management interface, the upper layer can monitor and control the PHY registers. Some of the registers in the PHY are defined by IEEE, so that PHY reflects its current state into the register, and the MAC continuously reads the state register of the PHY through the management interface to know the current PHY state, such as the connection speed, the ability to duplex, etc. Of course, it is also possible to set the PHY register through the management interface for control purposes, such as open shutdown of the flow control, self-negotiation mode or forced mode, etc., which is how Ethtool works.

MDIO/MDC, the PHY management interface serial communication bus, which is defined by the IEEE through several terms of the Ethernet standard IEEE 802.3. The MDIO is a simple two-wire serial interface that controls the transceiver and collects status information from the transceiver by connecting the management device (such as a MAC controller, microprocessor) to a management-capable transceiver such as a multiport Gigabit Ethernet transceiver or a 10GbE XAUI transceiver. The information can be collected including link status, transmission speed and selection, power outage, low power sleep state, Tx/rx mode selection, auto-negotiation control, loopback mode control, etc. In addition to the capabilities required by the IEEE, transceiver vendors can add more information-gathering capabilities.

The MDC is the clock input that manages the data, up to a maximum rate of 8.3MHz. The MDIO is an input-output bidirectional interface for managing data that is synchronized with the MDC clock. The MDIO workflow is:

• The MDIO interface is MDIO in a high impedance state in an idle (idle) data cable that does not transmit data.
• MDIO appears with a 2bit start identifier (01) A read/write operation begins.
• MDIO a 2bit data is present to identify whether it is a read operation (10) or a write operation (01).
• MDIO appears with an address of 5bit data ID PHY.
• MDIO a 5bitPHY register address appears.
• The MDIO requires 2 clock access time.
• MDIO Serial read/write 16bit register data.
• The MDIO reverts to the idle state while the MDIO enters a high-impedance state.

Note: The above content is selected from the Internet.

Support for Ethtool in Linux device drivers

Currently, almost all network card drivers have support for Ethtool, as shown in frame 2, the Ethtool framework contains both kernel space and user space: part of the user space is responsible for sending the Ethtool command to the kernel and receiving the execution result of the command, and the kernel space is partially based on the corresponding command word. Through the MDIO/MDC read and write MII register, the network card management, and the implementation of the results back to user space. Because the Linux network driver is a complex and large system, it only introduces the definition of the MII registers in the driver, the support for MDIO/MDC, and how to implement the Ethtool functional part in the driver.

Figure 2.ethtool Implementation Framework in Linux

MII registers as mandated by IEEE 802.3

About the Mii/gmii interface PHY Register is defined in the 802.3 22.2.4 Management functions. section, such as Table 22–6 and table 22–7 in this section (that is, figure 3 and Figure 4 of this article, are derived from Http://standards.ieee.org/getieee802/download/802.3-2008_section2. PDF) as shown in

Figure 3. IEEE802.3 defined MII Management Register set

You can see that the registers are divided into basic sets and extension sets, and the definition of the base set varies by GMII and Mii, and for Mii, the basic set includes the Register 0 control Register and the 1 status register, and for GMII; the base set includes registers 0, 1, and 15. The control register 0 and the status Register 1 of the definition 3 are as follows:

Figure 4. IEEE802.3-defined Register 0 control register and 1 status register

Figure 4. IEEE802.3-defined Register 0 control register and 1 status register

The reading and writing of registers 0 and 1 allows for the management of the NIC, and listing 1 lists the definitions of some PHY management registers and the individual bits of the control register and the status register.

Listing 1,/kernel/drivers/net/mii.h, defining PHY management Registers

 #define MII_BMCR 0x00/* Basic Mode control register */#define MII_BMSR 0x01/* Bas IC Mode Status Register */#define MII_PHYSID1 0x02/* PHYS ID 1 */#define MII_PHYSID 2 0x03/* PHYS ID 2 */#define MII_ADVERTISE 0x04/* Advertisement control        Reg */#define MII_LPA 0x05/* Link Partner Ability Reg */#define Mii_expansion 0x06 /* Expansion Register */#define MII_CTRL1000 0x09/* 1000base-t control */...//* B ASIC mode control register. */#define BMCR_RESV 0x003f/* Unused ... */#define BMCR_SPEED1000 0x0040 * MSB of S           Peed (+)/#define BMCR_CTST 0x0080/* Collision Test */#define BMCR_FULLDPLX 0X0100/* Full Duplex */#define BMCR_ANRESTART 0x0200/* Auto negotiation RestarT */#define BMCR_ISOLATE 0x0400 */Disconnect DP83840 from MII */#define Bmcr_pdown 0x0800 /* Powerdown the DP83840 */#define BMCR_ANENABLE 0x1000/* Enable Auto Negotiation */#define BM cr_speed100 0x2000/* Select 100Mbps */#define BMCR_LOOPBACK 0x4000/* TXD LOOPBACK B its */#define BMCR_RESET 0x8000/* RESET the DP83840 */* Basic mode status register . */#define BMSR_ERCAP 0x0001/* EXT-REG capability */#define BMSR_JCD 0x0002/* Jabber detected */#define BMSR_LSTATUS 0x0004/* Link status */#define Bmsr_an Egcapable 0x0008/* Able to do auto-negotiation */#define BMSR_RFAULT 0x0010/* Remote fault Detect Ed */#define BMSR_ANEGCOMPLETE 0x0020/* auto-negotiation complete */#define BMSR_RESV 0x    00C0/* Unused ...               */#define Bmsr_estaten 0x0100/* Extended Status in R15 */#define BMSR_100FULL2 0x0200/* Can do 10 0BASE-T2 HDX */#define BMSR_100HALF2 0x0400/* Can do 100base-t2 FDX */#define BMSR_10HALF 0x0800/* Ca n Do 10mbps, Half-duplex */#define BMSR_10FULL 0x1000/* Can do 10mbps, Full-duplex */#define Bmsr_100h ALF 0x2000/* Can do 100mbps, Half-duplex */#define BMSR_100FULL 0x4000/* Can do 100mbps, full- Duplex */#define BMSR_100BASE4 0x8000/* Can do 100mbps, 4k packets */

Implementation of the Mdc/mdio read-write MII register

In the earlier part of this article described the Mdc/mdio workflow, the NIC driver MDIO read and write functions Mdio_read and mdio_write, that is, the function pointer in Listing 3 is done in the driver files of each network card, all comply with IEEE802.3 M The frame format of the DIO. The typical frame format is the format defined in section 22nd:

Figure 5.ieee802.3 the MDIO frame format defined in clause 22

Domain	length (bit)	Description
St	2bits	01b
OP	2bits	Operation code, written as 01b, read as 10b
Phyadr	5bits	PHY ID
Regadr	5bits	Register Address
Ta	2 bits	State transition domain, read operation is x0b, write operation is 10b
DATA	+ Bits	Data

Implementing Ethtool functionality in the driver

In kernel/include/linux/ethtool.h defines the structure of the ethtool_ops, all members of the struct is a function pointer type, defines the function that the Ethtool can implement, the struct member variable is many, here does not list the code list At the same time, there are member variables ethtool_ops in the struct net_device as shown in Listing 2.

Listing 2,kernel/include/linux/netdevice.h, member variable ethtool_ops in Net_device

struct Net_device  {  ...  const struct Ethtool_ops *ethtool_ops;  ...  }

The NIC driver needs to initialize the Ethtool_ops and implement its defined function functions to enable ethtool support, taking dm9000.c as an example.

Checklist 3,kernel/drivers/net/dm9000.c,dm9000 Driver Support for Ethtool

static const struct Ethtool_ops dm9000_ethtool_ops = {  . get_drvinfo  = Dm9000_get_drvinfo,  . get_settings= Dm9000_get_settings,  . set_settings  = dm9000_set_settings,  . Get_msglevel  = Dm9000_get_msglevel,  . Set_msglevel  = Dm9000_set_msglevel,  . nway_reset= dm9000_nway_reset,  . Get_link  = dm9000_ Get_link,.   Get_eeprom_len  = Dm9000_get_eeprom_len,   . Get_eeprom  = Dm9000_get_eeprom,  . Set_eeprom= Dm9000_set_eeprom,  . get_rx_csum= dm9000_get_rx_csum,  . set_rx_csum= Dm9000_set_rx_csum,  . get_tx_csum= ethtool_op_get_tx_csum,  . set_tx_csum= dm9000_set_tx_csum,  };  ...  Ndev->ethtool_ops  = &dm9000_ethtool_ops;  ...

The functions in Listing 3 are implemented in the DM9000 driver, for example, if you need to see the connection of the current network, it can be obtained by dm9000_get_link, and the specific implementation of the function is shown in Listing 4:

List 4,dm9000_get_link

Static u32 dm9000_get_link (struct net_device *dev)  {  board_info_t *dm = To_dm9000_board (dev);  U32 ret;  if (Dm->flags & dm9000_platf_ext_phy)  ret = MII_LINK_OK (&dm->mii);  else  ret = dm9000_read_locked (DM, DM9000_NSR) & Nsr_linkst? 1:0;  return ret;  }  KERNEL/DRIVERS/NET/MII.C  int Mii_link_ok (struct mii_if_info *mii)  {/  * First, a dummy read, needed to LAT CH some MII phys *  /Mii->mdio_read (Mii->dev, mii->phy_id, MII_BMSR);  if (Mii->mdio_read (Mii->dev, mii->phy_id, MII_BMSR) & Bmsr_lstatus)  return 1;  return 0;  }

You can see the final implementation or read the PHY register from MDIO/MDC.

In addition to the command to manage the NIC, Ethtool also has other extended functions, the Ethtool framework is very conducive to the expansion of new features, developers can be in this framework to add their own desired functionality to implement other functions in addition to network card management, in fact, now the Ethtool has provided some other functions, such as to implement the network card Firmware brush write and update, the control of the Web driver log, these new features for debugging programs, correcting errors is very advantageous.

Listing 5, section Ethtool extension features: Firmware update and modify log levels

Ethtool-f|--flash devname   FILENAME  ethtool-s|--change devname  msglvl%d

Back to top of page

Configuring and managing network cards using Ethtool

The previous section focuses on the basics and methods of ethtool implementation, and this section focuses on some of the uses of Ethtool, focusing on ethtool usage in configuring and managing network cards.

The best way to understand ethtool usage is to look at Ethtool's help information "ethtool-h" or "Man Ethtool", which is not listed here because of the many helpful information, and will be replaced by examples of practical applications.

Example 1, using Ethtool to view the information of the NIC interface Eth4

Listing 6, viewing the interface information for the NIC

[Email protected]:~# ethtool eth4  Settings for ETH4:         supported ports: [TP]         supported link modes:   10base T/half 10baset/full                                 100baset/half 100baset/full                                 1000baset/full         Supports auto-negotiation:yes         Advertised link modes:  10baset/half 10baset/full                                 100baset/half         100baset/full 1000baset/full Advertised Auto-negotiation:yes         speed:100mb/s         duplex:full         port:twisted Pair         phyad:1         Transceiver:internal         auto-negotiation:on         Supports wake-on:g         wake-on:g         Link detected:yes

Instance 2, turn off auto-negotiation of the NIC and view the results of the modification.

Listing 7, turn off auto-negotiation of the NIC and view the results of the changes

[Email protected]:~# ethtool-s eth4 Autoneg off  [email protected]:~# ethtool eth4  Settings for Eth4:  support Ed ports: [TP]  supported link modes:   10baset/half 10baset/full 100baset/half                         100baset/full                         1000baseT /full  Supports auto-negotiation:yes  advertised link modes: Not  reported  advertised Auto-negotiation:no  speed:100mb/s  duplex:full  port:twisted Pair  phyad:1  Transceiver: Internal  auto-negotiation:off  Supports wake-on:g  wake-on:g  Link detected:yes

Instance 3, turn off auto-negotiation of the NIC and modify the network card rate to 10MB/S

Listing 8, turn off auto-negotiation of the NIC and modify the network card rate to 10MB/S

[Email protected]:~# ethtool-s eth4 autoneg off Speed [E-  mail protected]:~# ethtool eth4  Settings for eth4:
   
    supported ports: [TP]         supported link modes:   10baset/half 10baset/full                                 100baset/half 100baset/full 1000baset/full         Supports auto-negotiation:yes         advertised link modes: Not  reported         advertised Auto-negotiation:no         speed:10mb/s         duplex:full         port:twisted Pair         phyad:1         Transceiver: Internal         auto-negotiation:off         Supports wake-on:g         wake-on:g         Link detected:yes
   

Other functions of Ethtool can be implemented according to the syntax of their help information, which is not listed here.

Back to top of page

Extended Ethtool

According to some characteristics of the NIC, you can extend the Ethtool to complete the support of the special function of the network card, a typical extension application is to increase the ethtool to sideband support function, about sideband introduction can refer to the IBM developerWorks "talking about NCSI and its implementation on Linux

》。 Figure 6 is a block diagram of the functions of sideband Select_channel,enable_channel and disable_channel by adding custom cmd and corresponding implementation functions. Take Select_channel as an example, can be achieved by the following steps.

Figure 6, extending the sideband management capabilities of Ethtool

1. Ethtool Add command Word ethtool_selchannel in both user space and kernel space;
2. Add the execution function ethtool_select_channel corresponding to Ethtool_selchannel in Ethtool.ops;
3. Implement the Ethtool_select_channel () function in the Dev_ethtool function, the function of which is to use the packet sending interface of the protocol stack to send the wrapped NCSI Command protocol package to the MAC layer of the NIC, and accept the corresponding response, similar to the Ethtoo L_enable_channel (), Ethtool_disable_channel can be extended according to the same method, it can be seen that the Ethtool framework is very extensible, it is helpful for developers to tailor the actual needs.

Back to top of page

Summarize

Ethtool is a powerful network management tool under Linux, this paper first introduces the implementation principle and method of this tool, mainly introduces the MII Management register and MDIO/MDC standard in IEEE802.3.22 and the Ethtool in Linux network driver. Support, then the example illustrates the method of using this tool to manage the network card, and finally introduces an example of extending sideband management on the Ethtool framework, which can be used as a reference for developers.

"Turn" support and implementation of Linux network card driver for Ethtool