MII and miI-Tool

In Linux, if you run the ifconfig XYZ command, you will get a lot of information, but there is no such information as the speed and duplex status of the XYZ network interface. Is this reasonable? If you are familiar with windows, you will feel that the output of this command is indeed missing, but can windows ipconfig get this information? No. The speed duplex information of the Windows Nic is displayed after you select a specific Nic in "Control Panel-> network connection" and double-click it, to view the duplex information, you must click "properties", click "configuration" next to the top Nic name, and then click the "advanced" tab. Then, find the information slowly, which looks messy, in fact, it is also very confusing. Is the speed/Duplex information the Configuration Attribute of the NIC or the inbing attribute? The attributes under the local connection status include the inner Bing attribute and the Configuration Attribute of the NIC. The inner Bing attribute can be understood as the link layer and the physical layer attribute, the Configuration Attribute can be understood as the network layer attribute, which looks reasonable. In this case, the ifconfig output in Linux is a bit messy, including both the physical address information of the NIC, IP address information, and other information, indeed, ifconfig in Linux is a bit messy. If you configure multiple IP addresses on a network card, you cannot use the ifconfig command, but you can only see the last configured master IP address, therefore, the ifconfig command output is not very reasonable. If you want more reasonable output, use the ip command. I think the ifconfig command is a hodgedge. It is almost omnipotent, but it is extremely difficult to use. Now the problem is very clear, that is, setting the NIC speed and duplex mode, how can I set ifconfig? The funny thing is that although ifconfig does not display these messages that match the MAC address of the NIC by default, they can be set, for example, using the media option, the parameters are 10base2, 10 BaseT, AuI, and so on. Unlike simply clicking the NIC configuration in windows, click the Advanced tab, and then you can set these parameters as needed. Ifconfig in Linux is not suitable for setting these parameters, but it has a powerful tool to do everything. This is miI-tool and ethtool, which are not distinguished here, they implement similar functions.
The full name of MII is media independent interface, which is literally a media-independent interface. Therefore, it is independent from a specific device. Think carefully about the standard items, which are independent from specific devices. However, many Ethernet Card devices do not support the configuration of these parameters. Therefore, when you execute the MII-tool, you will receive the operation not supported prompt, which is reasonable, because these parameter settings are extremely functional, not in the software sense, but in the hardware sense, if there are no related registers on the NIC, in other words, the NIC is not smart enough to support the automatic negotiation duplex mode, how do you set the duplex mode, or how can you make two people spend the same time? In fact, features such as setting the duplex mode are not necessary. Therefore, if the hardware is not implemented for the software, you do not have to simulate it using soft algorithms. For upper-layer applications, the underlying duplex mode and speed are completely transparent. These concepts are only functional, not interface. Not all interfaces allow you to set the rate and duplex mode at will. We can think that MII is a self-negotiation mechanism set up by some smart high-speed Ethernet cards to be compatible with each other or to be compatible with the weak.
Don't be frightened by the Code mentioned above to think how complicated the MII-tool code is. In fact, it is very simple. A large share of the tool's source code is dealing with user options and combining these options, there is no other logic. In the final configuration, I is an ioctl, and the kernel uses VFS to route the ioctl to the final device. If the device does not support MII, then, an "unsupported" error is directly returned, and then the error is returned, in the ioctl framework of the kernel source code itself, there is a siocethtool flag to directly support configuration through negotiation such as rate and duplex modes, specifically, the device simply performs read and write operations on specific registers, which is very simple. In this case, you should not expect to find the fields about these parameters in the net_device struct of the kernel source code. They cannot be in this abstract and important struct, after all, many network devices do not have these concepts, so they should be best positioned in the private field of net_device. I mean they are not necessarily in PRI in private. The structure represented by vate may also be hidden in the contained struct of a more concealed struct. It makes no sense to discuss this.
Do drivers like virtual NICs need to implement these configurations? There is no need at all, because the incoming and outgoing data of the virtual network card is not running on the "line" at all, since there is no real "line", these line configurations are of course unnecessary. In fact, both speed and duplex modes are about the line configuration, speed and mode, and the conductivity of the line medium, there is a correlation between signal attenuation rate and anti-interference coefficient. Is it meaningful to set these settings for the virtual NIC that comes in and out of the local machine? I reiterate that these things are not in the sense of "interface", but in the sense of functional configuration, and they are not required for standardization, they exist only to make the physical layer more efficient. They are completely separated from the above N layers after calling the interface.

In openvpn, there is an important parameter -- txqueuelen n. It can be understood as a speed, but it is not a line rate but related to interface sending. The net_device in the kernel has a tx_queue_len field, indicates the number of data packets that can be accumulated in the sending queue before sending. If the value is too small, the data will be dropped if the application layer sends too fast, which is also worth noting. Take the Linux Tun device as an example. tun_net_xmit contains the following code snippet:
If (! (Tun-> flags & tun_one_queue )){
If (skb_queue_len (& Tun-> readq)> = tun_readq_size)
Netif_stop_queue (Dev );
} Else {
If (skb_queue_len (& Tun-> readq)> = Dev-> tx_queue_len)
Goto drop;
}
Skb_queue_tail (& Tun-> readq, SKB );