Method for kernel mode flow control unloading, computer equipment and medium

Abstract

The invention relates to the technical field of computers and provides a method for kernel mode flow control unloading, computer equipment and a medium. Kernel mode flow control is realized, message forwarding and hardware unloading kernel mode flow control are realized through cooperation of the kernel mode flow control data path module and the virtual switch of the user space, the pressure of the central processing unit is released, the flow table processing efficiency is improved, and the flow table processing efficiency is improved by expanding and optimizing the message. According to the method, the forwarding information is added to support kernel mode flow control unloading, so that a kernel protocol interface and a kernel protocol stack of an operating system can be called for processing, and the kernel mode flow control unloading is supported on the basis of supporting the kernel mode flow control unloading; the corresponding relation between the virtual network interface and the virtual instance device and the corresponding relation between the virtual instance device and the representative device can be flexibly adjusted, and therefore the requirement of a user for customizing input and output resources is met.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, computer device and medium for kernel-mode flow control offloading. Background Art

[0002] In cloud computing, big data and other applications, network virtualization is relied upon to generate various virtual machines and provide customized services in various input and output aspects. Therefore, it is necessary to improve the forwarding performance of traffic interaction between virtual machines and external devices. To this end, the traffic forwarding service is offloaded to dedicated hardware such as smart network cards. In the prior art, the offloading is completed and the operation function is provided through a dedicated interface in a user-state application in user state, such as the Data Plane Development Kit (DPDK). However, this user-state traffic control offloading solution not only has high requirements for resource configuration, but also bypasses the kernel operating system, resulting in the inability to use the operating system interface. In addition, the polling mode driver (Poll Mode Driver, PMD) is used to bypass the kernel for sending and receiving, resulting in a waste of hardware resources.

[0003] To this end, the present application proposes a method, a computer device and a medium for kernel-mode flow control offloading, which are used to solve the technical difficulties in the prior art. Summary of the invention

[0004] In a first aspect, the present application provides a method for kernel-mode flow control offloading. The method comprises: processing a message sending request of a first virtual network interface associated with a first virtual machine through a message routing module on a network card of a host machine, and sending the first message to a kernel driver on the network card when the message routing module fails to query a flow table for the first message; adding a first extension header to the first message through the kernel driver to obtain an extended first message, and sending the extended first message to a first representative device corresponding to the first virtual network interface in the kernel space of the host machine, wherein the first extension header includes a source device and a target device associated with the first message, and the kernel driver is further used to fill in the source device of the first extension header in the extended first message as the first virtual network interface; receiving the extended first message from the first representative device through a kernel-state flow control data path module in the kernel space, and then querying a flow table for the extended first message, and based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, cooperating with a virtual switch in the user space of the host machine to forward the first message and offload kernel-state flow control to the message routing module.

[0005] Through the first aspect of the present application, kernel-state flow control is implemented. Through the collaboration between the kernel-state flow control data path module and the virtual switch in the user space, message forwarding and hardware offload of kernel-state flow control are realized, which relieves the pressure on the central processing unit and improves the efficiency of flow table processing. In addition, by expanding and optimizing the message, adding forwarding information to support kernel-state flow control offloading, it is helpful to call the operating system kernel protocol interface and kernel protocol stack for processing. On the basis of supporting kernel-state flow control offloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted to meet the user's demand for customized input and output resources.

[0006] In a possible implementation of the first aspect of the present application, the kernel-state flow control data path module cooperates with the virtual switch based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, so as to realize the forwarding of the first message and offload the kernel-state flow control to the message routing module, including: when the kernel-state flow control data path module successfully queries the flow table for the extended first message, the kernel-state flow control data path module determines the first message action associated with the extended first message, and then sends the extended first message to the second representative device corresponding to the first message action in the kernel space; through the kernel driver, the extended first message is received from the second representative device, and then the target device of the first extension header in the extended first message is filled in as the second virtual network interface corresponding to the second representative device, and then the extended first message is sent to the message routing module; through the message routing module, the extended first message is parsed and forwarded to the second virtual machine associated with the second virtual network interface.

[0007] In a possible implementation of the first aspect of the present application, the kernel-state flow control data path module cooperates with the virtual switch based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, so as to realize the forwarding of the first message and offload the kernel-state flow control to the message routing module, and also includes: when the kernel-state flow control data path module fails to query the flow table for the extended first message, the kernel-state flow control data path module sends the extended first message to the virtual switch; through the virtual switch, determines the first message action associated with the extended first message, and then updates the forwarding flow table in the kernel-state flow control data path module; through the kernel-state flow control data path module, based on the updated forwarding flow table in the kernel-state flow control data path module, executes the first message action associated with the extended first message.

[0008] In a possible implementation of the first aspect of the present application, the virtual switch is used to manage a kernel-state flow control unload module in the kernel space, and the method further includes: when the virtual switch updates the forwarding flow table in the kernel-state flow control data path module, the virtual switch synchronously updates the forwarding flow table in the kernel-state flow control unload module; and unloads the forwarding flow table in the kernel-state flow control unload module to the message routing module through the kernel-state flow control unload module.

[0009] In a possible implementation of the first aspect of the present application, the kernel driver of the network card pre-registers a kernel-state flow control configuration function in the kernel-state flow control offload module so that the virtual switch configures hardware offload, and the kernel-state flow control offload module converts the forwarding flow table in the kernel-state flow control offload module into a hardware flow table that can be recognized by the network card by calling the registered kernel-state flow control configuration function.

[0010] In a possible implementation of the first aspect of the present application, the first virtual machine includes a first physical instance device, the first virtual network interface corresponds to the first physical instance device, and the source device of the first message is the first physical instance device.

[0011] In a possible implementation of the first aspect of the present application, the first virtual machine includes a first physical instance device and a first virtual instance device divided from the first physical instance device, the first virtual network interface corresponds to the first virtual instance device, and the source device of the first message is the first virtual instance device.

[0012] In a possible implementation of the first aspect of the present application, the first virtual network interface belongs to multiple virtual network interfaces, the first representative device belongs to multiple representative devices, the multiple virtual network interfaces correspond one-to-one to multiple virtual instance devices, the multiple virtual instance devices correspond one-to-one to the multiple representative devices, the multiple representative devices are managed by the virtual switch, and traffic forwarding between the multiple virtual instance devices is achieved by traffic forwarding between the multiple representative devices.

[0013] In a possible implementation manner of the first aspect of the present application, the method further includes: when the message routing module successfully queries the flow table for the first message, forwarding the first message is performed by the message routing module.

[0014] In a possible implementation of the first aspect of the present application, when the first representative device is created, the correspondence between the first representative device and the virtual instance device corresponding to the first virtual network interface is recorded through software and hardware collaboration in the user space and the kernel space.

[0015] In a possible implementation manner of the first aspect of the present application, at least one user-state application is deployed in the user space of the host machine, and the at least one user-state application includes a data plane development tool set.

[0016] In a second aspect, an embodiment of the present application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements a method according to any one of the implementation modes of any of the above aspects when executing the computer program.

[0017] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a computer device, the computer device executes a method according to any one of the implementation methods of any of the above aspects.

[0018] In a fourth aspect, an embodiment of the present application further provides a computer program product, which includes instructions stored on a computer-readable storage medium, and when the instructions are executed on a computer device, the computer device executes a method according to any one of the implementation methods of any of the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 A flow chart of a method for kernel-mode flow control offloading provided in an embodiment of the present application;

[0021] Figure 2 A schematic diagram of kernel-mode flow control unloading provided in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0024] It should be understood that, in the description of this application, "at least one" means one or more, and "a plurality of" means two or more. In addition, unless otherwise specified, the words "first", "second", etc. are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying an order.

[0025] Figure 1 A flow chart of a method for kernel-mode flow control offloading provided in an embodiment of the present application. Figure 1 As shown, the method includes the following steps.

[0026] Step S101: Processing a message sending request of a first virtual network interface associated with a first virtual machine through a message routing module on a network card of a host machine, and when the message routing module fails to query a flow table for the first message, sending the first message to a kernel driver on the network card.

[0027] Step S103: adding a first extension header to the first message through the kernel driver to obtain an extended first message, and sending the extended first message to a first representative device corresponding to the first virtual network interface in the kernel space of the host machine, wherein the first extension header includes a source device and a target device associated with the first message, and the kernel driver is also used to fill in the source device of the first extension header in the extended first message as the first virtual network interface.

[0028] Step S105: Receive the extended first message from the first representative device through the kernel-state flow control data path module in the kernel space, then query the flow table for the extended first message, and, based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, cooperate with the virtual switch in the user space of the host machine to realize forwarding of the first message and offload kernel-state flow control to the message routing module.

[0029] Figure 1The method for kernel-mode traffic control unloading shown can realize a kernel-mode unloading solution based on traffic control (TC). Different from the user-mode unloading solution, it does not rely on user-mode applications such as the Data Plane Development Kit (DPDK), can make full use of the interface of the kernel operating system, and also reduces the loss caused by switching between the user space and the kernel space. Among them, for the first packet of the network data flow, that is, the first packet, the hard-transferred flow table in the message routing module on the network card may not have a matching flow table entry or a corresponding matching rule, so according to the default rule matching, the first packet of the network data flow is sent to the virtual switch located in the user space. The virtual switch performs soft transfer and determines whether the rules corresponding to the current data flow can be unloaded to the hardware. If it can be unloaded, the kernel-mode traffic control interface is called to send the corresponding rules to the dedicated hardware, that is, to update the hard-transferred flow table on the network card, so that the subsequent messages of the same data flow can be forwarded through the network card. In addition, with the application of network virtualization technology, a physical instance device (physical function, PF) refers to the actual hardware function on a physical device, which represents the entity implementation of a physical device, such as a network adapter, a graphics card, etc. Through single root I / O virtualization (SRIOV), a physical instance device can be divided into multiple virtual instance devices (virtual function, VF), so a PF can correspond to one or more VFs. In addition, any PF and any VF correspond to a virtual network interface (virtual station interface, VSI). The virtual switch manages representative devices (representor), which are representative ports of VFs, for example. They implement forwarding between VFs through forwarding between representative devices, and are also used to implement unloading. For example, a VF first creates a corresponding representative device, and then loads the corresponding representative device to the management of the virtual switch for forwarding unloading, thereby implementing traffic control. Therefore, a VF on a virtual machine has a corresponding representative device, and traffic forwarding and traffic control are implemented through the association between the VF and the representative device. For example, corresponding rules can be configured on the virtual switch, such as setting that all packets received by representative device A are forwarded to representative device B, and all packets received by representative device B are forwarded to representative device A, so that the virtual machine A represented by representative device A and the virtual machine B represented by representative device B can communicate with each other. Figure 1 To further explain how to combine Figure 1 The method for kernel-mode flow control offloading shown in the figure realizes communication between virtual machines based on kernel-mode flow control offloading on the basis of flow table forwarding on software.

[0030] See also Figure 1 In step S101, a message sending request of a first virtual network interface associated with a first virtual machine is processed through a message routing module on a network card of a host machine, and when the message routing module fails to query a flow table for the first message, the first message is sent to a kernel driver on the network card. A network card can be any network communication device, and a dedicated hardware that provides message sending and receiving functions. The message routing module is invisible to the user, and the VF on the first virtual machine is visible to the user. The VF on the first virtual machine corresponds to the first virtual network interface associated with the first virtual machine, that is, a VSI is allocated to the VF, and the corresponding device is indexed by the VSI. Multiple VFs can be configured to be enabled on one or more virtual machines, for example, one VF is allocated to each of two virtual machines, or two VFs can be allocated to one virtual machine, which is conducive to flexible configuration of input and output resources. Here, the first virtual network interface associated with the first virtual machine can correspond to a PF on the first virtual machine, or can correspond to a VF on the first virtual machine. By allocating a VSI to the PF and the VF, the corresponding device can be indexed by the VSI. When the message routing module fails to query the flow table for the first message, this means that there is no corresponding flow table entry or corresponding matching rule in the hard-converted flow table. This may be because the first message packet of the network data flow is to be queried, so the hardware table query of the message routing module does not hit, that is, the internal flow table module does not hit. When the message routing module fails to query the flow table for the first message, the message routing module sends the first message to the kernel driver on the network card. Here, the message routing module can also send the first message to a designated device managed by the kernel driver, such as a VSI control device pre-configured by the software, that is, the software driver decides how to handle messages that do not hit the hard-converted flow table, and the network card kernel driver manages the designated device for handling messages that do not hit the hard-converted flow table.

[0031] Continue reading Figure 1In step S103, the kernel driver adds a first extension header to the first message to obtain an extended first message, and sends the extended first message to the first representative device corresponding to the first virtual network interface in the kernel space of the host machine, wherein the first extension header includes the source device and the target device associated with the first message, and the kernel driver is also used to fill in the source device of the first extension header in the extended first message as the first virtual network interface. Here, in order to realize the communication between virtual machines based on kernel-mode flow control unloading, the original message needs to be optimized, and the first extension header is added, that is, an additional extension header is added on the basis of the original message to store necessary forwarding information to support kernel-mode flow control unloading. Specifically, the additional information included in the first extension header includes the source device and the target device associated with the first message, where the source device is, for example, the source port (sport), which identifies the device from which the message is sent, for example, the sport is VSI-1, that is, it is sent from VF0. The target device, such as the target port (dport), identifies the device to which the message is sent. For example, dport is a designated device (such as CTRL_VSI) managed by the network card kernel driver. Here, the kernel driver is also used to fill in the source device of the first extension header in the first message after the extension as the first virtual network interface. In this way, by parsing the first extension header in the first message after the extension, it can be determined that the source device is the first virtual network interface, and it can also be determined through the corresponding relationship recorded internally which representative device and the corresponding VF the first message from the first virtual network interface actually comes from, so that the driver can call the operating system kernel protocol interface and send the message to the corresponding kernel protocol stack for processing. In this way, on the basis of supporting kernel-mode flow control unloading, the corresponding relationship between the virtual network interface and the virtual instance device and the corresponding relationship between the virtual instance device and the representative device can be flexibly adjusted to meet the user's demand for customized input and output resources.

[0032] Continue reading Figure 1In step S105, the first extended message is received from the first representative device through the kernel-mode flow control data path module in the kernel space, and then the flow table is queried for the first extended message, and based on the result of the kernel-mode flow control data path module querying the flow table for the first extended message, the virtual switch in the user space of the host machine is cooperated to realize the forwarding of the first message and unload the kernel-mode flow control to the message routing module. In this way, the flow table search in the kernel-mode data path is realized, that is, the flow table is queried for the first extended message through the kernel-mode flow control data path module in the kernel space. Therefore, based on the result of the kernel-mode flow control data path module querying the flow table for the first extended message, that is, the kernel-mode flow control data path module fails to query the flow table for the first extended message, or the kernel-mode flow control data path module fails to query the flow table for the first extended message, corresponding subsequent measures can be taken. If the kernel-state flow control data path module fails to query the flow table for the first message after the extension, it means that the message needs to be sent to the user-state virtual switch for soft conversion and the new flow table item or rule needs to be sent to the kernel-state flow control data path module, and it should also be unloaded to the network card if the hardware can be unloaded. If the kernel-state flow control data path module succeeds in querying the flow table for the first message after the extension, it means that the matching message action can be determined, that is, the flow table item or matching rule hit by the first message after the extension can be determined, so that the message can be sent to the corresponding representative device and the corresponding packet sending function can be called to realize message forwarding.

[0033] In this way, kernel-state flow control is implemented. Through the collaboration of the kernel-state flow control data path module and the virtual switch in the user space, message forwarding and hardware offload of kernel-state flow control are realized, which relieves the pressure on the central processing unit and improves the efficiency of flow table processing. In addition, by expanding and optimizing the message and adding forwarding information to support kernel-state flow control offloading, it is helpful to call the operating system kernel protocol interface and kernel protocol stack for processing. On the basis of supporting kernel-state flow control offloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted to meet the user's needs for customized input and output resources.

[0034] Figure 2 A schematic diagram of kernel-mode flow control unloading provided in an embodiment of the present application. Figure 2 As shown, a virtual switch 203 is deployed in the user space 201 of the host machine, and a kernel-mode flow control data path module 213 and a kernel-mode flow control unloading module 215 are deployed in the kernel space 211. A message routing module 223 and a kernel driver 227 are deployed on the network card 221 of the host machine. Figure 2 The kernel-mode flow control unloading shown refers to the following steps: processing a message sending request of a first virtual network interface 225 associated with a first virtual machine through a message routing module 223 on a network card 221 of a host machine, and when the message routing module 223 fails to query a flow table for the first message, sending the first message to a kernel driver 227 on the network card; adding a first extension header to the first message through the kernel driver 227 to obtain an extended first message, and sending the extended first message to a first representative device 217 corresponding to the first virtual network interface 225 in the kernel space 211 of the host machine, wherein the first extension header includes the first message associated with The source device and the target device, the kernel driver 227 is also used to fill in the source device of the first extension header in the first extended message as the first virtual network interface 225; receive the first extended message from the first representative device 217 through the kernel state flow control data path module 213 in the kernel space 211, then query the flow table for the first extended message, and, based on the result of the kernel state flow control data path module 213 querying the flow table for the first extended message, cooperate with the virtual switch 203 in the user space 201 of the host machine to realize the forwarding of the first message and unload the kernel state flow control to the message routing module 223. In addition, the virtual switch 203 is used to manage the kernel state flow control unloading module 215 in the kernel space 211. The method for hardware unloading includes: when the virtual switch 203 updates the forwarding flow table in the kernel-state flow control data path module 213, the virtual switch 203 synchronously updates the forwarding flow table in the kernel-state flow control unloading module 215; and unloading the forwarding flow table in the kernel-state flow control unloading module 215 to the message routing module 223 through the kernel-state flow control unloading module 215. In addition, the kernel driver 227 of the network card pre-registers the kernel-state flow control configuration function 209 in the kernel-state flow control unloading module 215 so that the virtual switch 203 configures hardware unloading, and the kernel-state flow control unloading module 215 converts the forwarding flow table in the kernel-state flow control unloading module 215 into a hardware flow table that can be recognized by the network card 221 by calling the registered kernel-state flow control configuration function 209.

[0035] See also Figure 2, kernel-state flow control is implemented, and the kernel-state flow control data path module 213 cooperates with the virtual switch 203 of the user space 201 to implement message forwarding and hardware offload kernel-state flow control, which releases the pressure on the central processing unit and improves the flow table processing efficiency. In addition, by expanding and optimizing the message, adding forwarding information to support kernel-state flow control offloading, it is helpful to call the operating system kernel protocol interface and kernel protocol stack for processing. On the basis of supporting kernel-state flow control offloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted, thereby meeting the user's demand for customized input and output resources.

[0036] See also Figure 1 and Figure 2In a possible implementation, the kernel-state flow control data path module cooperates with the virtual switch based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, so as to realize the forwarding of the first message and unload the kernel-state flow control to the message routing module, including: when the kernel-state flow control data path module successfully queries the flow table for the extended first message, the kernel-state flow control data path module determines the first message action associated with the extended first message, and then sends the extended first message to the second representative device corresponding to the first message action in the kernel space; through the kernel driver, the extended first message is received from the second representative device, and then the target device of the first extension header in the extended first message is filled in as the second virtual network interface corresponding to the second representative device, and then the extended first message is sent to the message routing module; through the message routing module, the extended first message is parsed and forwarded to the second virtual machine associated with the second virtual network interface. In this way, kernel-mode flow control is implemented, and the kernel-mode flow control data path module cooperates with the virtual switch in the user space to realize message forwarding and hardware offload kernel-mode flow control. For example, by parsing the extension header, the driver can know that the message comes from VF0, such as the Nv0 device corresponding to VM1. At the same time, when the driver turns on SRIOV, it synchronously creates the VF and REP devices, and at the same time, the driver records the corresponding relationship between the VF and REP devices. At this time, the driver can know that the REP device actually corresponding to the message from VSI-1 is REP1, and then the driver calls the operating system kernel protocol stack interface to send the message to the corresponding protocol stack. In this way, the message from REP1 can be forwarded to REP2, and the corresponding relationship between the virtual network interface and the virtual instance device and the corresponding relationship between the virtual instance device and the representative device can be flexibly adjusted to meet the user's customized input and output resource needs. Furthermore, by expanding and optimizing the message, including filling in the target device of the first extension header in the first message after the expansion as the second virtual network interface corresponding to the second representative device, the message forwarding path can be controlled by adjusting the forwarding information included in the extension header. This not only realizes the communication between virtual machines, but also can adapt to the operating mechanism of the kernel state driver, and on this basis meet the operating requirements of network virtualization technology and virtual switches, which is conducive to application in various application scenarios that widely adopt network virtualization technology, such as data centers, high-performance servers, artificial intelligence computing clusters, etc.

[0037] In a possible implementation, the kernel-state flow control data path module cooperates with the virtual switch based on the result of the kernel-state flow control data path module querying the flow table for the first message after extension, so as to realize the forwarding of the first message and unload the kernel-state flow control to the message routing module, and further includes: when the kernel-state flow control data path module fails to query the flow table for the first message after extension, the kernel-state flow control data path module sends the first message after extension to the virtual switch; through the virtual switch, determine the first message action associated with the first message after extension, and then update the forwarding flow table in the kernel-state flow control data path module; through the kernel-state flow control data path module, based on the updated forwarding flow table in the kernel-state flow control data path module, execute the first message action associated with the first message after extension. In this way, when the kernel-state data path fails to search the flow table, send the message to the user space, so that the action can be updated to the data path before executing the action. Therefore, the kernel-mode flow control data path module can execute message actions based on the updated forwarding flow table, such as calling a packet sending function to send a message to the corresponding kernel protocol stack for processing.

[0038] In a possible implementation, the virtual switch is used to manage the kernel-mode flow control unloading module in the kernel space, and the method further includes: when the virtual switch updates the forwarding flow table in the kernel-mode flow control data path module, the virtual switch synchronously updates the forwarding flow table in the kernel-mode flow control unloading module; and unloads the forwarding flow table in the kernel-mode flow control unloading module to the message routing module through the kernel-mode flow control unloading module. In this way, when the hardware unloading selection is enabled by the user, that is, the user enables the hardware unloading function in the configuration of the virtual switch, the virtual switch unloads the flow table to the kernel-mode flow control data path module, that is, when the virtual switch updates the forwarding flow table in the kernel-mode flow control data path module, the virtual switch will also send the flow table to the kernel-mode flow control unloading module, so that after receiving the flow table, the kernel-mode flow control unloading module can call the pre-registered configuration function to parse the sent flow table and convert it into a hardware flow table that can be recognized by the hardware, thereby realizing hardware unloading kernel-mode flow control.

[0039] In a possible implementation, the kernel driver of the network card pre-registers a kernel-mode flow control configuration function in the kernel-mode flow control unloading module so that the virtual switch configures hardware unloading, and the kernel-mode flow control unloading module converts the forwarding flow table in the kernel-mode flow control unloading module into a hardware flow table that can be recognized by the network card by calling the registered kernel-mode flow control configuration function. In this way, hardware unloading kernel-mode flow control is implemented. By pre-registering the configuration function through the kernel driver, various hardware can be flexibly adapted.

[0040] In a possible implementation, the first virtual machine includes a first physical instance device, the first virtual network interface corresponds to the first physical instance device, and the source device of the first message is the first physical instance device. In this way, on the basis of supporting kernel-mode flow control offloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted, thereby meeting the user's demand for customized input and output resources.

[0041] In a possible implementation, the first virtual machine includes a first physical instance device and a first virtual instance device obtained by dividing the first physical instance device, the first virtual network interface corresponds to the first virtual instance device, and the source device of the first message is the first virtual instance device. In this way, on the basis of supporting kernel-mode flow control offloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted, thereby meeting the user's demand for customized input and output resources.

[0042] In a possible implementation, the first virtual network interface belongs to a plurality of virtual network interfaces, the first representative device belongs to a plurality of representative devices, the plurality of virtual network interfaces correspond one-to-one to a plurality of virtual instance devices, the plurality of virtual instance devices correspond one-to-one to the plurality of representative devices, the plurality of representative devices are managed by the virtual switch, and the traffic forwarding between the plurality of virtual instance devices is realized by the traffic forwarding between the plurality of representative devices. In this way, on the basis of supporting kernel-mode flow control unloading, the correspondence between the virtual network interface and the virtual instance device and the correspondence between the virtual instance device and the representative device can be flexibly adjusted, so as to meet the user's demand for customized input and output resources. Moreover, by extending and optimizing the original message, including the kernel driver also being used to fill in the source device of the first extension header in the first message after the extension as the first virtual network interface, it is helpful to support kernel-mode flow control unloading.

[0043] In a possible implementation, the method further includes: when the message routing module successfully queries the flow table for the first message, forwarding the first message is performed by the message routing module. In this way, hard forwarding is supported and flow table forwarding efficiency is improved.

[0044] In a possible implementation, when the first representative device is created, the correspondence between the first representative device and the virtual instance device corresponding to the first virtual network interface is recorded through the software and hardware collaboration in the user space and the kernel space. In this way, by recording the correspondence internally when creating the representative device, it is possible to determine which representative device the message actually comes from, and the virtual network interface and the corresponding VF corresponding to the representative device can flexibly adjust the correspondence between the virtual network interface and the virtual instance device, and the correspondence between the virtual instance device and the representative device on the basis of supporting kernel-mode flow control offloading, so as to meet the user's demand for customized input and output resources.

[0045] In a possible implementation, at least one user-mode application is deployed in the user space of the host machine, and the at least one user-mode application includes a data plane development tool set. In this way, it supports the use of a rich user-mode application ecosystem while realizing message forwarding and hardware offload kernel-mode flow control.

[0046] See also Figure 1 and Figure 2 In some embodiments, two VFs may be configured to be enabled, for example, VF0 and VF1, and the two devices are allocated to VM1 and VM2 respectively, and the device names are Nv0 and Nv1 respectively. Figure 1 and Figure 2And various implementation details, between two virtual machines, namely VF0 and VF1, based on the kernel state traffic control scheme, the intercommunication between virtual machines is realized. Specifically, two representative devices, namely REP devices, REP1 and REP2, are created, and the device names are N_0 and N_1 respectively. The hardware assigns a VSI to PF and VF, and the corresponding device is indexed by VSI. For example, the VSIs corresponding to VF0 and VF1 are 1 and 2 (that is, VSI-1, VSI-2), respectively. Here, the VSI assigned to PF is 0. In addition, CTRL_VSI is deployed as a designated device. CTRL_VSI is invisible to users. CTRL_VSI is used for message routing. It is specifically used to process messages sent up after the hardware table lookup does not hit. Through CTRL_VSI, the message can be forwarded to the corresponding REP device for processing, and the REP device is managed by OVS. Finally, the message can obtain the forwarding flow table through the OVS software, and finally complete the traffic forwarding and unloading. The two VM communication steps can be referred to as follows: 1) First, VF0 is inside VM1. VF0 is visible to the user and the device name is Nv0. If the user initiates a request packet to VM2 in VM1, the packet will first be sent to the hardware by Nv0 (VF0 device). 2) For each VF or PF, the hardware will assign a VSI, which is the ID of the device corresponding to the index. For example, the hardware determines that the request packet comes from VF0 because the packet comes from VSI-1. The hardware then looks up the table through the internal flow table module. If the hardware has just been initialized and there is no flow table, the hardware will send the message to the CTRL_VSI pre-configured by the software. Here, the pre-configured configuration can be understood as a default execution of sending the packet to a device if the flow table query fails. The device is managed by the network card kernel driver, that is, the software driver decides how to handle the packet. 3) CTRL_VSI receives the packet sent by the hardware. The hardware will add an extension header before the original message. That is, if the original message is x, the message received by the driver is h plus x, where h is the extension header added by the hardware. The extension header mainly stores some forwarding information. The main members include but are not limited to sport: identifies the device from which the message is sent, for example, sport is VSI-1, which is sent from VF0; and dport: identifies the device to which the packet is sent, for example, dport is CTRL_VSI, which is sent to CTRL_VSI. By parsing the extension header, the driver can know that the message comes from VF0, which is the Nv0 device of VM1. At the same time, when the driver turns on SRIOV, it simultaneously creates the VF and REP devices. At the same time, the driver records the corresponding relationship between the VF and REP devices internally.The driver knows that the REP device actually corresponding to the message from VSI-1 is REP1 (that is, the N_0 device, which is already mounted on the ovs bridge). At this time, CTRL_VSI updates skb->dev. The previous skb->dev corresponds to the Nv0 device (that is, the VF0 device of VM1), and now it is updated to the N_0 device (that is, the REP1 device managed by ovs). Then the driver calls the operating system kernel protocol stack interface to send the message to the protocol stack. 4) Since the REP1 device (N_0) is added to OVS, this operation will add a hook function to the protocol stack entry of the REP1 device. Once the device receives the message sent from the kernel protocol stack, it will execute this hook function, that is, the packet is redirected to the driver (OVS-TC-DRIVER) inside ovs. 5) After receiving the message, the OVS driver first searches the flow table in the kernel data path. Assuming that the kernel data path is also empty when it is just initialized, OVS will send the message to the user application. 6) After receiving the message, the user-state application parses the message to determine that the message comes from the REP1 device, and then queries the flow table to obtain the corresponding action: output to REP2, that is, the message is forwarded to the REP2 device; then the user-state application notifies the OVS kernel-state driver of the action again; after receiving it, the driver will update the forwarding flow table to the kernel-state data path; that is, if there is no hardware unloading, all subsequent messages sent by VM1 can be forwarded in the OVS kernel-state driver, and no longer need to be sent to the user-state app. (However, if there is hardware unloading, the message will not go to the ovs kernel-state data path to query the flow table, but will be directly forwarded to VM2, which will be introduced later in the hardware unloading part). 7) After the OVS kernel-mode driver updates the action to the data path, it then executes the action, which means that the message needs to be sent to REP2. At this time, the packet sending function REP_PKT_XMIT of REP2 will be called (this function is the packet sending function of the operating system network device, and this function is implemented by the network card driver. 8) The message sent by VM1 has arrived at the packet sending function of REP2 of the network card driver. The operating system provides two parameters for this packet sending function: one is the message to be sent, and the other is the device. Since the network card driver maintains the correspondence between the REP device and the VF device VSI, it can be determined that the message needs to be sent to VSI-2, which is the VF1 device. 9) The network card driver packet sending function fills the dport of the extension header with VSI-2, and then sends the message to the hardware. After receiving it, the hardware parses the extension header and finds that the dport is VSI-2, so it sends the message to the N_1 device of VM2. In this way, communication between the two virtual machines is achieved. Based on the soft-switch flow table, subsequent messages that hit the hard-switch flow table no longer need to rely on the virtual switch for table lookup and forwarding, which improves the efficiency of message processing.

[0047] See also Figure 1 and Figure 2 In some embodiments, in terms of hardware unloading, if the user configures the hardware unloading function in the user-mode OVS, after unloading the flow table to the kernel-mode data path, OVS will also send the flow table to the OVS kernel-mode unloading module. After receiving the flow table, the module will call the configuration function registered in advance by the network card driver, and then the flow table will be directly sent to the hardware unloading module of the network card driver. Then, the hardware unloading module parses the sent flow table, and then translates it into a hardware flow table that can be recognized by the hardware, and finally calls the software and hardware interface to unload the translated flow table to the hardware message routing module.

[0048] See also Figure 1 and Figure 2 In some embodiments, the device naming can be optimized to enable users to quickly distinguish the device correspondence. Specifically, in terms of specifying devices such as CTRL_VSI, the CTRL_VSI is a routing VSI inside the driver and is invisible to users; the forwarding processing of the hardware flow table that is not hit is implemented through the VSI, and the software driver and the hardware cooperate to maintain the correspondence between the VF and REP devices. Through the extended header information, you can know who the traffic comes from and where it goes. Then the traffic is sent to the kernel state OVS, and the kernel state OVS implements how to forward it; finally, after the kernel state OVS obtains the forwarding flow table from the user state OVS, it realizes the unloading of the hardware. In addition, in terms of REP management, when the REP device is created, the software and hardware cooperative driver records the correspondence between the REP device and the VF device to complete the unloading and forwarding. In addition, in terms of the naming of VF / REP devices, users can quickly find the correspondence between devices through device naming, making unloading management simpler and more efficient. In addition, in terms of message extension header processing, by adding an extension header to the original message, the existence of the extension header can complete the forwarding of REP and VF device traffic through the combination of software and hardware. Among them, special management is performed on device naming. When the device is created, a new file can be added to the file system, and then the device name can be written into the file, which can be used by the service later. It should be understood that the name of the PF device is generally not modified, and is named by the default rules of the operating system (of course, it can also be modified according to user needs), as long as the VF and REP device names have the characteristics of the PF device name. For example, assuming that SRIOV is turned on, such as turning on 2 VFs, the network card driver will add 4 devices at this time, and then the driver will first obtain the network device of the PF device in the newly added VF device code, and then obtain the name of the PF device network device. The subsequent VF device can obtain the PF device name N, and then add VF devices one by one, and the device names are Nv0 and Nv1 respectively. The REP device is similarly operated, and the device names are N_0 and N_1 respectively. After each device obtains the name, the name is written into the device network device file system file.

[0049] For example, the four devices in Table 1 below have corresponding file information:

[0050] Table 1

[0051] equipment Vf Vf1 Rep0 Rep1 Device Index 0 1 0 1 Device Name Nv0 Nv1 N_0 N_1

[0052] Refer to Table 1. When each VF or REP device is created, the name of the corresponding PF device is first obtained, and then the device name is written into the device name file of the device driver file system. The device is then named by matching the rules through the service. For example, when naming VF or REP devices, the name of the PF is first obtained, and the PF name is used as the name prefix. Then, the corresponding VF and REP devices are distinguished by character and punctuation combinations. In this way, through device naming, users can quickly identify the corresponding relationship between devices and improve overall efficiency.

[0053] Figure 3 3 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application, and the computing device 300 includes: one or more processors 310, a communication interface 320 and a memory 330. The processor 310, the communication interface 320 and the memory 330 are interconnected via a bus 340. Optionally, the computing device 300 may also include an input / output interface 350, and the input / output interface 350 is connected to an input / output device for receiving parameters set by a user, etc. The computing device 300 can be used to implement some or all of the functions of the device embodiment or system embodiment in the above-mentioned embodiment of the present application; the processor 310 can also be used to implement some or all of the operating steps of the method embodiment in the above-mentioned embodiment of the present application. For example, the specific implementation of the various operations performed by the computing device 300 can refer to the specific details in the above-mentioned embodiments, such as the processor 310 is used to perform some or all of the steps in the above-mentioned method embodiment or some or all of the operations in the above-mentioned method embodiment. For another example, in an embodiment of the present application, the computing device 300 may be used to implement part or all of the functions of one or more components in the above-mentioned apparatus embodiment. In addition, the communication interface 320 may be specifically used to perform the communication functions necessary to implement the functions of these apparatuses and components, and the processor 310 may be specifically used to perform the processing functions necessary to implement the functions of these apparatuses and components.

[0054] It should be understood that Figure 3The computing device 300 may include one or more processors 310, and the multiple processors 310 may provide processing capabilities in a parallel connection mode, a serial connection mode, a serial-parallel connection mode, or any connection mode, or the multiple processors 310 may form a processor sequence or a processor array, or the multiple processors 310 may be divided into a main processor and an auxiliary processor, or the multiple processors 310 may have different architectures such as a heterogeneous computing architecture. In addition, Figure 3 The computing device 300 shown in the figure, and the related structural description and functional description are exemplary and non-limiting. In some exemplary embodiments, the computing device 300 may include Figure 3 More or fewer components may be shown, or some components may be combined or separated, or may have a different arrangement of components.

[0055] The processor 310 may have a variety of specific implementation forms. For example, the processor 310 may include a central processing unit (CPU), a graphic processing unit (GPU), a neural-network processing unit (NPU), a tensor processing unit (TPU) or a data processing unit (DPU), etc., and the embodiment of the present application does not specifically limit it. The processor 310 may also be a single-core processor or a multi-core processor. The processor 310 may be a combination of a CPU and a hardware chip. The above-mentioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. The processor 310 may also be implemented using a logic device with built-in processing logic alone, such as an FPGA or a digital signal processor (DSP). The communication interface 320 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface may be a cellular network interface or a wireless local area network interface, etc.

[0056] The memory 330 may be a non-volatile memory, such as a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The memory 330 may also be a volatile memory, which may be a random access memory (RAM) used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 330 may also be used to store program codes and data, so that the processor 310 calls the program codes stored in the memory 330 to execute some or all of the operation steps in the above method embodiment, or to execute the corresponding functions in the above device embodiment. Figure 3 Show more or fewer components, or have different component configurations.

[0057] The bus 340 may be a peripheral component interconnect express (PCIe) bus, an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 340 may be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 340 may also include a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity, Figure 3 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0058] The method and device provided in the embodiments of the present application are based on the same inventive concept. Since the principles of solving the problems in the methods and devices are similar, the embodiments, implementation methods, examples or implementation methods of the methods and devices can refer to each other, and the repeated parts will not be repeated. The embodiments of the present application also provide a system, which includes multiple computing devices, and the structure of each computing device can refer to the structure of the computing device described above. The functions or operations that can be implemented by the system can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, which will not be repeated here.

[0059] The present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a computer device (such as one or more processors), the method steps in the above method embodiment can be implemented. The specific implementation of the processor of the computer-readable storage medium in executing the above method steps can refer to the specific operations described in the above method embodiment and / or the specific functions described in the above device embodiment, which will not be repeated here.

[0060] It should be understood by those skilled in the art that the embodiments of the present application may be provided as methods, systems, or computer program products. The present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. The embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. The present application may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program codes. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiments of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. Computer-readable storage media can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media. Available media can be magnetic media (such as floppy disks, hard disks, tapes), optical media, or semiconductor media. Semiconductor media can be solid-state hard disks, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other form of suitable storage media.

[0061] 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. 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 generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in 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.

[0062] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. The steps in the method of the embodiment of the present application can be adjusted in order, merged or deleted according to actual needs; the modules in the system of the embodiment of the present application can be divided, merged or deleted according to actual needs. If these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

1. A method for kernel-mode flow control unloading, characterized in that: The method comprises: Processing a message sending request of a first virtual network interface associated with a first virtual machine through a message routing module on a network card of a host machine, and sending the first message to a kernel driver on the network card when the message routing module fails to query a flow table for the first message; By means of the kernel driver, a first extension header is added to the first message to obtain an extended first message, and the extended first message is sent to a first representative device corresponding to the first virtual network interface in the kernel space of the host machine, wherein the first extension header includes a source device and a target device associated with the first message, and the kernel driver is further used to fill in the source device of the first extension header in the extended first message as the first virtual network interface; The extended first message is received from the first representative device through the kernel-state flow control data path module in the kernel space, and then the flow table is queried for the extended first message. Moreover, based on the result of the kernel-state flow control data path module querying the flow table for the extended first message, the virtual switch in the user space of the host machine is cooperated to realize forwarding of the first message and offload kernel-state flow control to the message routing module.

2. The method according to claim 1, characterized in that: By means of the kernel state flow control data path module, based on the result of the kernel state flow control data path module querying the flow table for the extended first message, cooperating with the virtual switch to forward the first message and offloading the kernel state flow control to the message routing module, including: When the kernel-state flow control data path module successfully queries the flow table for the first extended message, the kernel-state flow control data path module determines a first message action associated with the first extended message, and then sends the first extended message to a second representative device corresponding to the first message action in the kernel space; Receiving the extended first message from the second representative device through the kernel driver, then filling in the target device of the first extension header in the extended first message as the second virtual network interface corresponding to the second representative device, and then sending the extended first message to the message routing module; The extended first message is parsed through the message routing module and forwarded to the second virtual machine associated with the second virtual network interface.

3. The method according to claim 2, characterized in that The method further comprises: cooperating with the virtual switch through the kernel state flow control data path module based on the result of the kernel state flow control data path module querying the flow table for the extended first message, so as to realize the forwarding of the first message and offload the kernel state flow control to the message routing module, and further comprising: When the kernel state flow control data path module fails to query the flow table for the first extended message, the kernel state flow control data path module sends the first extended message to the virtual switch; Determining, by means of the virtual switch, the first message action associated with the extended first message, and then updating the forwarding flow table in the kernel state flow control data path module; The first message action associated with the extended first message is executed through the kernel state flow control data path module based on the updated forwarding flow table in the kernel state flow control data path module.

4. The method according to claim 3, characterized in that The virtual switch is used to manage the kernel-mode flow control unloading module in the kernel space, and the method further includes: When the virtual switch updates the forwarding flow table in the kernel-state flow control data path module, the virtual switch synchronously updates the forwarding flow table in the kernel-state flow control offload module; The forwarding flow table in the kernel-state flow control unloading module is unloaded to the message routing module through the kernel-state flow control unloading module.

5. The method according to claim 4, characterized in that The kernel driver of the network card pre-registers a kernel-state flow control configuration function in the kernel-state flow control unloading module so that the virtual switch configures hardware unloading. The kernel-state flow control unloading module converts the forwarding flow table in the kernel-state flow control unloading module into a hardware flow table that can be recognized by the network card by calling the registered kernel-state flow control configuration function.

6. The method according to claim 1, characterized in that The first virtual machine includes a first physical instance device, the first virtual network interface corresponds to the first physical instance device, and the source device of the first message is the first physical instance device.

7. The method according to claim 1, characterized in that The first virtual machine includes a first physical instance device and a first virtual instance device divided from the first physical instance device, the first virtual network interface corresponds to the first virtual instance device, and the source device of the first message is the first virtual instance device.

8. The method according to claim 1, characterized in that The first virtual network interface belongs to multiple virtual network interfaces, the first representative device belongs to multiple representative devices, the multiple virtual network interfaces correspond one-to-one to multiple virtual instance devices, the multiple virtual instance devices correspond one-to-one to the multiple representative devices, the multiple representative devices are managed by the virtual switch, and traffic forwarding between the multiple virtual instance devices is achieved by traffic forwarding between the multiple representative devices.

9. The method according to claim 1, characterized in that: The method further comprises: When the message routing module successfully queries the flow table for the first message, the first message is forwarded by the message routing module.

10. The method according to claim 1, characterized in that When the first representative device is created, the corresponding relationship between the first representative device and the virtual instance device corresponding to the first virtual network interface is recorded through the cooperation of software and hardware in the user space and the kernel space.

11. The method according to claim 1, characterized in that: At least one user-state application is deployed in the user space of the host machine, and the at least one user-state application includes a data plane development tool set.

12. A computer device, characterized in that: The computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which, when executed on a computer device, cause the computer device to perform the method according to any one of claims 1 to 11.

Images