Packet receiving method, packet sending method and forwarding model architecture of kernel protocol stack of operating system

Abstract

The embodiment of the invention provides a packet receiving method, a packet sending method and a forwarding model architecture of an operating system kernel protocol stack. The method is applied to a switch, the switch comprises a Linux kernel and a switch chip, and the method comprises the following steps: acquiring an initial request data packet and a network identifier through the switch chip; the initial request data packet is processed according to the network identifier through a network equipment driving module of the Linux kernel, a first tunnel message is obtained, the first tunnel message is provided with a virtualization tunnel head, the virtualization tunnel head comprises the network identifier, and a destination address in the virtualization tunnel head is an interface address of a VXLAN driving module of the Linux kernel; decapsulating a virtualized tunnel head of the first tunnel message through a VXLAN driving module to obtain a target request data packet; and sending the target request data packet to a protocol stack of the Linux kernel through a virtual extensible local area network corresponding to the network identifier. Through adoption of the method, directional transmission of the data packet in the virtualization environment can be ensured, and the packet receiving efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method for receiving packets, a method for sending packets, and a forwarding model architecture for an operating system kernel protocol stack. Background Technology

[0002] Currently, kernel-based VXLAN (Virtual Extensible LAN) packet sending and receiving solutions include: Figure 1 As shown, the kernel layer's left underlay network handles the forwarding process for VLAN FIF ports, while the right underlay network handles the forwarding process for Layer 3 ports. The VXLAN (Virtual Extensible LAN) forwarding table is implemented in software by the kernel-level VXLAN module. The following explanation uses the underlay network as the VLAN FIF port to illustrate the current kernel implementation: When a VXLAN packet enters the switch through the underlay network, it is sent to the kernel protocol stack via the GE port and reaches the bridge. The bridge then forwards the packet to the corresponding VLAN FIF port. The packet then tunnels through a UDP tunnel to the VXLAN interface. The VXLAN interface detunes the packet to obtain the original packet, sends it back to the protocol stack, looks up the interface, and sends it to the corresponding outgoing interface. Therefore, access devices in the VXLAN network cannot directly connect to virtual terminal devices for communication. The forwarding table is implemented purely in software by the kernel module, resulting in poor lookup and forwarding performance. Summary of the Invention

[0003] In view of this, embodiments of this application propose a method, apparatus, electronic device, and storage medium for receiving packets in an operating system kernel protocol stack, which can solve the problem of the inability to forward packets when the device is directly connected to a virtual terminal, thereby improving forwarding performance.

[0004] In a first aspect, embodiments of this application provide a method for receiving packets using an operating system kernel protocol stack, applied to a switch. The switch includes a Linux kernel and a switching chip. The method includes: obtaining an initial request data packet and a network identifier through the switching chip; processing the initial request data packet according to the network identifier using a network device driver module of the Linux kernel to obtain a first tunnel packet, wherein the first tunnel packet has a virtualized tunnel header, the virtualized tunnel header including the network identifier, and the destination address in the virtualized tunnel header being the interface address of the VXLAN driver module of the Linux kernel; decapsulating the virtualized tunnel header of the first tunnel packet using the VXLAN driver module to obtain a target request data packet; and sending the target request data packet to the protocol stack of the Linux kernel through a Virtual Extensible Local Area Network corresponding to the network identifier.

[0005] Secondly, embodiments of this application provide a packet sending method for an operating system kernel protocol stack, applied to a switch. The switch includes a Linux kernel and a switching chip. The method includes: the Linux kernel's protocol stack sending a specified data packet to the Linux kernel's VXLAN driver module through a target Scalable Local Area Network (Scalable LAN). The specified data packet is a next-hop data packet generated by the protocol stack based on a table lookup of a received request data packet; the VXLAN driver module adding a virtual tunnel header, including a network identifier and the address of the Linux kernel's network device driver module, to the specified data packet to obtain a second tunnel packet, wherein the network identifier corresponds to the target Scalable LAN; the switching chip extracting the network identifier from the virtual tunnel header of the second tunnel packet and stripping the virtual tunnel header to obtain the specified data packet; and forwarding the specified data packet through a logical port in the switching chip corresponding to the network identifier.

[0006] Thirdly, this application provides a forwarding model architecture, including a switching chip and a network device driver module and a VXLAN driver module of the Linux kernel; the switching chip is used to obtain an initial request data packet and a network identifier; the network device driver module is used to process the initial request data packet according to the network identifier to obtain a first tunnel packet, wherein the first tunnel packet has a virtualized tunnel header, the virtualized tunnel header includes the network identifier, and the destination address in the virtualized tunnel header is the interface address of the VXLAN driver module of the Linux kernel; the VXLAN driver module is used to decapsulate the virtualized tunnel header of the first tunnel packet to obtain a target request data packet, and send the target request data packet to the protocol stack of the Linux kernel through the virtual extensible local area network corresponding to the network identifier.

[0007] Fourthly, the application provides a forwarding model architecture, including a switching chip and a Linux kernel VXLAN driver module; the VXLAN driver module is used to receive a specified data packet sent by the Linux kernel protocol stack through a target Scalable Local Area Network (Scalable LAN), wherein the specified data packet is a next-hop data packet generated by the protocol stack based on a table lookup of a received request data packet; the VXLAN driver module is also used to add a virtual tunnel header including a network identifier and the address of the Linux kernel network device driver module to the specified data packet to obtain a second tunnel packet, wherein the network identifier corresponds to the target Scalable LAN; the switching chip is used to extract the network identifier from the virtual tunnel header of the second tunnel packet and strip the virtual tunnel header to obtain the specified data packet; the switching chip is also used to forward the specified data packet through a logical port in the switching chip corresponding to the network identifier.

[0008] Fifthly, embodiments of this application provide an electronic device, which includes a memory and the second forwarding model described above.

[0009] Sixthly, embodiments of this application provide a switch, the switch including memory running a Linux kernel and a switching chip; the switch is used to perform the above-described method.

[0010] This application provides a method for receiving packets, sending packets, and a forwarding model architecture for an operating system kernel protocol stack. The method is applied to a switch, which includes a Linux kernel and a switching chip. The method includes: obtaining an initial request packet and a network identifier through the switching chip; processing the initial request packet according to the network identifier using the network device driver module of the Linux kernel to obtain a first tunnel packet, wherein the first tunnel packet has a virtualized tunnel header, the virtualized tunnel header including the network identifier, and the destination address in the virtualized tunnel header being the interface address of the VXLAN driver module of the Linux kernel; decapsulating the virtualized tunnel header of the first tunnel packet using the VXLAN driver module to obtain a target request packet; and sending the target request packet to the protocol stack of the Linux kernel through the Virtual Extensible Local Area Network corresponding to the network identifier. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram of packet reception in the operating system kernel protocol stack in related technologies is shown; Figure 2 This paper illustrates a flowchart of a packet receiving method for an operating system kernel protocol stack according to an embodiment of this application. Figure 3 This illustration shows a schematic diagram of a forwarding architecture provided in an embodiment of this application; Figure 4 This paper shows another schematic diagram of a forwarding architecture provided in an embodiment of the present application; Figure 5 This paper illustrates another flowchart of a packet sending method for an operating system kernel protocol stack provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of a switch provided in an embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0014] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0015] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0016] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0017] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0018] Please see Figure 1 , Figure 1 This application provides a method for receiving packets using an operating system kernel protocol stack. This method can be applied to electronic devices, such as switches or electronic devices with switching functionality. The electronic device (switch) includes a Linux kernel and a switching chip. The method includes: Step S110: Obtain the initial request data packet and network identifier through the switching chip.

[0019] Among them, the switching chip refers to the application-specific integrated circuit in the network switch, which is responsible for high-speed data packet forwarding and has data processing capabilities. It usually has a hardware forwarding table and logical ports.

[0020] The initial data request packet refers to the raw data packet that enters the logical port of the switching chip from the network and has not yet been processed by the Linux kernel protocol stack. That is, the above step S110 specifically involves receiving the initial request data packet and the network identifier through the logical port of the switching chip.

[0021] The initial data request packet can be divided into two types depending on its source: one type is a packet from the first logical port of the switch chip (e.g., the VTEP port, which is the logical interface used as the endpoint of the virtual network tunnel in the VXLAN network). In this case, the initial request packet is a tunnel packet, which has been encapsulated with a VXLAN tunnel header (outer UDP / IP header and inner VXLAN header). This initial data request packet comes from other VXLAN tunnel endpoints in the network where the switch is located.

[0022] Another type is a message from the second logical port of the switching chip (such as an AC port, Attachment Circuit, which refers to the logical port of the logical link or interface connecting the terminal device (such as a virtual machine, server, or physical machine) to the VTEP). In this case, the VTEP (VXLAN Tunnel Endpoint) is the edge device of the VXLAN network, which is the start and end point for encapsulating and decapsulating VXLAN tunnel messages. VXLAN (Virtual Extensible Local Area Network): In this case, the initial data request packet is a raw message without any VXLAN tunnel header, and the initial data request packet usually comes from a directly connected virtual terminal or physical server.

[0023] Specifically, the network identifier can refer to the network identifier of a Virtual Extensible Local Area Network (VXLAN), namely the VIN (VXLAN Network Identifier). It can be a string of one or more letters, numbers, and symbols, as long as it can be used to uniquely identify a VXLAN virtual network.

[0024] The network identifier can be obtained in several ways. Different logical interfaces can correspond to different network identifiers. The network identifier can be obtained from the logical interface that receives the initial request data packet. Alternatively, it can be obtained from the source / destination IP address or source / destination MAC address in the request data packet, along with a pre-configured mapping policy. No specific limitations are imposed here; the configuration can be tailored to actual needs.

[0025] In one possible implementation of this application, each logical interface can have multiple network identifiers or a corresponding range of network identifiers, and the network identifiers can be obtained by parsing the initial request data packet.

[0026] Step S120: The initial request data packet is processed by the network device driver module of the Linux kernel according to the network identifier to obtain a first tunnel packet. The first tunnel packet has a virtualized tunnel header, the virtualized tunnel header includes the network identifier, and the destination address in the virtualized tunnel header is the interface address of the VXLAN driver module of the Linux kernel.

[0027] The first tunnel message refers to a VXLAN tunnel message with a unified format processed by the network device driver module of the Linux kernel. Since the destination address in its virtualized tunnel header is the interface address of the VP interface of the VXLAN driver module of the Linux kernel, it can ensure that any type of initial request data packet received by the switch, such as data packets received through the first logical port or the second logical port, can be processed into the first tunnel message, and the first tunnel message can be correctly received and processed by the subsequent VXLAN driver module.

[0028] Step S130: Decapsulate the virtualized tunnel header of the first tunnel packet using the VXLAN driver module to obtain the target request data packet.

[0029] The VXLAN driver module is a software component in the Linux kernel that implements VXLAN functionality. It is responsible for the establishment, encapsulation, and decapsulation of VXLAN tunnels. Here, the VXLAN driver module is used for decapsulation, that is, removing the outer VXLAN tunnel header (UDP / IP header and VXLAN header) of the data packet to obtain the target request data packet.

[0030] Specifically, since the destination address of the first tunnel message is the interface address of the VP interface of the Linux kernel's VXLAN driver module, the Linux kernel's network device driver module will deliver the first tunnel message to the VXLAN driver module. After receiving the first tunnel message, the VXLAN driver module will parse the tunnel message and obtain the target request datagram, as well as the network identifier.

[0031] Step S140: Send the target request data packet to the protocol stack of the Linux kernel through the virtual scalable local area network corresponding to the network identifier.

[0032] The Linux kernel protocol stack refers to a set of software code within the operating system kernel that implements network protocols such as TCP / IP, and is responsible for functions such as routing, filtering, and connection management.

[0033] The VXLAN driver module, upon receiving a target request packet and a network identifier, can locate the corresponding VXLAN interface based on the network identifier and replace the source network device with the VXLAN interface in the target request packet. This enables the target request packet to be sent to the Virtual Extensible LAN corresponding to the network identifier. The target request packet is then treated as a message received from the VXLAN interface and injected back into the kernel network protocol stack's input flow. The protocol stack then uses the packet's destination IP address to consult the kernel's routing table and determine whether the packet should be received locally (to an application on the local machine) or forwarded to another network interface (to another host). If forwarding is required, the protocol stack will send the packet to the outgoing interface determined by the routing decision.

[0034] By adopting the method described in this application, the network device driver module of the Linux kernel can process the initial request data packet according to the network identifier to obtain the first tunnel message. Then, the vp interface of the VXLAN driver module performs unified decapsulation to obtain the target request data packet and send it to the protocol stack of the Linux kernel through the virtual extensible LAN. This ensures the directional transmission of data packets in the virtualization environment, thereby solving the problem that directly connected virtual terminals cannot forward packets, improving packet sending efficiency, and expanding the application scenarios of VXLAN networks.

[0035] In one possible implementation, step S110 includes: receiving an initial request data packet through a logical port of the switching chip and obtaining the network identifier corresponding to the initial request data packet, wherein the logical port includes a first logical port used as a tunnel endpoint of a virtual network tunnel and a second logical port used to transmit messages of a virtual terminal. If the logical port that receives the initial request data packet is the first logical port, the data packet carries a virtualized tunnel header; Step S120 includes: replacing the destination address in the virtualized tunnel header with the interface address of the VXLAN driver module through the network device driver module of the Linux kernel to obtain the first tunnel packet.

[0036] It is worth mentioning that there can be multiple first logical ports and multiple second logical ports, and each logical port corresponds to a network identifier.

[0037] The first logical port is the tunnel endpoint of the virtual network tunnel, which is specifically used to receive and send tunnel messages. That is, the initial request data packet received by the switching chip through its first logical port is a tunnel message. When the switching chip receives the initial request data packet, it can know the first logical port corresponding to the initial request data packet, and thus obtain the network identifier corresponding to the initial request data packet.

[0038] For example, such as Figure 3 As shown, this example illustrates how another VTEP device (IP address 10.20.30.40) in the network wants to send a VXLAN message (initial request packet) to this switch. The inner layer of the packet carries the traffic of virtual machine A (10.1.1.2) accessing virtual machine B (10.1.1.1), with a VXLAN network ID (VNI) of 10000 and the physical IP address of this switch being 192.168.100.10.

[0039] When a VXLAN packet arrives at a physical port of a switch (e.g., ge1, ge2, or ge3) through the physical network, the switching chip, based on its configuration, identifies multiple VTEP logical ports created on that physical port. The aforementioned initial request packet is categorized as originating from a VTEP logical port. When the switching chip receives the initial request packet through the VTEP logical port, it can confirm that the initial request packet is a standard tunnel packet carrying a complete VXLAN tunnel header, including an outer Ethernet header and an outer IP header. The outer Ethernet header contains the destination MAC address of the local switch's physical port; the outer IP header contains the source IP address 10.20.30.40 (remote VTEP) and the destination IP address 192.168.100.10 (local physical IP address); the UDP header contains the destination port of the VXLAN port; the VXLAN header contains the VNI address 10000; and the inner raw message contains the source IP address 10.1.1.2 and the destination IP address 10.1.1.1.

[0040] The switching chip's hardware parsing engine parses the tunnel message and directly extracts the VNI field (Network Identifier) ​​value, which is 10000, from the VXLAN tunnel header of the initial request packet. The chip internally records that this message originated from a VTEP port, which can receive messages belonging to multiple different VXLAN networks.

[0041] During this process, since the initial request packet is a tunnel message and its VXLAN header already includes a network identifier, there is no need to add a network identifier to the initial request packet. Simply replace the destination MAC (local physical MAC) in the outer Ethernet header of the initial request packet with the MAC address of the logical interface (e.g., VP port) of the VXLAN driver module (e.g., 02:00:00:00:00:01); and replace the destination IP (192.168.100.10) in the outer IP header with the IP address of the logical interface (e.g., VP port) of the VXLAN driver module (e.g., 169.254.1.1).

[0042] By adopting the above modification, the destination of the initial request packet, the tunnel message, becomes the internal VP interface. The Linux kernel's network stack will directly dispatch this packet to the VP interface bound to the VXLAN driver module based on the destination IP and MAC address, thus bypassing the complex Underlay network processing.

[0043] In one possible implementation, if the logical port receiving the initial request data packet is the second logical port, the above step S120 includes: adding a virtualized tunnel header, including the network identifier corresponding to the second logical port and the interface address of the VXLAN driver module, to the initial request data packet through the network device driver module of the Linux kernel.

[0044] For example, such as Figure 4 As shown, the example illustrates how a raw request packet is generated for virtual machine A (10.1.1.2) to access 10.1.1.1, and then sent to the switching chip via a virtual network. When the raw request packet arrives at a physical port (e.g., ge0) of the switching chip, the switching chip, based on its configuration, identifies that one or more AC logical ports have been created on this ge0 port. The packet is then classified as originating from an AC logical port. Therefore, the switching chip confirms that the received "Initial Request Packet" is a raw Ethernet frame without any VXLAN tunnel header, including: source MAC (i.e., the MAC of virtual machine A), destination MAC (usually the MAC of the gateway or other virtual machines), source IP (i.e., 10.1.1.2), and destination IP (i.e., 10.1.1.1), etc. Unlike the VTEP port, which parses the VNI from the packet, for the AC port, the network identifier (VNI) is determined by the configuration of the logical port itself. That is, when configuring the AC port, the administrator will bind it to a specific VXLAN network, i.e., bind a fixed VNI (e.g., 10000).

[0045] When the switching chip receives the initial request data packet through this AC port, it does not need to parse the message content. It can directly obtain the corresponding network identifier, i.e., VNI=10000, by querying the port configuration based on the message entry point (i.e., the AC port that receives the initial request data packet).

[0046] Specifically, when the initial data request packet arrives at the Linux kernel's network device driver module through the switching chip, the network device driver module parses the packet control word filled in by the switching chip to obtain the network identifier and receiving interface. It then queries the interface type table (maintained by software and issued during AC and VTEP port configuration) to determine whether the initial data request packet originated from the AC port or the VTEP port. If it is determined to originate from the AC port, the initial request packet needs to be encapsulated. At this point, the network device driver module encapsulates this original packet with a completely new and complete VXLAN tunnel header. This new tunnel header contains two core pieces of information: one of which is the network identifier, namely VNI 10000 obtained from the AC port. This value will be filled into the VNI field of the newly created VXLAN header; the other is the interface address of the VXLAN driver module: that is, the IP (169.254.1.1) and MAC (02:00:00:00:00:01) of the logical interface (i.e., VP interface) in the VXLAN driver module. The above IP and MAC addresses are respectively filled into the IP field of the outer IP header destination and the MAC field of the outer Ethernet header destination of the new tunnel header.

[0047] By using the above settings, the first tunnel packet obtained after encapsulation can be "disguised" as a tunnel packet carrying the correct VNI sent to the internal VP interface. The Linux kernel network stack will directly dispatch this packet to the VXLAN driver module based on the destination IP 169.254.1.1, and finally forward it to the kernel protocol stack so that the kernel can recognize and process the packet of the directly connected virtual terminal.

[0048] By processing the two types of packets using the methods described above, the first tunnel packet is obtained. This successfully normalizes two physically distinct data streams (tunnel stream and original stream) into a unified data stream that can be efficiently and correctly processed by the kernel VXLAN module, thereby simultaneously supporting direct connection terminals and improving forwarding performance.

[0049] After processing at the network layer (IP layer), the protocol stack submits the data packet to the corresponding transport layer protocol for processing based on the "protocol" field in the IP header (for example, a value of 6 represents TCP and 17 represents UDP). The protocol stack then looks up the table to generate the next-hop data packet based on the received request packet and uses it as the specified data packet.

[0050] It is worth mentioning that after obtaining a specified data packet, the kernel protocol stack can also send the specified data packet outwards. The specific packet sending process can be found in the packet sending method section below. No specific limitations are made here.

[0051] Please see Figure 5 As shown in the illustration, this application also provides a packet sending method for an operating system kernel protocol stack, applied to a switch. The switch includes a Linux kernel and a switching chip. The method includes: Step S210: The protocol stack of the Linux kernel sends a specified data packet to the VXLAN driver module of the Linux kernel through the target Scalable Local Area Network. The specified data packet is the next-hop data packet generated by the protocol stack based on the received request data packet.

[0052] The specified data packet is generated based on the request packet received by the protocol stack. For details, please refer to the specific description of the packet receiving method of the operating system kernel protocol stack in the previous embodiment, which will not be repeated here.

[0053] The protocol stack can query the routing table to determine the outgoing interface for sending the specified data packet. This outgoing interface is the kernel's representation of the "target Scalable LAN," specifically the VXLAN interface (vxlanif) configured with the corresponding VNI. In the Linux kernel, each VXLAN interface is created and maintained by the VXLAN driver module. Therefore, this data packet can be sent by the protocol stack to the kernel's VXLAN driver module for processing via a table lookup forwarding method through the target Scalable LAN.

[0054] Step S220: The VXLAN driver module adds a virtual tunnel header, including a network identifier and the address of the network device driver module of the Linux kernel, to the specified data packet to obtain a second tunnel packet. The network identifier corresponds to the target Scalable Local Area Network.

[0055] The VXLAN driver module can add the following layers to the outer layer of the original specified data packet: a VXLAN header (containing a VNI), a UDP header, an outer IP header, and an outer Ethernet header. The resulting encapsulated packet is called a "second tunnel packet." After encapsulation, the VXLAN driver module sends this second tunnel packet to the Linux kernel's network device driver module through the kernel's network subsystem.

[0056] Step S230: Extract the network identifier from the virtual tunnel header of the second tunnel packet using the switching chip, and strip the virtual tunnel header to obtain the specified data packet.

[0057] Specifically, the VXLAN driver module can send the "second tunnel packet" directly from the host memory to the CPU port of the switching chip via the sending interface. The hardware parsing engine of the switching chip recognizes that the packet from the CPU port is a VXLAN tunnel packet, and then initiates the hardware decapsulation process: Extracting the network identifier: The chip parses the VXLAN header and extracts the VNI (10000). This VNI is crucial for subsequent hardware forwarding. Stripping the tunnel header: The chip strips away the outer Ethernet header, IP header, UDP header, and VXLAN header of the packet, restoring the internal "specified data packet" (i.e., the original Ethernet frame initially generated by the protocol stack).

[0058] This step enables the use of the switching chip's hardware capabilities to quickly decapsulate packets, extract key forwarding information (VNI), and restore the original packet (specified data packet).

[0059] Step S240: Forward the specified data packet through the logical port in the switching chip corresponding to the network identifier.

[0060] The switching chip can use the destination MAC address + VNI as a key to query its hardware forwarding table. Based on the lookup result, the chip determines which logical port the packet should be sent from. This logical port has two possibilities: One possibility is that the switching chip's logical ports include a first logical port (VTEP port) used as the tunnel endpoint for the virtual network tunnel and a second logical port (AC port) used to transmit packets from the virtual terminal. If the egress is the AC port: the chip directly sends the original specified data packet from the physical port corresponding to the AC port without re-encapsulation. If the egress is the VTEP port: the chip uses the tunnel information configured for the VTEP port (source / destination IP, etc.) to re-encapsulate the original specified data packet with a new VXLAN tunnel header, and then sends the encapsulated new tunnel packet from the corresponding physical port.

[0061] In one possible implementation, the logical ports of the switching chip include a first logical port used as a tunnel endpoint for a virtual network tunnel and a second logical port used for transmitting packets of a virtual terminal. Step S120 includes: if the logical port corresponding to the network identifier is the first logical port, the switching chip adds a virtual tunnel header to the specified data packet according to the tunnel information associated with the first logical port to obtain a third tunnel packet, and forwards the third tunnel packet through the logical port in the switching chip corresponding to the network identifier.

[0062] In one possible implementation, step S120 further includes: if the target logical port is a second logical port, performing a table lookup and forwarding of the specified data packet through the logical port in the switching chip corresponding to the network identifier.

[0063] Please refer to it again. Figure 2 and Figure 3 As shown, taking the example of virtual machine A (10.1.1.2) sending an initial request data packet to virtual machine B (10.1.1.1) through a switch, when virtual machine B (10.1.1.1) needs to send a specified data packet to virtual machine A (10.1.1.2), the destination IP of the original specified data packet is 10.1.1.2. The switch's kernel protocol stack, through routing lookup, hands it over to a VXLAN interface (such as vxlan0) configured with VNI 10000 for processing. Subsequently, the kernel's VXLAN driver module encapsulates a VXLAN tunnel header for this specified data packet, setting its destination IP and MAC to the address of the switch chip's CPU-VTEP port, thus forming a "second tunnel packet". This packet is directly sent to the switch chip's CPU (VTEP port) via DMA. The switch chip's hardware then decapsulates the packet, extracts the internal specified data packet and VNI 10000, and queries the hardware forwarding table. After looking up the table, if the target 10.1.1.2 is found to be directly connected to the local AC port, the chip will directly forward the specified data packet from the AC port to virtual machine A; if the target 10.1.1.2 is found to be directly connected to the local VTEP port, the chip hardware will repackage a new VXLAN tunnel header for it and send it out from the corresponding VTEP port.

[0064] By employing the above method, a specified data packet can be sent to the VXLAN driver module at the protocol stack. The VXLAN driver module encapsulates the specified data packet into a second tunnel message. After obtaining the second tunnel message, it is directly sent to a specific CPU port of the switching chip via DMA (Direct Memory Access). Upon receiving the message at the CPU-VTEP0 port, the switching chip (hardware) immediately performs hardware decapsulation, extracting the VNI and the original message. Then, the chip queries its hardware forwarding table to directly determine whether the message should be forwarded from the AC port or the VTEP port. If the table lookup result shows that the target MAC address is located on an AC port of the local machine, the chip directly forwards the specified data packet from that AC port through step S240. If the table lookup result shows that the target MAC address needs to be reached through a VTEP port, the chip triggers a second hardware encapsulation and then forwards the new tunnel message from the corresponding VTEP port. This re-encapsulation process is entirely completed by the switching chip ASIC. The chip obtains tunnel information (destination IP, MAC, etc.) from the configuration of the target VTEP port and generates a new outer header. The CPU does not need to allocate any computing resources for this encapsulation. Furthermore, this solution physically bypasses the underlying physical network's software protocol stack within the Linux kernel, thereby achieving path optimization and significantly reducing processing latency.

[0065] In other words, by adopting the solution of this application, the encapsulated VXLAN tunnel packet (second tunnel packet) is avoided from being treated as an ordinary IP packet and sent again to the Linux kernel's IP routing stack, bridge subsystem, and associated physical network card driver, as is the case in related technologies. This avoids the inefficiency caused by multiple memory copies, context switches, and software table lookups. Clearly, this solution improves packet sending efficiency by having the network device driver module directly write the second tunnel packet to the CPU-VTEP port of the switch chip via DMA after the VXLAN driver module has encapsulated it. This action skips all the aforementioned kernel software network subsystems.

[0066] In one possible implementation, before executing step S210, the method further includes: generating a next-hop data packet corresponding to the received request data packet by the protocol stack of the kernel layer by looking up a table, determining that the next-hop data packet is a specified data packet, and determining the target scalable local area network from multiple scalable local area networks of the kernel layer according to the address information of the request data packet.

[0067] Specifically, the implementation principles of the above steps can be found in the detailed description of the foregoing embodiments, and will not be repeated here.

[0068] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0069] Another embodiment of this application provides a forwarding model architecture, including a switching chip and a network device driver module and a VXLAN driver module of the Linux kernel; The switching chip is used to acquire the initial request data packet and the network identifier; The network device driver module is used to process the initial request data packet according to the network identifier to obtain a first tunnel message, wherein the first tunnel message has a virtualized tunnel header, the virtualized tunnel header includes the network identifier, and the destination address in the virtualized tunnel header is the interface address of the VXLAN driver module of the Linux kernel. The VXLAN driver module is used to decapsulate the virtualized tunnel header of the first tunnel packet to obtain the target request data packet, and send the target request data packet to the protocol stack of the Linux kernel through the virtual extensible LAN corresponding to the network identifier.

[0070] The specific implementation principle of the above forwarding model architecture can be found in the detailed description of the packet receiving method of the operating system kernel protocol stack in the foregoing embodiments, and will not be repeated here.

[0071] Another embodiment of this application provides a forwarding model architecture, including a switching chip and a VXLAN driver module for the Linux kernel; The VXLAN driver module is used to receive a specified data packet sent by the Linux kernel protocol stack through the target Scalable Local Area Network. The specified data packet is the next-hop data packet generated by the protocol stack by looking up a table based on the received request data packet. The VXLAN driver module is also used to add a virtual tunnel header, including a network identifier and the address of the network device driver module of the Linux kernel, to the specified data packet to obtain a second tunnel packet, wherein the network identifier corresponds to the target Scalable Local Area Network; The switching chip is used to extract the network identifier from the virtual tunnel header of the second tunnel packet, and strip the virtual tunnel header to obtain the specified data packet; The switching chip is also used to forward the specified data packet through the logical port in the switching chip corresponding to the network identifier.

[0072] The specific implementation principle of the above forwarding model architecture can be found in the detailed description of the packet sending method of the operating system kernel protocol stack in the foregoing embodiments, and will not be repeated here.

[0073] The following will combine Figure 6 This application provides a description of an electronic device 100.

[0074] Please see Figure 6 Based on the methods provided in the above embodiments, this application also provides another electronic device 100 including a processor 102 capable of performing the aforementioned methods. The electronic device 100 may be a switch, and the switch includes the forwarding model.

[0075] The electronic device 100 also includes a memory 104. The memory 104 stores a program that can execute the contents of the foregoing embodiments, and the processor 102 can execute the program stored in the memory 104.

[0076] The processor 102 may include one or more cores for data processing and message matrix units. The processor 102 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 102 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 102 and may be implemented separately using a communication chip.

[0077] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data acquired by the electronic device 100 during use.

[0078] The electronic device 100 may also include a network module and a screen. The network module is used to receive and transmit electromagnetic waves, converting electromagnetic waves into electrical signals, thereby enabling communication with communication networks or other devices, such as audio playback devices. The network module may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, SIM cards, memory, etc. The network module can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks, or metropolitan area networks. The screen can display interface content and perform data interaction, such as displaying the aforementioned interface and triggering operations through the screen.

[0079] Please refer to it again. Figure 3 and Figure 4 This application provides a switch, which includes memory running a Linux kernel and a switching chip; the switch is used to execute the aforementioned operating system kernel packet receiving method and / or operating system kernel protocol stack packet sending method.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for receiving packets in an operating system kernel protocol stack, characterized in that, Applied to a switch, the switch including a Linux kernel and a switching chip, the method includes: The initial request data packet and network identifier are obtained through the switching chip; The initial request packet is processed by the network device driver module of the Linux kernel according to the network identifier to obtain a first tunnel packet. The first tunnel packet has a virtualized tunnel header, which includes the network identifier. The destination address in the virtualized tunnel header is the interface address of the VXLAN driver module of the Linux kernel. The VXLAN driver module decapsulates the virtualized tunnel header of the first tunnel packet to obtain the target request data packet. The target request data packet is sent to the protocol stack of the Linux kernel through the virtual scalable local area network corresponding to the network identifier.

2. The method according to claim 1, characterized in that, The step of obtaining the initial request data packet and network identifier through the switching chip includes: The initial request data packet is received through the logical port of the switching chip, and the network identifier corresponding to the initial request data packet is obtained. The logical port includes a first logical port used as the tunnel endpoint of the virtual network tunnel and a second logical port used to transmit messages of the virtual terminal. If the logical port that receives the initial request data packet is the first logical port, the data packet carries a virtualized tunnel header; The network device driver module in the Linux kernel processes the initial request data packet according to the network identifier to obtain a first tunnel message, including: The first tunnel packet is obtained by replacing the destination address in the virtualized tunnel header with the interface address of the VXLAN driver module through the network device driver module of the Linux kernel.

3. The method according to claim 2, characterized in that, If the logical port receiving the initial request data packet is the second logical port, the network device driver module of the Linux kernel processes the initial request data packet according to the network identifier to obtain a first tunnel message, including: The Linux kernel's network device driver module adds a virtualized tunnel header to the initial request packet, including the network identifier corresponding to the second logical port and the interface address of the VXLAN driver module.

4. A method for sending packets using an operating system kernel protocol stack, characterized in that, Applied to a switch, the switch including a Linux kernel and a switching chip, the method includes: The Linux kernel's protocol stack sends a specified data packet to the Linux kernel's VXLAN driver module through the target Scalable Local Area Network. The specified data packet is the next-hop data packet generated by the protocol stack based on a table lookup of the received request data packet. The VXLAN driver module adds a virtual tunnel header, including a network identifier and the address of the network device driver module of the Linux kernel, to the specified data packet to obtain a second tunnel packet. The network identifier corresponds to the target Scalable Local Area Network. The network identifier is extracted from the virtual tunnel header of the second tunnel message by the switching chip, and the virtual tunnel header is stripped to obtain the specified data packet; The specified data packet is forwarded through the logical port in the switching chip corresponding to the network identifier.

5. The method according to claim 4, characterized in that, The switching chip's logic ports include a first logic port used as a tunnel endpoint for a virtual network tunnel and a second logic port used for transmitting messages from virtual terminals. Forwarding the specified data packet through the logical port in the switching chip corresponding to the network identifier includes: If the logical port corresponding to the network identifier is the first logical port, the switching chip adds a virtual tunnel header to the specified data packet according to the tunnel information associated with the first logical port to obtain a third tunnel packet, and forwards the third tunnel packet through the logical port in the switching chip corresponding to the network identifier.

6. The method according to claim 5, characterized in that, The step of forwarding the specified data packet through the logical port in the switching chip corresponding to the network identifier further includes: If the target logical port is the second logical port, the specified data packet is forwarded by looking up a table through the logical port in the switching chip that corresponds to the network identifier.

7. The method according to claim 4, characterized in that, Before the Linux kernel's protocol stack sends the specified data packet to the Linux kernel's VXLAN driver module via the target Scalable Local Area Network, the method further includes: The kernel layer's protocol stack generates a next-hop data packet corresponding to the received request data packet by looking up a table, determines that the next-hop data packet is the specified data packet, and determines the target scalable local area network from multiple scalable local area networks in the kernel layer based on the address information of the request data packet.

8. A forwarding model architecture, characterized in that, This includes switching chips, as well as network device driver modules and VXLAN driver modules for the Linux kernel; The switching chip is used to acquire the initial request data packet and the network identifier; The network device driver module is used to process the initial request data packet according to the network identifier to obtain a first tunnel message, wherein the first tunnel message has a virtualized tunnel header, the virtualized tunnel header includes the network identifier, and the destination address in the virtualized tunnel header is the interface address of the VXLAN driver module of the Linux kernel. The VXLAN driver module is used to decapsulate the virtualized tunnel header of the first tunnel packet to obtain the target request data packet, and send the target request data packet to the protocol stack of the Linux kernel through the virtual extensible LAN corresponding to the network identifier.

9. A forwarding model architecture, characterized in that, This includes the switching chip and the VXLAN driver module for the Linux kernel; The VXLAN driver module is used to receive a specified data packet sent by the Linux kernel protocol stack through the target Scalable Local Area Network. The specified data packet is the next-hop data packet generated by the protocol stack by looking up a table based on the received request data packet. The VXLAN driver module is also used to add a virtual tunnel header, including a network identifier and the address of the network device driver module of the Linux kernel, to the specified data packet to obtain a second tunnel packet, wherein the network identifier corresponds to the target Scalable Local Area Network; The switching chip is used to extract the network identifier from the virtual tunnel header of the second tunnel packet, and strip the virtual tunnel header to obtain the specified data packet; The switching chip is also used to forward the specified data packet through the logical port in the switching chip corresponding to the network identifier.

10. An electronic device, characterized in that, The electronic device includes a memory and the forwarding model as described in claims 8 and / or 9.

11. A switch comprising memory running a Linux kernel and a switching chip; the switch being configured to perform the method described in any one of claims 1-4, or 5-8.

Images