Virtual Device
Virtual Devices are abstracted based on one or more real devices. The correspondence between virtual devices and real devices can be one-to-one, one-to-many, and multiple-to-one, virtual devices may be created on top of other virtual devices. But not all combinations make sense, and not all combinations have Kernel support.
The usage of virtual devices is as follows:
- Bonding: a set of real devices are virtualized into a virtual device, making it like a single device to improve performance;
- 802.1Q: This is a VLAN standard. The VLAN header is used to expand the 802.3/Ethernet frame header and create a VLAN;
- Bridding: The Bridge interface is the virtual device of the bridge.
- Aliasing interface: allows a real Ethernet interface to have multiple virtual interfaces (such as eth0: 0 eth0: 1). Each interface has its own IP Address Configuration. Now, to improve the network code, you do not need to define a new Virtual Interface When configuring multiple IP addresses on the same Nic device.
- Normal balancer (true equalizer, teql): This is a queue rule for traffic control.
- Tunnel interface (Tunnel Interface): the IP over IP tunnel has been implemented based on the GRE (General Routing Encapsulation) protocol.
Interaction Between Virtual Devices and kernel network protocol stacks
The interaction between virtual devices and real devices and the kernel is slightly different:
- Initialization: Most virtual devices, like real devices, are assigned a net_device data structure, but not all virtual devices are assigned a net_device instance, the alias device is implemented only as a simple tag on the associated real device.
- Configuration: Most virtual devices need to provide special user space tools for configuration, especially for high-level fields of Virtual Devices. Standard tools such as ifconfig cannot be used for configuration.
- External interface: each virtual device usually outputs a file or directory containing some files to the/proc file system. files related to the virtual device are additional files, it does not replace files related to physical devices. That is to say, Virtual Devices generate their own/proc files, but they do not have their own net_device instance aliases. This is an exception.
- Transmission: When the virtual device and the real device are not one-to-one, the function used for transmission may need to select the real device and other tasks used, qoS is applied according to the needs of each device. When there are multiple relationships between virtual devices and real devices, traffic control must be configured.
- Receiving: Virtual Devices are software objects and do not need to interact with real resources on the system, such as registering IRQ and allocating I/O Ports and I/O memory. Therefore, different types of Virtual Devices have different behaviors when receiving data packets.
- External notification information: the logic of a virtual device is based on a real device. A real device has no knowledge of this logic and thus cannot pass the notification information. The notification information must directly face Virtual Devices. For example, if a device in the bound device group goes down, the algorithm used to allocate traffic must be able to detect this situation, in order to avoid subsequent traffic distribution to the down device. Different from software implementation triggering information, hardware triggering information, such as PCI power management, cannot directly reach the virtual device because there is no hardware related to the virtual device.
Configuration files related to network initialization in the proc file system
Some files in/proc output the internal data structure and configuration parameter values, used to record the resources and status allocated by the device driver. For example, the lsmod command uses the proc/modules file as the information source to output the loaded modules and dependencies in the current system.
In the/proc/NET directory, there is a file created by the device processing layer initialization function net_dev_init through dev_proc_init and dev_mcast_init:
Dev file: contains statistics about the receipt and transmission of each network device registered to the kernel:
Dev_mcast file: displays the parameter values used for IP multicast of each network device registered to the kernel.
Wireless: similar to the dev file, it outputs some parameter values of Dev-> get_wireless_stats for each wireless device. These values only apply to wireless devices, because wireless devices allocate a Data Structure to store these statistics.
Softnet_stat: outputs statistics on software interruptions used by network subsystems
Functions related to system initialization
Request_irq allocates IRQ lines and registers the Interrupt Processing Routine callback function. You can register exclusive or shared disconnection.
Free_irq cancels the callback function of the interrupt processing routine. If no device can use this function again, the disconnected resource will be released.
Request_region allocates I/O Ports and I/O memory
Release_region releases the I/O port and I/O memory
Call_usermodehelper calls the user space auxiliary Application
Module_param module configuration parameters
Net_dev_init initializes a piece of network code during system boot.
Global Variables
Dev_boot_phase Boolean ID. To force the NIC device to execute net_dev_init before the driver registration
Data Structure
Struct irq_action: defines the structure of each IRQ line instance, including a callback function.
Net_device describes a network device.