Message processing method, programmable network card device, physical server and storage medium

Abstract

The embodiment of the present application provides a message processing method, a programmable network card device, a physical server and a storage medium. In the embodiment of the present application, a software-based virtual switch is deployed on the programmable network card device, and a message parsing acceleration module and a hardware message queue that provide message parsing services for the virtual switch are implemented on the programmable network card device based on programmable hardware. Messages that need to be forwarded through the virtual switch first pass through the message parsing acceleration module, which parses the header information of the message and provides the parsing results to the virtual switch. This can greatly save the message parsing overhead of the virtual switch and achieve higher message forwarding performance. At the same time, all operations except the parsing of the message header information are completed by the software-based virtual switch, which can adapt to flexible and changeable application requirements and ensure the rapid iteration and evolution of application requirements.

Description

Technical Field

[0001] The present application relates to the technical field of cloud computing, and in particular to a message processing method, a programmable network card device, a physical server, and a storage medium. Background Art

[0002] The slowdown in Moore's Law has led to a rapid increase in the marginal cost of general-purpose central processing unit (CPU) performance. To cope with the expansion of network bandwidth from the mainstream 10G to 25G, 40G, 100G, 200G, and even 400G, cloud vendors have begun adopting hardware acceleration solutions to offload network virtualization processing to SmartNICs. The most typical example is offloading virtual switches (vSwitches) to SmartNICs.

[0003] In this way, whether it is a message sent from the host side of the smart network card or a message received from the physical network, it will first pass through the hardware part of the smart network card to match the flow table entry; if the message hits the flow table entry on the hardware, the hardware part will directly forward the message, realizing hardware acceleration of the vswitch and improving forwarding performance.

[0004] Cloud-based network application requirements are characterized by rapid iteration and evolution. This requires the hardware logic of Smart NICs to be highly flexible and quickly adapt to the iteration and evolution of application requirements. However, hardware typically cannot provide this flexibility. If the hardware logic is implemented using ASICs, it cannot be modified. Even using FPGAs is limited by development cycles and hardware resources, making it unable to support flexible and changing application requirements. Summary of the Invention

[0005] Multiple aspects of the present application provide a message processing method, a programmable network card device, a physical server and a storage medium, which are used to improve forwarding performance while adapting to flexible and changing application requirements.

[0006] An embodiment of the present application provides a physical server, comprising: a physical machine and a programmable network card device, wherein a virtual machine is deployed on the physical machine, and a virtual switch for forwarding data between different virtual machines is deployed on the programmable network card device;

[0007] The programmable network card device includes a message parsing acceleration module and a hardware message queue implemented based on programmable hardware; the message parsing acceleration module is used to receive a target message that needs to be forwarded through the virtual switch, parse the header information of the target message, and obtain metadata information of the target message; and write the target message and the metadata information into the hardware message queue for reading by the virtual switch;

[0008] The virtual switch runs on the processor of the programmable network card device, and is used to read the target message and the metadata information from the hardware message queue, obtain the to-be-matched information of the target message based on the metadata information; match in the forwarding flow table based on the to-be-matched information, and forward the target message based on the flow table entry in the match.

[0009] An embodiment of the present application provides a programmable network card device, on which a virtual switch for forwarding data between different virtual machines is deployed. The programmable network card device includes: a processor, and a message parsing acceleration module and a hardware message queue implemented based on programmable hardware;

[0010] The message parsing acceleration module is configured to receive a target message that needs to be forwarded via the virtual switch, parse the header information of the target message to obtain metadata information of the target message, and write the target message and the metadata information into the hardware message queue for reading by the virtual switch;

[0011] The virtual switch runs on the processor, and is used to read the target message and the metadata information from the hardware message queue, obtain the to-be-matched information of the target message based on the metadata information; match in the forwarding flow table based on the to-be-matched information, and forward the target message based on the flow table entry in the match.

[0012] The present application also provides a message processing method, which is applied to a message parsing acceleration module implemented based on programmable hardware on a programmable network card device. The programmable network card device is deployed with a virtual switch and also includes a hardware message queue implemented based on programmable hardware. The method includes:

[0013] Receive a target message that needs to be forwarded through the virtual switch; parse the header information of the target message to obtain metadata information of the target message; write the target message and the metadata information into the hardware message queue, so that the virtual switch can obtain the to-be-matched information of the target message according to the metadata information and forward the target message according to the flow table entry matched by the to-be-matched information in the forwarding flow table.

[0014] An embodiment of the present application also provides a message processing method, which is applied to a virtual switch on a programmable network card device, wherein the programmable network card device also includes a message parsing acceleration module and a hardware message queue implemented based on programmable hardware. The method includes: reading the target message written by the message parsing acceleration module and the metadata information of the target message from the hardware message queue, wherein the metadata information is obtained by the message parsing acceleration module parsing the header information of the target message; obtaining the to-be-matched information of the target message based on the metadata information, and matching in the forwarding flow table based on the to-be-matched information; and forwarding processing the target message according to the flow table entry in the match.

[0015] An embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor implements the steps of the message processing method provided in the embodiment of the present application and executable by the virtual switch.

[0016] An embodiment of the present application also provides a computer program product, including a computer program / instruction. When the computer program / instruction is executed by a processor, the processor implements the steps of any message processing method provided in the embodiment of the present application.

[0017] In an embodiment of the present application, a software-based virtual switch is deployed on a programmable network card device, and a message parsing acceleration module and a hardware message queue are implemented on the programmable network card device to provide message parsing services for the virtual switch based on programmable hardware. Based on this, the message that needs to be forwarded by the virtual switch first passes through the message parsing acceleration module, which parses the header information of the message to obtain the metadata information of the message, and writes the message and its metadata information into the hardware message queue; in this way, the virtual switch can directly read the message and its metadata information from the hardware message queue, obtain the to-be-matched information of the message based on the metadata information, match it in the forwarding flow table based on the to-be-matched information, and forward the message according to the flow table entry in the match. In this process, the virtual switch does not need to perform the parsing operation of the message header information, but parses the message header information through hardware and provides the parsing result to the virtual switch, which can greatly save the message parsing overhead of the virtual switch and achieve higher message forwarding performance. At the same time, all operations except the parsing of the message header information are completed by the software-based virtual switch, which can adapt to flexible and changeable application requirements and ensure the rapid iteration and evolution of application requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 A schematic diagram of the structure of a physical server provided for an exemplary embodiment of the present application;

[0020] Figure 2a-2c A schematic diagram of the message structure and its parsing status provided for an exemplary embodiment of the present application;

[0021] Figure 3 A schematic diagram of a fast and slow path flow for message forwarding by a physical server provided in an exemplary embodiment of the present application;

[0022] Figure 4 A schematic structural diagram of a programmable network card device provided by an exemplary embodiment of the present application;

[0023] Figure 5 A flowchart of a message processing method provided by an exemplary embodiment of the present application;

[0024] Figure 6 A flowchart of another message processing method provided by an exemplary embodiment of the present application;

[0025] Figure 7 A schematic structural diagram of a message processing device provided for an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0026] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0027] The hardware acceleration solution of the existing virtual switch cannot adapt to the iteration and evolution of application requirements and has poor flexibility. To address this technical problem, in an embodiment of the present application, a software-based virtual switch is deployed on a programmable network card device, and a message parsing acceleration module and a hardware message queue are implemented on the programmable network card device based on programmable hardware. Messages that need to be forwarded through the virtual switch first pass through the message parsing acceleration module, which parses the message header information and provides the parsing results to the virtual switch. This can greatly save the message parsing overhead of the virtual switch and achieve higher message forwarding performance. At the same time, all operations except message header information parsing are completed by the software-based virtual switch, which can adapt to flexible and changing application requirements and ensure rapid iteration and evolution of application requirements.

[0028] The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0029] Figure 1 This is a structural diagram of a physical server provided by an exemplary embodiment of the present application. The physical server can be applied to a cloud network system and implemented as an infrastructure in the cloud network system. Figure 1 As shown, the physical server includes: a physical machine 10, on which at least one virtual machine 101 is deployed, each virtual machine 101 having a virtual network card 101a and an upper-layer application 101b, the virtual network card 101a being a network card simulated by the virtual machine 101 to which it belongs in software or hardware through virtualization technology, the virtual network card 101a serving as the network interface of the virtual machine 101 to which it belongs, and being used to connect the virtual machine 101 to the network and provide data transmission services for the upper-layer application 101b on the virtual machine 101 to which it belongs.

[0030] In this embodiment, in order to implement data forwarding between different virtual machines 101, a virtual switch needs to be deployed on the physical machine. The virtual switch is responsible for forwarding data between different virtual machines 101 on the same physical machine 10 and between different virtual machines 101 on different physical machines 10. For example, when virtual machines E1 and E2 on the same physical machine transmit data, virtual machine E1 first transmits the data to the virtual switch through its virtual network card, and the virtual switch forwards the data to virtual machine E2 via the virtual network card of virtual machine E2. For another example, when data is transmitted between virtual machines F and G on different physical machines, virtual machine F transmits data to the virtual switch on the physical machine to which it belongs through its virtual network card. The virtual switch transmits the data to the physical network card of the physical machine to which it belongs. The physical network card transmits the data to the physical network card of the physical machine to which virtual machine G belongs. The physical network card transmits the data to the virtual switch of the physical machine to which virtual machine G belongs. The virtual switch transmits the data to virtual machine G via the virtual network card of virtual machine G.

[0031] In addition to the aforementioned physical machine 10, the physical server of the embodiment of the present application also includes a programmable network card device 20. The programmable network card device 20 can be implemented as a pluggable structure and plugged into the physical machine 10. The pluggable structure has advantages such as flexibility and strong scalability, but is not limited to this. For example, the programmable network card device 20 can also be directly integrated into the physical machine 10. The programmable network card device 20 has network card functions and can serve as the physical network card of the physical machine 10, responsible for forwarding network traffic on the physical machine 10.

[0032] In addition, some functions of the physical machine 10 can be offloaded to the programmable network card device 20. The programmable network card device 20 consists of two parts: one is the processor (CPU) and the corresponding operating system (OS), which is responsible for carrying some software functions running on the physical machine, such as network management and configuration, and data processing that does not require high performance; the other is the programmable hardware part, which is responsible for accelerating the processing of various software functions on the physical machine 10 and supports hardware offloading of various software functions. For example, some operations that need to be performed by the CPU on the physical machine 10, such as packet encapsulation / decapsulation, Network Address Translation (NAT), rate limiting, and Really Simple Syndication (RSS), can be offloaded to the programmable network card device 20 for hardware implementation, thereby reducing the burden on the physical machine CPU.

[0033] Optionally, in terms of implementation, the programmable network card device 20 may be a smart network card (SmartNiC) or a data processing unit (DPU), without limitation. Furthermore, the programmable hardware on the programmable network card device 20 may be any programmable hardware device, such as an application specific integrated circuit (ASIC), a system on chip (SOC), a field programmable gate array (FPGA), or a complex programmable logic device (CPLD).

[0034] In the embodiment of the present application, with the help of the programmable network card device 20, the virtual switch can be offloaded from the physical machine 10 to the programmable network card device 20. Figure 1 As shown, the virtual switch 201 can be implemented in software on the programmable network card device 20, that is, a software-based virtual switch is deployed on the programmable network card device 20. The software-based virtual switch needs to run on the CPU of the programmable network card device 20, that is, the processor (CPU) of the programmable network card device 20 runs the program code corresponding to the virtual switch to implement the data forwarding function of the virtual switch.

[0035] The following describes, in different scenarios, the process of data transmission by upper-layer application 101b on virtual machine 101 through virtual switch 201. The following uses virtual machine A0, which includes upper-layer application A1 and virtual network card A2, and the physical machine where virtual machine A0 resides, which includes programmable network card device A3, with virtual switch A4 implemented on programmable network card device A3, as an example to describe the data transmission process for upper-layer application A1.

[0036] Data forwarding scenario C1: Upper-layer application A1 receives a message from upper-layer application B1 on another physical machine, processes the message, and then forwards it. Specifically, the physical network card on programmable network card device A3 receives a message from upper-layer application B1 on another physical machine and provides the message to virtual switch A4. Virtual switch A4, based on the forwarding flow table, provides the message to virtual network card A2 of virtual machine A0. Virtual network card A2 then provides the message to upper-layer application A1 on virtual machine A0. Upper-layer application A1 processes the message and provides it to virtual network card A2. Virtual network card A2 provides the processed message to virtual switch A4. Virtual switch A4, based on the forwarding flow table, provides the processed message to the physical network card on programmable network card device A3. The physical network card on programmable network card device A3 then transmits the processed message to upper-layer application B1 via the network.

[0037] Data transmission scenario C2: Upper-layer application A1 generates a message and needs to send it to upper-layer applications on other virtual machines on the same physical machine or to upper-layer applications on other physical machines. Upper-layer application A1 provides the generated message to virtual network card A2, and virtual network card A2 provides the message to virtual switch A4. When upper-layer application A1 instructs to send the message to upper-layer applications on other virtual machines on the same physical machine, virtual switch A4 provides the message to the virtual network card of the other virtual machine based on the forwarding flow table, and the virtual network card of the other virtual machine provides the message to the upper-layer application on the other virtual machine; when the upper-layer application instructs to send the message to the upper-layer application on other physical machines, virtual switch A4 provides the message to the physical network card on programmable network card device A3 based on the forwarding flow table, and the physical network card on programmable network card device A3 provides the message to the physical network card of the other physical machine, so that the physical network card of the other physical machine can provide the received message to the upper-layer application of the other physical machine.

[0038] Data receiving scenario C3: The upper-layer application A1 receives messages sent from upper-layer applications on other virtual machines. Specifically, if the virtual machine where the upper-layer application A1 is located and the other virtual machines are located on the same physical machine, the virtual switch A4 receives the messages sent from the upper-layer applications on the other virtual machines, and provides the messages to the virtual network card A2 based on the forwarding flow table, and the virtual network card A2 provides the received messages to the upper-layer application A1 for the upper-layer application A1 to process the received messages. Alternatively, if the virtual machine where the upper-layer application A1 is located and the other virtual machines are located on different physical machines, the physical network card on the programmable network card device A3 receives the messages sent from the upper-layer applications on other physical machines, and provides the messages to the virtual switch A4, and the virtual switch A4 provides the messages to the virtual network card A2 based on the forwarding flow table, and the virtual network card A2 provides the received messages to the upper-layer application A1 for the upper-layer application A1 to process the received messages.

[0039] In the three application scenarios listed above, the virtual switch is implemented using software and performs packet forwarding based on a forwarding flow table. The forwarding flow table contains multiple flow entries, each corresponding to a data flow. A flow entry primarily consists of two parts: match information and action information. The match information is the key information corresponding to the action information, primarily including information that uniquely identifies the data flow. For example, it can be a packet quintuple: source / destination IP address, source / destination port number, and protocol type. Alternatively, it can be a packet triplet or septuple. The action information includes the action to be performed on the packet, such as encapsulation / decapsulation, forwarding, or rate limiting.

[0040] During packet forwarding, the virtual switch relies on the programmable network card device's CPU to parse the packet to obtain the packet's matching information, match the matching information with the matching information in the forwarding flow table, and process the packet based on the action information in the matching flow table entry. This entire process relies on the programmable network card device's CPU resources and is affected by CPU performance, which can restrict packet forwarding performance. To improve the packet forwarding performance of the virtual switch, hardware offload for the virtual switch can be implemented on the programmable network card device 20 based on the hardware offload function of the programmable network card device 20. That is, a switch acceleration module based on programmable hardware can be implemented on the programmable network card device 20, and the switch acceleration module provides data forwarding acceleration services for the virtual switch 201.

[0041] Specifically, the forwarding flow table used by virtual switch 201 is preconfigured into the switch acceleration module. Thus, during the message transmission and reception process, any message that requires forwarding by the virtual switch first reaches the switch acceleration module. The switch acceleration module parses the message to obtain the message's matching information, matches the matching information in the forwarding flow table based on the matching information, and forwards the message based on the matching flow table entry. Ultimately, hardware replaces the software-based virtual switch 201 in forwarding the message. In the case of a matching flow table entry, the message no longer needs to be sent to virtual switch 201 for software processing, which can improve message forwarding speed. Furthermore, having the switch acceleration module perform message forwarding processing can reduce the involvement of virtual switch 201, thereby reducing the CPU resources of programmable network card device 20 occupied by running virtual switch 201, which is beneficial for improving the performance of the programmable network card device.

[0042] However, due to the rapid iteration and evolution of upper-layer applications based on cloud networks, it is often necessary to change the matching information in the flow table entries and / or the action information in the flow table entries. This requires the switch acceleration module to have strong flexibility and be able to adaptively change the matching information in the hardware flow table entries and / or the action information in the flow table entries according to the iteration and evolution of the upper-layer applications. However, the switch acceleration module implemented based on programmable hardware cannot meet similar flexibility. To this end, in the following embodiments of the present application, a new packet processing solution is provided for accelerating a virtual switch based on hardware-assisted parsing of packets into software form.

[0043] like Figure 1 As shown, the programmable hardware of the programmable network card device 20 implements a message parsing acceleration module 202 and a hardware message queue 203, instead of a switch acceleration module, and a software-based virtual switch 201 runs on the processor of the programmable network card device 20. The programmable hardware on the programmable network card device 20 can be FPGA, CPLD, ASIC or SOC, etc., and the message parsing acceleration module 202 and the hardware message queue 203 are implemented using FPGA, CPLD, ASIC or SOC. Optionally, the hardware message queue 203 can be a ring queue (ring), but is not limited to this. In addition, there can be one or more hardware message queues, which is not limited to this. Figure 1 In the figure, a hardware message queue is used as an example. The acceleration process of the virtual switch 201 based on the message parsing acceleration module 202 and the hardware message queue 203 in the software form is as follows:

[0044] All messages that need to be forwarded through the virtual switch 201 first arrive at the message parsing acceleration module 202. For ease of description and distinction, the messages that need to be forwarded through the virtual switch 201 are referred to as target messages. Figure 1In the figure, the target message shown in ① can be a message sent from an upper-layer application in any virtual machine on the physical machine 10, or it can be a message from an upper-layer application on other physical machines 10 received from the physical network by the physical network card on the programmable network card device.

[0045] The message parsing acceleration module 202 receives the target message that needs to be forwarded via the virtual switch 201, such as Figure 1 As shown in ②, the header information of the target message is parsed to obtain the metadata information of the target message; Figure 1 As shown in step ③, the target message and metadata are written into hardware message queue 203 for reading by virtual switch 201. The metadata primarily includes information obtained by parsing the target message's header information, which helps virtual switch 201 quickly obtain the target message's matching information. The target message's matching information can be a quintuple, triplet, or septuplet of the message, corresponding to the type of matching information in the forwarding flow table, depending on the requirements of the upper-layer application.

[0046] The virtual switch 201 runs on the CPU of the programmable network card device 20, such as Figure 1 As shown in ④, the target message and metadata information can be read from the hardware message queue 203. It should be noted that the action performed by the virtual switch 201 is the action performed by the CPU of the programmable network card device when running the virtual switch 201. Optionally, when the message parsing acceleration module 202 writes the target message and metadata information to the hardware message queue 203, the hardware message queue 203 can generate an interrupt signal, and the CPU reads the target message and metadata information from the hardware message queue 203 according to the interrupt signal generated by the hardware message queue 203. Alternatively, the CPU can periodically poll the hardware message queue 203, and when it is found that there is new target message and metadata information in the hardware message queue 203, it reads the target message and metadata information from the hardware message queue 203.

[0047] like Figure 1 As shown in ⑤, after reading the target message and metadata information from the hardware message queue 203, the virtual switch 201 obtains the target message's to-be-matched information according to the metadata information, and matches it in the forwarding flow table according to the to-be-matched information; and Figure 1 As shown in ⑥, the target message is forwarded according to the matching flow table entry. The forwarding process of the target message includes forwarding the target message to the physical network, or forwarding the target message to the upper layer application in any virtual machine on the physical machine 10.

[0048] Among them, as for the forwarding performance of the software virtual switch 201, the two parts that have a greater impact on the forwarding performance are: one is the parsing of the message header information, and the other is the execution of the processing actions in the flow table entries. However, the execution of the processing actions in the flow table entries often changes with the rapid iteration and evolution of the upper-layer applications. Therefore, in this embodiment, the complete forwarding logic is no longer implemented in hardware like the switch acceleration module. Instead, the message parsing acceleration module 202 and the hardware message queue 203 assist the virtual switch 201 in parsing the message header information and provide the parsing results to the virtual switch 201. By reducing the overhead of message header information parsing, the purpose of improving the forwarding performance of the virtual switch 201 is achieved. At the same time, all operations except the message header information parsing are completed by the software-based virtual switch 201, which can adapt to flexible and changeable application requirements and ensure rapid iteration and evolution of application requirements.

[0049] It is explained here that since the message parsing acceleration module 202 only needs to complete the parsing of the message header information and does not need to match the forwarding flow table, it is different from the implementation method of the switch acceleration module. There is no need to send the forwarding flow table to the message parsing acceleration module 202, that is, there is no need to maintain the forwarding flow table on the hardware, but only needs to maintain the forwarding flow table at the software level.

[0050] In each embodiment of the present application, the implementation method of the message parsing acceleration module 202 for parsing the header information of the target message is not limited, and the following two implementation methods may be used, but are not limited to:

[0051] Implementation method A1: pre-parsing method. In this implementation, after receiving a target message, the message parsing acceleration module 202 can pre-parse the target message's header information to obtain the position offsets of multiple protocol fields contained in the header information; and generate metadata information based on the position offsets of the multiple protocol fields in the header information. Pre-parsing refers to the process of parsing the target message's header information to obtain the position offsets of the multiple protocol fields in the header information. In this embodiment, the metadata information includes at least the position offsets of the multiple protocol fields contained in the target message's header information.

[0052] Specifically, when a target message arrives at the programmable network card device, it is first sent to the message parsing acceleration module 202. The message parsing acceleration module 202 pre-parses the target message's header information in hardware, obtains the offset of each protocol field in the message header information from the outside to the inside, and saves the offset of each protocol field. The offset of each protocol field describes the starting position of each protocol field in the message header information. Optionally, the offset can be a byte number relative to the first byte of the message header.

[0053] It should be noted that the protocol fields included in the header information of different types of messages may be different, and this embodiment of the present application does not limit this. The message parsing acceleration module 202 can pre-parse the header information of various types of messages and obtain the position offset of each protocol field included in the header information. The following examples are provided:

[0054] In some application scenarios, the message transmission does not use the tunnel protocol. The header information of such messages only contains a single layer of protocol fields. For example, the message header information is the second layer L2 protocol field, the third layer L3 protocol field, and the fourth layer L4 protocol field from the outside to the inside. Figure 2a The following is a message structure of a single-layer protocol field. Figure 2a In the example, the L2 protocol field mainly refers to the MAC field; the L3 protocol field mainly refers to the IP field, which can be an IPV4 field or an IPV6 field; the L4 protocol field refers to the TCP field or the UDP field. Figure 2a As shown, the message parsing acceleration module 202 pre-parses the header information of such a message and obtains the position offset of the L2 protocol field and the L2 layer protocol type (such as MAC), the position offset of the L3 protocol field and the L3 layer protocol type (such as IP), the position offset of the L4 protocol field and the L4 layer protocol type (such as TCP or UDP), etc. as metadata information. In other words, the metadata information includes not only the position offset of each protocol field, but also the protocol type of each protocol field. The protocol type information is used to distinguish the corresponding protocol field.

[0055] In other application scenarios, message transmission uses a tunnel protocol, with tunnel encapsulation as the demarcation point. The header information of such messages contains two layers of protocol fields, for example, an outer layer protocol field and an inner layer protocol field. Optionally, the tunnel protocol can be, but is not limited to, vlan or vxlan. In some scenarios, the outer layer protocol field includes, from the outside to the inside, the outer layer L2 protocol field, the outer layer L3 protocol field, the outer layer L4 protocol field, and the outer layer tunnel protocol field; correspondingly, the inner layer protocol field includes, from the outside to the inside, the inner layer L2 protocol field, the inner layer L3 protocol field, the inner layer L4 protocol field, and the inner layer tunnel protocol field. In other scenarios, the outer protocol field includes, from the outside to the inside, the outer L2 protocol field, the outer L3 protocol field, and the outer L4 protocol field, and the outer tunnel protocol field is embedded in the outer L2 protocol field; accordingly, the inner protocol field includes, from the outside to the inside, the inner L2 protocol field, the inner L3 protocol field, and the inner L4 protocol field, and the inner tunnel protocol field is embedded in the inner L2 protocol field.

[0056] like Figure 2b The following is a message structure of a double-layer protocol field. Figure 2bIn the header information of this type of message, from the outside to the inside, the outer layer L2 protocol field, the outer layer L3 protocol field, the outer layer L4 protocol field, the outer layer tunnel protocol header, the inner layer L2 protocol field, the inner layer L3 protocol field, the inner layer L4 protocol field and the inner layer tunnel protocol header. Among them, the outer layer or inner layer L2 protocol field refers to the MAC field, the outer layer or inner layer L3 protocol field refers to the IP field, the outer layer or inner layer L4 protocol field refers to the TCP or UDP field, and the outer layer or inner layer tunnel protocol header can be a vlan or vxlan protocol. Further, as Figure 2b As shown, the message parsing acceleration module 202 pre-parses the header information of such a message and can obtain the position offset of the outer layer L2 protocol field and the protocol type of the outer layer L2 (such as MAC), the position offset of the outer layer L3 protocol field and the protocol type of the outer layer L3 (such as IP), the position offset of the outer layer L4 protocol field and the protocol type of the outer layer L4 (such as TCP or UDP), the position offset of the outer layer tunnel protocol header and the protocol type of the outer layer tunnel protocol header (such as vlan or vxlan), and the position offset of the inner layer L2 protocol field and the protocol type of the inner layer L2 (such as MAC), the position offset of the inner layer L3 protocol field and the protocol type of the inner layer L3 (such as IP), the position offset of the inner layer L4 protocol field and the protocol type of the inner layer L4 (such as TCP or UDP), the position offset of the inner layer tunnel protocol header and the protocol type of the inner layer tunnel protocol header (such as vlan or vxlan), etc. as metadata information. In other words, the metadata information includes not only the position offset of each protocol field, but also the protocol type of each protocol field. The protocol type information is used to distinguish which protocol field corresponds to which.

[0057] like Figure 2c The following is another double-layer protocol field message structure. Figure 2c In the header information of this message, from the outside to the inside, the outer layer L2 protocol field, the outer layer L3 protocol field, the outer layer L4 protocol field, the inner layer L2 protocol field, the inner layer L3 protocol field, and the inner layer L4 protocol field are included in sequence. Among them, the outer layer tunnel protocol field is embedded in the outer layer L2 protocol field, and the inner layer tunnel protocol field is embedded in the inner layer L2 protocol field. Figure 2cAs shown, the message parsing acceleration module 202 pre-parses the header information of such a message and can obtain the position offset of the outer L2 protocol field, the position offset and protocol type of the outer tunnel protocol header (such as vlan or vxlan), the protocol type of the outer L2 (such as MAC), the position offset of the outer L3 protocol field and the protocol type of the outer L3 (such as IP), the position offset of the outer L4 protocol field and the protocol type of the outer L4 (such as TCP or UDP), as well as the position offset of the inner L2 protocol field, the position offset and protocol type of the inner tunnel protocol header (such as vlan or vxlan), and the protocol type of the inner L2 (such as MAC), the position offset of the inner L3 protocol field and the protocol type of the inner L3 (such as IP), the position offset of the inner L4 protocol field and the protocol type of the inner L4 (such as TCP or UDP), etc. as metadata information. In other words, the metadata information includes not only the position offset of each protocol field, but also the protocol type of each protocol field. The protocol type information is used to distinguish which protocol field corresponds to which.

[0058] After obtaining the target message's metadata, message parsing acceleration module 202 writes the target message and metadata into hardware message queue 203 for reading by virtual switch 201. In implementation A1, virtual switch 201 reads the target message and metadata from hardware message queue 203 and, based on the position offsets of multiple protocol fields contained in the metadata, retrieves the values ​​of each protocol field corresponding to the specified protocol type from the target message's header information as the information to be matched.

[0059] The specified protocol type can be determined according to the requirements of the upper layer application. For example, it can be one or a combination of L3 protocol type (such as IP protocol), L4 protocol type (such as TCP or UDP protocol), L2 protocol type (such as MAC protocol), tunnel protocol type (such as vlan or vxlan). Depending on the specified protocol type, the implementation of the information to be matched will be different. For example, if the specified protocol type is Figure 2b or Figure 2c The L4 protocol type in the message structure shown is specifically implemented as a six-tuple (source IP, destination IP, L4 protocol type, source port, destination port, VNI). VNI is a virtual network identifier (Vxlan Network Identifier), which represents a broadcast domain in a vlan or vxlan network. For example, if the specified protocol type is Figure 2a The L4 protocol type in the message structure shown is specifically implemented as a five-tuple (source IP, destination IP, L4 protocol type, source port, destination port) for the information to be matched and the matching information in the forwarding flow table.

[0060] After obtaining the information to be matched, the virtual switch 201 matches the information to be matched in the forwarding flow table. Specifically, the virtual switch 201 matches the information to be matched with the matching information in each flow table entry in the forwarding flow table. If a flow table entry is matched, the target message is forwarded according to the action information in the matching flow table entry. In this embodiment, the matching flow table entry is regarded as a fastpath mode, which includes the message parsing process of the message parsing acceleration module 202, the process of the virtual switch 201 matching the forwarding flow table, and the process of forwarding the message according to the matching flow table entry.

[0061] Further optionally, if no flow table entry is matched, indicating that the target message may be the first message of a data flow, the virtual switch 201 forwards the target message according to the processing flow of the first message based on the target message's to-be-matched information, specifically including: a process of matching the target message in the routing table, ACL table, and rate limit table in sequence according to the target message's to-be-matched information, ultimately obtaining the routing information, ACL policy, and rate limit policy matched in the target message, and forwarding the target message according to the matched routing information, ACL policy, and rate limit policy. In this embodiment, the situation where no flow table entry is matched is regarded as a first slowpath mode, which includes: a message parsing process of the message parsing acceleration module 202, a process of the virtual switch 201 matching the routing table, ACL table, and rate limit table, and a process of forwarding the message according to the matched routing information, ACL policy, and rate limit policy.

[0062] Further optionally, the virtual switch 201 can also generate a flow table entry corresponding to the data flow to which the target message belongs based on the to-be-matched information of the target message and the relevant information matched by the to-be-matched information in the processing flow of the first message, and add the flow table entry to the forwarding flow table. In this way, subsequent messages in the data flow can be processed through the fastpath mode, which helps to improve the message forwarding speed. Among them, the relevant information matched by the to-be-matched information in the processing flow of the first message includes but is not limited to: routing information, ACL policy and speed limit policy matched according to the to-be-matched information of the target message. The to-be-matched information of the target message can be used as the matching information in the flow table entry corresponding to the data flow to which the target message belongs, and the routing information, ACL policy and speed limit policy matched according to the to-be-matched information of the target message can be used as the action information in the flow table entry corresponding to the data flow to which the target message belongs.

[0063] It is explained here that in the pre-parsing process of the above-mentioned implementation method A1, the packet parsing acceleration module 202 only parses the position offsets of the multiple protocol fields contained in the packet header information. The extraction of the information to be matched and the matching and action execution of the forwarding flow table are all the responsibility of the software-based virtual switch 201, which can flexibly respond to the iteration and evolution of any upper-layer application. When the matching information and / or action required by the upper-layer application changes, the matching information and / or action information in the forwarding flow table can be flexibly adjusted. Accordingly, the virtual switch 201 can change the extracted information to be matched and adjust the matching logic and action execution logic as needed. The pre-parsing process of the underlying hardware of the virtual switch 201 is completely unaffected by the iteration and evolution of the upper-layer application. By assisting the virtual switch 201 with hardware to parse the packet header information, the forwarding performance of the virtual switch 201 can be greatly improved.

[0064] Implementation method A2: keyword parsing method. In this implementation, after receiving a target message, the message parsing acceleration module 202 can perform keyword parsing on the target message's header information to obtain the values ​​of each protocol field in the header information corresponding to the specified protocol type; and generate metadata information based on the values ​​of each protocol field in the header information corresponding to the specified protocol type. Keyword parsing refers to the process of parsing the target message's header information to obtain the values ​​of each protocol field in the header information corresponding to the specified protocol type. In this embodiment, the metadata information includes at least the values ​​of each protocol field in the target message's header information corresponding to the specified protocol type, that is, the target message's information to be matched.

[0065] Specifically, the message parsing acceleration module 202 needs to pre-store the specified protocol type required by the upper-layer application. Based on this, when the target message arrives at the programmable network card device, it is first sent to the message parsing acceleration module 202. The message parsing acceleration module 202 performs keyword parsing on the header information of the target message in a hardware manner to obtain the values ​​of each protocol field in the message header information corresponding to the specified protocol type. Optionally, the message parsing acceleration module 202 first pre-parses the header information of the target message to obtain the position offset (offset) and protocol type information of each protocol field in the message header information from the outside to the inside, and saves the position offset and protocol type information of each protocol field; then, the position offset of the protocol field belonging to the specified protocol type is determined from the pre-parsed information, and the values ​​of each protocol field belonging to the specified protocol type are extracted from the header information of the target message based on the position offset of the protocol field belonging to the specified protocol type as metadata information of the target message. Alternatively, optionally, the message parsing acceleration module 202 parses the header information of the target message step by step from the outside to the inside, and each time a protocol field is parsed, determines whether the protocol field belongs to the specified protocol type, until a protocol field belonging to the specified protocol type is parsed, and uses the values ​​of these protocol fields as metadata information of the target message.

[0066] The specified protocol type can be determined according to the requirements of the upper layer application. For example, it can be one or a combination of L3 protocol type (such as IP protocol), L4 protocol type (such as TCP or UDP protocol), L2 protocol type (such as MAC protocol), tunnel protocol type (such as vlan or vxlan). Depending on the specified protocol type, the values ​​of the protocol fields corresponding to the specified protocol type will be different. For example, if the specified protocol type is Figure 2b or Figure 2c The L4 protocol type in the message structure shown is specifically implemented as a six-tuple (source IP, destination IP, L4 protocol type, source port, destination port, VNI). VNI is a virtual network identifier (Vxlan Network Identifier), which represents a broadcast domain in a vlan or vxlan network. For example, if the specified protocol type is Figure 2a The L4 protocol type in the message structure shown is specifically implemented as a five-tuple (source IP, destination IP, L4 protocol type, source port, destination port) corresponding to the specified protocol type.

[0067] After obtaining the target message's metadata, message parsing acceleration module 202 writes the target message and metadata into hardware message queue 203 for reading by virtual switch 201. In implementation A2, virtual switch 201 reads the target message and metadata from hardware message queue 203, obtains the values ​​of each protocol field corresponding to the specified protocol type in the metadata, and directly uses these values ​​as the information to be matched.

[0068] After obtaining the information to be matched, the virtual switch 201 matches the information to be matched in the forwarding flow table, specifically, matches the information to be matched with the matching information in each flow table entry in the forwarding flow table; if the flow table entry is matched, the target message is forwarded according to the action information in the matching flow table entry. In this embodiment, Figure 3 As shown, the matching flow table entry is regarded as a fastpath mode, which includes the message parsing process of the message parsing acceleration module 202, the process of the virtual switch 201 matching the forwarding flow table and the process of forwarding the message according to the matching flow table entry.

[0069] Further optionally, if no flow table entry is matched, indicating that the target message may be the first message of a data flow, the virtual switch 201 forwards the target message according to the processing flow of the first message based on the target message's to-be-matched information, specifically including: matching the target message in the routing table, ACL table, and speed limit table in turn according to the target message's to-be-matched information, and finally obtaining the routing information, ACL policy, and speed limit policy in the target message match, and forwarding the target message according to the matching routing information, ACL policy, and speed limit policy. In this embodiment, if Figure 3 As shown, the situation where no flow table entry is matched is regarded as the first slow path mode, which includes: the message parsing process of the message parsing acceleration module 202, the process of the virtual switch 201 matching the routing table, ACL table and speed limit table, and the process of forwarding the message according to the matching routing information, ACL policy and speed limit policy.

[0070] Further optionally, the virtual switch 201 can also generate a flow table entry corresponding to the data flow to which the target message belongs based on the to-be-matched information of the target message and the relevant information matched by the to-be-matched information in the processing flow of the first message, and add the flow table entry to the forwarding flow table. In this way, subsequent messages in the data flow can be processed through the fastpath mode, which helps to improve the message forwarding speed. Among them, the relevant information matched by the to-be-matched information in the processing flow of the first message includes but is not limited to: routing information, ACL policy and speed limit policy matched according to the to-be-matched information of the target message. The to-be-matched information of the target message can be used as the matching information in the flow table entry corresponding to the data flow to which the target message belongs, and the routing information, ACL policy and speed limit policy matched according to the to-be-matched information of the target message can be used as the action information in the flow table entry corresponding to the data flow to which the target message belongs.

[0071] It is explained here that in the keyword parsing process of the above-mentioned implementation method A2, the packet parsing acceleration module 202 can obtain the information to be matched from the packet header information as metadata information according to the specified protocol type, and the matching and action execution of the forwarding flow table based on the information to be matched are the responsibility of the software-based virtual switch 201, which can flexibly respond to some upper-layer applications that have iterative and evolutionary requirements for packet processing actions. When the packet processing actions required by the upper-layer applications change, the action information in the forwarding flow table can be flexibly adjusted. Accordingly, the virtual switch 201 can adjust the action execution logic as needed, and the keyword parsing process of the underlying hardware of the virtual switch 201 is not affected by the iteration and evolution of the upper-layer applications. By assisting the virtual switch 201 with hardware to parse the packet header information, the forwarding performance of the virtual switch 201 can be greatly improved.

[0072] In either implementation A1 or implementation A2, the message parsing acceleration module 202 is further configured to generate additional parsing information based on the parsing result of the target message header information, and use the additional parsing information as part of the metadata information. In implementation A1, the parsing result of the target message header information specifically refers to the position offset of each of the multiple protocol fields in the target message header information, and may further include the protocol type information of each protocol field, such as Figure 2a-2c In the above implementation A2, the parsing result of the header information of the target message specifically refers to the value of each protocol field corresponding to the specified protocol type in the header information of the target message, that is, the information to be matched.

[0073] Regardless of the implementation method, the additional parsing information may include but is not limited to: first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is wrong when the target message supports hardware parsing, and at least one of the protocol feature information of the target message obtained by parsing when the parsing result is not wrong.

[0074] If the target message can be parsed by the message parsing acceleration module 202, it means that the target message supports hardware parsing, and the value of the first identification information can be a first value, such as 1; if the target message cannot be parsed by the message parsing acceleration module 202, it means that the target message does not support hardware parsing, and the value of the first identification information can be a second value, such as 0. The values ​​of the first value and the second value are not limited, and 1 and 0 are only examples. Figure 2a-2c In the example, the first identification information is represented by unit8_t parse_enable.

[0075] In the case where the target message supports hardware parsing, if the message parsing acceleration module 202 does not report an error during the process of parsing the target message, it means that the parsing result is not wrong, and the second identification information can be a third value, such as 1; if the message parsing acceleration module 202 reports an error during the process of parsing the target message, it means that the parsing result is wrong, and the second identification information can be a fourth value, such as 0. The values ​​of the third value and the fourth value are not limited, and 1 and 0 are only examples. Figure 2a-2c In the example, the second identification information is represented by parse_error.

[0076] If the parsing result is correct, the protocol feature information of the target message obtained by parsing can also be used as additional parsing information. In this embodiment, the protocol feature information of the target message mainly refers to whether the target message is a double-layer message in the logical network (overlay). A double-layer message refers to a message that supports both internal and external double-layer protocols, such as Figure 2b and Figure 2c If the header information of the target message contains both inner and outer layer protocol fields, the value of the protocol characteristic information is 1. If the header information of the target message contains one layer protocol field, the value of the protocol characteristic information is 0. Figure 2a-2c In the protocol feature information, outer_vlaid is used to represent it.

[0077] For the message parsing acceleration module 202, the parsing result of the header information of the target message and the parsing additional information generated according to the parsing result are written as metadata information into the hardware message queue 203. Figure 2a-2cAs shown, in addition to the unit8_t parse_enable, parse_error, and outer_vlaid fields, the additional parsing information also includes a reserved field, parse_reserv, which is used to add more additional parsing information later.

[0078] Based on the above-mentioned additional parsing information, the virtual switch 201 first determines whether the target message supports hardware parsing according to the additional parsing information in the metadata information, whether the parsing structure is wrong if it supports hardware parsing, and further determines whether the target message is a double-layer message containing inner and outer double-layer protocol fields if the parsing result is not wrong.

[0079] Among them, when it is determined based on the parsed additional information that the target message supports hardware parsing and the parsing result is not wrong when hardware parsing is supported, the virtual switch 201 can read the target message and metadata information from the hardware message queue 203 based on whether the target message is a double-layer message containing inner and outer double-layer protocol fields; thereafter, the above-mentioned implementation method A1 or A2 is adopted to obtain the target message's information to be matched based on the metadata information; matching is performed in the forwarding flow table based on the information to be matched, and the target message is forwarded according to the flow table entry in the match.

[0080] Further, optionally, if it is determined based on the parsed additional information that the target message does not support hardware parsing, or that the target message supports hardware parsing but the parsing result is incorrect, the virtual switch 201 needs to perform keyword parsing on the header information of the target message, obtain the values ​​of each protocol field in the header information corresponding to the specified protocol type as the information to be matched, perform a match in the forwarding flow table based on the information to be matched, and forward the target message based on the matching flow table entry. In other words, if the hardware cannot parse the header information of the target message, or the parsing is incorrect, the virtual switch 201 needs to parse the header information of the target message using software.

[0081] Furthermore, after the virtual switch 201 performs keyword parsing on the header information of the target message to obtain the information to be matched, it matches it in the forwarding flow table according to the information to be matched; if a flow table entry is matched, the target message is forwarded according to the action information in the matched flow table entry. If no flow table entry is matched, it means that the target message may be the first message of a data flow, then the virtual switch 201 forwards the target message according to the processing flow of the first message based on the information to be matched of the target message, specifically including: matching in the routing table, ACL table and speed limit table in turn according to the information to be matched of the target message, and finally obtaining the routing information, ACL policy and speed limit policy in the target message match, and forwarding the target message according to the routing information, ACL policy and speed limit policy in the match. Further optionally, the virtual switch 201 can also generate a flow table entry corresponding to the data flow to which the target message belongs based on the information to be matched of the target message and the relevant information matched by the information to be matched in the processing flow of the first message, and add the flow table entry to the forwarding flow table. In this way, subsequent messages in the data flow can be processed through the fastpath mode, which helps to improve the message forwarding speed.

[0082] In this embodiment, if Figure 3 As shown, the message processing flow when the target message does not support hardware parsing or the target message supports hardware parsing but the parsing result is wrong can be called the second slow path (lowpath) mode, which includes: the message parsing process of the message parsing acceleration module 202, the process of the virtual switch 201 re-parsing the message in software, the process of matching the forwarding flow table and forwarding the message according to the matching flow table items, and the process of matching the routing table, ACL table and speed limit table when the flow table items are not matched, and the process of forwarding the message according to the matching routing information, ACL policy and speed limit policy, etc.

[0083] In the above or following embodiments of the present application, a message parsing acceleration module 202, a hardware message queue 203, and a virtual switch 201 are implemented on the programmable network card device 20. Optionally, the programmable network card device 20 also includes a physical network card of a physical machine implemented based on programmable hardware, such as Figure 1 On this basis, different scenarios of message transmission on physical servers are described as follows:

[0084] The upper layer application in virtual machine K generates a first message and needs to send the first message to virtual machine J. After virtual machine J processes the first message, it needs to forward the processed first message to virtual machine H.

[0085] If virtual machine J and virtual machine K are located on the same physical server, virtual machine K sends the first message to the message parsing acceleration module 202 on the same physical server through its virtual network card; the message parsing acceleration module 202 parses the header information of the first message to obtain metadata information, and writes the first message and metadata information into the hardware message pair array; the virtual switch 201 reads the first message and metadata information from the hardware message pair array, adopts the above-mentioned implementation method A1 or A2 to obtain the information to be matched according to the metadata information, and matches in the local forwarding flow table according to the information to be matched. When the flow table entry corresponding to virtual machine J is matched, the first message is sent to virtual machine J via the virtual network card of virtual machine J.

[0086] If virtual machine J and virtual machine K are located on different physical servers, virtual machine K sends the first message to the message parsing acceleration module 202 on the physical server to which it belongs through its virtual network card; the message parsing acceleration module 202 parses the header information of the first message to obtain metadata information, and writes the first message and metadata information into the hardware message pair array; the virtual switch 201 on the physical server to which virtual machine K belongs reads the first message and metadata information from the hardware message pair array, adopts the above-mentioned implementation method A1 or A2 to obtain the information to be matched according to the metadata information, and matches in the local forwarding flow table according to the information to be matched. When the flow table entry corresponding to the physical server to which virtual machine J belongs is matched, the first message is sent to the physical network card of the physical server to which virtual machine K belongs, and the physical network card provides the first message to the physical network card of the physical server to which virtual machine J belongs through network transmission, and the physical network card provides the first message to the message parsing acceleration module 202 of the physical server to which virtual machine J belongs. Furthermore, the message parsing acceleration module 202 of the physical server to which virtual machine J belongs will receive the first message, and the message parsing acceleration module 202 will parse the header information of the first message to obtain metadata information, and write the first message and metadata information into the hardware message pair array; the virtual switch 201 on the physical server to which virtual machine J belongs reads the first message and metadata information from the hardware message pair array, and adopts the above-mentioned implementation method A1 or A2 to obtain the information to be matched according to the metadata information, and matches in the local forwarding flow table according to the information to be matched, and when the flow table entry corresponding to virtual machine J is matched, the first message is provided to virtual machine J via the virtual network card of virtual machine J.

[0087] After receiving the first message, virtual machine J processes the first message to obtain a processed first message, and sends the processed first message to virtual machine H. The process of virtual machine J sending the processed first message to virtual machine H is the same as or similar to the process of virtual machine J receiving the first message sent by virtual machine K. This process can be divided into two cases: virtual machines J and virtual machines H are located on the same physical server or on different physical servers, which will not be described in detail here.

[0088] In the embodiments of the present application, in addition to the above components, the physical server also includes: memory, communication components, power supply components and other components, which are not included in the Figure 1 The memory is used to store computer programs and can be configured to store various other data to support operations on the physical server. Examples of such data include instructions for any application or method operating on the physical server.

[0089] Among them, the memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0090] The communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0091] A power supply assembly provides power to various components of the device in which the power supply assembly resides. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly resides.

[0092] In addition to the above physical server, the embodiment of the present application also provides a programmable network card device, such as Figure 4 As shown, a virtual switch 201 for forwarding data between different virtual machines is deployed on the programmable network card device 20. The programmable network card device includes: a processor, a message parsing acceleration module 202 and a hardware message queue 203 implemented based on programmable hardware.

[0093] Among them, the message parsing acceleration module 202 is used to receive the target message that needs to be forwarded through the virtual switch 201, parse the header information of the target message, and obtain the metadata information of the target message; write the target message and metadata information into the hardware message queue 203 for the virtual switch 201 to read.

[0094] The virtual switch 201 runs on the processor and is used to read the target message and metadata information from the hardware message queue 203, obtain the target message's to-be-matched information based on the metadata information; match the to-be-matched information in the forwarding flow table, and forward the target message based on the matching flow table entry.

[0095] In an optional embodiment, the packet parsing acceleration module 202 is specifically configured to pre-parse the target packet's header information to obtain the position offsets of multiple protocol fields in the header information; and generate metadata information based on the position offsets of the multiple protocol fields in the header information. Accordingly, the virtual switch 201 is specifically configured to obtain the values ​​of each protocol field corresponding to a specified protocol type from the target packet's header information based on the position offsets of the multiple protocol fields in the metadata information, as the information to be matched.

[0096] In an optional embodiment, the packet parsing acceleration module 202 is specifically configured to perform keyword parsing on the header information of the target packet to obtain the values ​​of each protocol field in the header information corresponding to a specified protocol type; and generate metadata information based on the values ​​of each protocol field in the header information corresponding to the specified protocol type. Accordingly, the virtual switch 201 is specifically configured to obtain the values ​​of each protocol field in the metadata information corresponding to the specified protocol type as the information to be matched.

[0097] In an optional embodiment, the message parsing acceleration module 202 is further configured to generate additional parsing information based on the parsing result of the target message header information, and include the additional parsing information as part of the metadata information. The additional parsing information includes at least one of first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is an error if the target message supports hardware parsing, and protocol feature information of the target message obtained by parsing.

[0098] In an optional embodiment, when the target message does not support hardware parsing or the parsing result is erroneous, the virtual switch 201 is further used to: perform keyword parsing on the header information of the target message, obtain the value of each protocol field corresponding to the specified protocol type in the header information as the information to be matched; match in the forwarding flow table according to the information to be matched, and forward the target message according to the flow table entry in the match.

[0099] In an optional embodiment, the virtual switch 201 is also used to: when no flow table entry is matched, forward the target message according to the processing flow of the first message based on the information to be matched; generate a flow table entry corresponding to the data flow to which the target message belongs based on the information to be matched and the relevant information matched by the information to be matched in the processing flow of the first message, and add the flow table entry to the forwarding flow table.

[0100] The programmable network card device provided in the embodiment of the present application can deploy a virtual switch in software form, and includes a message parsing acceleration module and a hardware message queue implemented based on programmable hardware; the message that needs to be forwarded through the virtual switch first passes through the message parsing acceleration module, and the message parsing acceleration module parses the header information of the message and provides the parsing result to the virtual switch, which can greatly save the message parsing overhead of the virtual switch and achieve higher message forwarding performance. At the same time, all operations except the parsing of the message header information are completed by the software virtual switch, which can adapt to flexible and changeable application requirements and ensure the rapid iteration and evolution of application requirements.

[0101] Figure 5 A flow chart of a message processing method provided for an exemplary embodiment of the present application; the message processing method is applied to a physical server, the physical server includes a physical machine and a programmable network card device, a virtual machine is deployed on the physical machine, a virtual switch is deployed on the programmable network card device, and the programmable network card device includes a message parsing acceleration module and a hardware message queue based on programmable hardware, and the virtual switch is used to forward data between different virtual machines. For a detailed introduction to each component in the physical server, please refer to the aforementioned embodiment and will not be repeated here. The method provided in this embodiment is specifically described from the perspective of the message parsing acceleration module on the programmable network card device of the physical server, such as Figure 5 As shown, the method includes:

[0102] 501. Receive a target message that needs to be forwarded via a virtual switch;

[0103] 502. Parse the header information of the target message to obtain metadata information of the target message;

[0104] 503. Write the target message and metadata information into the hardware message queue, so that the virtual switch can obtain the to-be-matched information of the target message according to the metadata information and forward the target message according to the flow table entry matched by the to-be-matched information in the forwarding flow table.

[0105] In an optional embodiment, parsing the header information of the target message to obtain metadata information of the target message includes: pre-parsing the header information of the target message to obtain position offsets of multiple protocol fields in the header information; and generating metadata information of the target message based on the position offsets of the multiple protocol fields in the header information. In this optional embodiment, the metadata information of the target message includes the position offsets of the multiple protocol fields in the header information.

[0106] In another optional embodiment, parsing the target message's header information to obtain metadata information about the target message includes: performing keyword parsing on the target message's header information to obtain values ​​of each protocol field in the header information corresponding to a specified protocol type; and generating metadata information about the target message based on the values ​​of each protocol field in the header information corresponding to the specified protocol type. In this optional embodiment, the metadata information about the target message includes values ​​of each protocol field in the header information corresponding to the specified protocol type, such as a quintuple or a triplet.

[0107] In the above optional embodiments, the position offsets of the respective protocol fields in the header information, or the values ​​of the protocol fields corresponding to the specified protocol type in the header information, are all parsing results obtained by parsing the header information of the target message. In some optional embodiments, in addition to generating metadata information of the target message based on the parsing results of the header information of the target message, additional parsing information can also be generated based on the parsing results of the header information of the target message, and the additional parsing information can be used as part of the metadata information. Optionally, the additional parsing information includes at least one of first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is erroneous if the target message supports hardware parsing, and protocol feature information of the target message obtained by parsing.

[0108] Figure 6 A flow chart of another message processing method provided for an exemplary embodiment of the present application; the message processing method is applied to a physical server, the physical server includes a physical machine and a programmable network card device, a virtual machine is deployed on the physical machine, a virtual switch is deployed on the programmable network card device, and the programmable network card device includes a message parsing acceleration module and a hardware message queue based on programmable hardware, and the virtual switch is used to forward data between different virtual machines. For a detailed introduction to each component in the physical server, please refer to the aforementioned embodiment and will not be repeated here. The method provided in this embodiment is specifically described from the perspective of a virtual switch deployed on the programmable network card device of the physical server, and the virtual switch can run on the CPU of the programmable network card device, such as Figure 6 As shown, the method includes:

[0109] 601. Read the target message and metadata information of the target message written by the message parsing acceleration module from the hardware message queue, where the metadata information is obtained by parsing the header information of the target message by the message parsing acceleration module.

[0110] 602. Obtain the to-be-matched information of the target message according to the metadata information, and perform a match in the forwarding flow table according to the to-be-matched information;

[0111] 603. Forward the target message according to the matching flow entry.

[0112] In an optional embodiment, the metadata information of the target message includes position offsets of each of multiple protocol fields in the header information. Based on this, obtaining the target message's to-be-matched information based on the metadata information includes: obtaining, from the target message's header information, values ​​of each protocol field corresponding to a specified protocol type based on the position offsets of each of the multiple protocol fields in the metadata information, as the to-be-matched information.

[0113] In another optional embodiment, the metadata information of the target message includes values ​​of each protocol field in the header information corresponding to the specified protocol type. Based on this, obtaining the target message's to-be-matched information based on the metadata information includes: obtaining the values ​​of each protocol field in the metadata information corresponding to the specified protocol type as the to-be-matched information.

[0114] In an optional embodiment, the metadata information of the target message further includes: additional parsing information. Optionally, the additional parsing information is generated based on the parsing result of the target message header information, and includes at least one of first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is an error if the target message supports hardware parsing, and protocol feature information of the target message obtained through parsing.

[0115] The virtual switch can also determine whether the target message supports hardware parsing based on the additional parsing information included in the metadata information of the target message, whether the parsing structure is wrong if it supports hardware parsing, and further determine whether the target message is a double-layer message containing inner and outer double-layer protocol fields if the parsing result is not wrong.

[0116] In the case where the target message does not support hardware parsing or the target message supports hardware parsing but the parsing result is erroneous, the method further includes: performing keyword parsing on the header information of the target message to obtain the values ​​of each protocol field corresponding to the specified protocol type in the header information as information to be matched; matching in the forwarding flow table according to the information to be matched, and forwarding the target message according to the flow table entry in the match.

[0117] Further optionally, the method also includes: in the case where no flow table entry is matched, forwarding the target message according to the processing flow of the first message based on the information to be matched; generating a flow table entry corresponding to the data flow to which the target message belongs based on the information to be matched and the relevant information matched by the information to be matched during the forwarding processing, and adding the flow table entry to the forwarding flow table.

[0118] In the message processing method provided in the above-mentioned embodiment of the present application, the virtual switch cooperates with the message parsing acceleration module and the hardware message queue implemented based on programmable hardware on the programmable network card device; the message that needs to be forwarded through the virtual switch first passes through the message parsing acceleration module, and the message parsing acceleration module parses the header information of the message and provides the parsing result to the virtual switch, which can greatly save the message parsing overhead of the virtual switch and achieve higher message forwarding performance. At the same time, all operations except the parsing of the message header information are completed by the virtual switch in software form, which can adapt to flexible and changeable application requirements and ensure the rapid iteration and evolution of application requirements.

[0119] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The serial numbers of the operations, such as 501, 502, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0120] The present application provides a schematic diagram of a message processing device according to an exemplary embodiment. Figure 7 As shown, the message processing device can be implemented in a virtual switch and includes:

[0121] A reading module 71 is configured to read the target message and metadata information of the target message written by the message parsing acceleration module from the hardware message queue, wherein the metadata information is obtained by parsing the header information of the target message by the message parsing acceleration module;

[0122] A matching module 72 is configured to obtain information to be matched of the target message according to the metadata information, and perform matching in the forwarding flow table according to the information to be matched;

[0123] The forwarding module 73 is configured to forward the target message according to the flow table entry matched by the matching module.

[0124] Figure 6 All relevant contents of each step involved in the illustrated method embodiment can be referred to in the corresponding functional description and will not be repeated here.

[0125] Accordingly, the embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement Figure 6 The steps in the method shown.

[0126] Accordingly, the embodiment of the present application further provides a computer program product that stores a computer program / instruction, which, when executed by a processor, enables the processor to implement Figure 6 The steps in the method shown.

[0127] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0128] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0129] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0130] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0131] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in a computer-readable medium, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0132] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0133] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0134] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A physical server, characterized in that: include: A physical machine and a programmable network card device, wherein a virtual machine is deployed on the physical machine, and a software-based virtual switch for forwarding data between different virtual machines is deployed on the programmable network card device; The programmable network card device includes a message parsing acceleration module and a hardware message queue implemented based on programmable hardware; the message parsing acceleration module is used to receive a target message that needs to be forwarded through the virtual switch, parse the header information of the target message, and obtain metadata information of the target message; and write the target message and the metadata information into the hardware message queue for reading by the virtual switch; The virtual switch runs on the processor of the programmable network card device, and is used to read the target message and the metadata information from the hardware message queue, and obtain the to-be-matched information of the target message based on the metadata information; match in the forwarding flow table based on the to-be-matched information, and forward the target message based on the flow table entry in the match; when the matching information and / or action required by the upper-layer application in the virtual machine changes, the virtual switch changes the extracted to-be-matched information as needed, and adjusts the matching logic and action execution logic.

2. The physical server according to claim 1, wherein: The message parsing acceleration module is specifically used for: Pre-parsing the header information of the target message to obtain position offsets of multiple protocol fields in the header information; The metadata information is generated according to the position offsets of the respective multiple protocol fields in the header information.

3. The physical server according to claim 2, wherein: The virtual switch is specifically used for: According to the position offsets of the plurality of protocol fields in the metadata information, the values ​​of the protocol fields corresponding to the specified protocol type are obtained from the header information of the target message as the information to be matched.

4. The physical server according to claim 1, wherein: The message parsing acceleration module is specifically used for: Perform keyword parsing on the header information of the target message to obtain the value of each protocol field corresponding to the specified protocol type in the header information; and generate the metadata information according to the value of each protocol field corresponding to the specified protocol type in the header information; The virtual switch is specifically configured to obtain values ​​of various protocol fields corresponding to a specified protocol type in the metadata information as the information to be matched.

5. The physical server according to any one of claims 1 to 4, characterized in that: The message parsing acceleration module is also used to: Generate parsed additional information according to the parsing result of the header information of the target message, and use the parsed additional information as part of the metadata information; The additional parsing information includes at least one of first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is wrong if the target message supports hardware parsing, and protocol feature information of the target message obtained by parsing.

6. The physical server according to claim 5, characterized in that In the case that the target message does not support hardware parsing or the parsing result is erroneous, the virtual switch is further configured to: Perform keyword parsing on the header information of the target message to obtain the value of each protocol field corresponding to the specified protocol type in the header information as the information to be matched; Matching is performed in a forwarding flow table according to the information to be matched, and forwarding processing is performed on the target message according to the matched flow table entry.

7. A programmable network card device, characterized in that: The programmable network card device is deployed with a software-based virtual switch for forwarding data between different virtual machines. The programmable network card device includes: a processor, a message parsing acceleration module and a hardware message queue implemented based on programmable hardware; The message parsing acceleration module is configured to receive a target message that needs to be forwarded via the virtual switch, parse the header information of the target message to obtain metadata information of the target message, and write the target message and the metadata information into the hardware message queue for reading by the virtual switch; The virtual switch runs on the processor and is configured to read the target message and the metadata information from the hardware message queue, obtain the to-be-matched information of the target message based on the metadata information, perform matching in a forwarding flow table based on the to-be-matched information, and forward the target message based on the flow table entry in the match; when the matching information and / or action required by the upper-layer application in the virtual machine changes, the virtual switch changes the extracted to-be-matched information as needed and adjusts the matching logic and action execution logic.

8. The device according to claim 7, characterized in that The message parsing acceleration module is specifically used for: Pre-parsing the header information of the target message to obtain position offsets of multiple protocol fields in the header information; The metadata information is generated according to the position offsets of the respective multiple protocol fields in the header information.

9. The device according to claim 8, characterized in that The virtual switch is specifically used for: According to the position offsets of the plurality of protocol fields in the metadata information, the values ​​of the protocol fields corresponding to the specified protocol type are obtained from the header information of the target message as the information to be matched.

10. The device according to claim 7, characterized in that The message parsing acceleration module is specifically used for: Perform keyword parsing on the header information of the target message to obtain the value of each protocol field corresponding to the specified protocol type in the header information; and generate the metadata information according to the value of each protocol field corresponding to the specified protocol type in the header information; The virtual switch is specifically configured to obtain values ​​of various protocol fields corresponding to a specified protocol type in the metadata information as the information to be matched.

11. A message processing method, characterized in that: A packet parsing acceleration module implemented based on programmable hardware is applied to a programmable network card device, wherein the programmable network card device is deployed with a software-based virtual switch and also includes a hardware packet queue implemented based on programmable hardware. The method includes: receiving a target message that needs to be forwarded via the virtual switch; Parsing the header information of the target message to obtain metadata information of the target message; The target message and the metadata information are written into the hardware message queue, so that the virtual switch can obtain the information to be matched of the target message according to the metadata information and forward the target message according to the flow table entry matched by the information to be matched in the forwarding flow table; when the matching information and / or action required by the upper-layer application in the virtual machine changes, the virtual switch changes the extracted information to be matched as needed and adjusts the matching logic and action execution logic.

12. The method according to claim 11, characterized in that Parsing the header information of the target message to obtain metadata information of the target message includes: Pre-parsing the header information of the target message to obtain position offsets of multiple protocol fields in the header information; The metadata information is generated according to the position offsets of the respective multiple protocol fields in the header information.

13. The method according to claim 11, characterized in that Parsing the header information of the target message to obtain metadata information of the target message includes: Perform keyword parsing on the header information of the target message to obtain the value of each protocol field corresponding to the specified protocol type in the header information; The metadata information is generated according to the values ​​of the protocol fields corresponding to the specified protocol type in the header information.

14. The method according to any one of claims 11 to 13, characterized in that: Also includes: Generate parsed additional information according to the parsing result of the header information of the target message, and use the parsed additional information as part of the metadata information; The additional parsing information includes at least one of first identification information indicating whether the target message supports hardware parsing, second identification information indicating whether the parsing result is wrong if the target message supports hardware parsing, and protocol feature information of the target message obtained by parsing.

15. A message processing method, characterized in that: A software-based virtual switch applied to a programmable network card device, wherein the programmable network card device further includes a message parsing acceleration module and a hardware message queue implemented based on programmable hardware, and the method includes: Reading the target message written by the message parsing acceleration module and metadata information of the target message from the hardware message queue, where the metadata information is obtained by the message parsing acceleration module by parsing header information of the target message; Acquire the to-be-matched information of the target message according to the metadata information, and perform matching in the forwarding flow table according to the to-be-matched information; Forwarding the target message according to the matching flow table entry; When the matching information and / or action required by the upper layer application in the virtual machine changes, the virtual switch changes the extracted information to be matched as needed and adjusts the matching logic and action execution logic.

16. The method according to claim 15, characterized in that Acquiring the target message's information to be matched according to the metadata information includes: According to the position offsets of the plurality of protocol fields in the metadata information, obtaining the values ​​of the protocol fields corresponding to the specified protocol type from the header information of the target message as the information to be matched; or The values ​​of the protocol fields corresponding to the specified protocol type in the metadata information are obtained as the information to be matched.

17. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to implement the steps in the method according to any one of claims 15 to 16.

Images