Data transmission method and device

Abstract

Embodiments of the present invention disclose a data transmission method and apparatus, applied to a daemon process in a host machine. The method comprises: obtaining information required for performing an acceleration operation from a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator; determining information recognizable by the hardware accelerator based on the information required for performing the acceleration operation; and transmitting the information recognizable by the hardware accelerator to the hardware accelerator, wherein the hardware accelerator is configured to obtain data to be accelerated based on the information recognizable by the hardware accelerator and perform an acceleration operation on the data to be accelerated. Implementing embodiments of the present invention can improve the transmission efficiency of data packets.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a data transmission method and device. Background Art

[0002] Network Function Virtualization (NFV) achieves hardware universalization through a combination of "software + general-purpose hardware". This makes network device functions no longer dependent on dedicated hardware. Hardware resources can be fully and flexibly shared, enabling the rapid development and deployment of new services. It also performs automatic deployment, elastic scaling, fault isolation, and self-healing based on actual business needs.

[0003] However, with the generalization of NFV hardware, the processing power of these general-purpose devices is insufficient, resulting in extended packet processing times and insufficient throughput. Therefore, hardware acceleration devices are needed to accelerate packet processing. Therefore, increasing packet throughput and improving transmission efficiency is a pressing technical challenge. Summary of the Invention

[0004] The embodiments of the present invention provide a data transmission method and device, which can improve the transmission efficiency of data packets.

[0005] A first aspect of an embodiment of the present invention discloses a data transmission method, which is applied to a daemon process in a host machine, wherein the host machine has a virtual machine deployed thereon, and the host machine also has a hardware accelerator and at least one virtual accelerator configured for the virtual machine deployed thereon, the method comprising:

[0006] Acquire information required for performing an acceleration operation in a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator;

[0007] Determining information that can be recognized by the hardware accelerator based on the information required to perform the acceleration operation;

[0008] The information that can be recognized by the hardware accelerator is sent to the hardware accelerator, and the hardware accelerator is used to obtain data to be accelerated according to the information that can be recognized by the hardware accelerator, and perform an acceleration operation on the data to be accelerated.

[0009] The information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address for storing the acceleration result, and the acceleration type parameter.

[0010] The hardware accelerator may be a multi-queue hardware accelerator (ie, supporting multiple virtual functions (VFs), each VF being equivalent to a hardware accelerator), or a single-queue hardware accelerator.

[0011] It can be seen that the information required to perform the acceleration operation adopts a predefined data structure, which occupies a unit item of the virtual input / output ring of the target virtual accelerator. This can greatly enhance the throughput capacity of the virtual input / output ring. More data packets can be transmitted per unit time, thereby improving the transmission efficiency of data packets.

[0012] In addition, the daemon process in the host machine runs in the vhost-user user state and directly accesses the hardware accelerator in the user state without going through the kernel protocol stack, thereby minimizing the number of context switches between the kernel state and the user state and reducing the switching overhead.

[0013] In a possible implementation, determining, based on the information required for performing the acceleration operation, the information recognizable by the hardware accelerator includes:

[0014] Determining the host physical address of the data to be accelerated according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host physical address;

[0015] The sending the information that can be recognized by the hardware accelerator to the hardware accelerator includes:

[0016] Sending the host physical address of the data to be accelerated to the hardware accelerator;

[0017] The hardware accelerator is configured to obtain the data to be accelerated from a virtual machine memory corresponding to a virtual machine physical address of the data to be accelerated according to a host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0018] In this possible implementation, since the mapping between virtual machine physical addresses and host physical addresses is pre-established, the hardware accelerator can identify the host physical addresses. Therefore, the virtual machine does not need to copy the data to be accelerated from virtual memory to the memory buffer, thus achieving zero-copy in the packet sending direction. Zero-copy in the packet sending direction means that when the virtual machine sends the information required to perform the acceleration operation to the hardware accelerator, it does not need to copy the data to be accelerated from the virtual machine memory to the memory buffer.

[0019] In one possible implementation, the hardware accelerator supports multiple virtual functions (VFs). After determining the host physical address of the data to be accelerated, the method further includes:

[0020] Querying the target VF bound to the target virtual accelerator from the preset binding relationship between the virtual accelerator and the VF;

[0021] The sending the host physical address of the data to be accelerated to the hardware accelerator comprises:

[0022] The host physical address of the data to be accelerated is sent to the target VF, and the target VF is used to obtain the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0023] The binding relationship between the virtual accelerator and the VF is established in advance, so that the virtual accelerators do not interfere with each other and the performance is optimized.

[0024] In one possible implementation, the method further includes:

[0025] After the data to be accelerated is accelerated, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator in the binding relationship.

[0026] In the case where the hardware accelerator supports multiple VFs, the identifier of the target virtual accelerator can be obtained from the binding relationship.

[0027] In a possible implementation, before obtaining information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator, the method further includes:

[0028] If the hardware accelerator supports multiple virtual functions (VFs), an unused target VF is selected from the multiple VFs, and a binding relationship between the target virtual accelerator and the target VF is established.

[0029] As can be seen, for multi-queue hardware accelerators, the above-mentioned bidirectional zero-copy solution (i.e., zero-copy in both the sending and receiving directions) achieves zero-copy performance across the entire accelerated data flow path, with virtually no additional CPU consumption. This allows the solution to retain the advantages of paravirtualization technology, such as VM portability and VNFC code portability (i.e., hardware-agnostic).

[0030] In one possible implementation, before sending the host physical address of the data to be accelerated to the hardware accelerator, the method further includes:

[0031] The identifier of the target virtual accelerator is recorded.

[0032] The identifier of the target virtual accelerator may be recorded at a specified location in the memory buffer.

[0033] In one possible implementation, the method further includes:

[0034] After the data to be accelerated is accelerated, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator according to the recorded identifier of the target virtual accelerator.

[0035] As can be seen, for a single-queue hardware accelerator, the above-mentioned bidirectional zero-copy solution (i.e., zero-copy in both the sending and receiving directions) achieves zero-copy performance across the entire accelerated data flow, with virtually no additional CPU consumption. This allows the solution to retain the advantages of paravirtualization technology, such as VM portability and VNFC code portability (i.e., hardware-agnostic performance).

[0036] In a possible implementation, determining, based on the information required for performing the acceleration operation, the information recognizable by the hardware accelerator includes:

[0037] Determining the host virtual address of the data to be accelerated in the virtual machine memory according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host virtual address;

[0038] Copying the data to be accelerated to a memory buffer according to the host virtual address of the data to be accelerated in the virtual machine memory;

[0039] Determining the host physical address of the data to be accelerated in the memory buffer according to the host virtual address of the data to be accelerated in the memory buffer and a preset mapping relationship between the host virtual address and the host physical address;

[0040] The sending the information that can be recognized by the hardware accelerator to the hardware accelerator includes:

[0041] The host physical address of the data to be accelerated is sent to the hardware accelerator.

[0042] The hardware accelerator is configured to obtain the data to be accelerated from the memory buffer according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0043] In this possible implementation, only the mapping relationship between the virtual machine's physical address and the host's virtual address is established in advance, and the mapping relationship between the virtual machine's physical address and the host's physical address is not established. Since the hardware accelerator can only recognize host physical addresses, it is necessary to convert the host virtual address of the data to be accelerated into the host physical address of the data to be accelerated that the hardware accelerator can recognize. In this method, the virtual machine needs to copy the data to be accelerated in the virtual memory to the memory buffer.

[0044] In one possible implementation, the method further includes:

[0045] After the data to be accelerated is accelerated, the generated acceleration result is copied to the memory of the virtual machine;

[0046] According to the identifier of the target virtual accelerator, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator.

[0047] Among them, after the data to be accelerated is accelerated, the daemon process in the host machine also needs to copy the generated acceleration result from the memory buffer to the virtual machine memory, so that the subsequent virtual machine can obtain the acceleration result from the virtual machine memory.

[0048] In a possible implementation, after adding the identifier of the unit item to the virtual input / output ring of the target virtual accelerator, the method further includes:

[0049] An interrupt request carrying an identifier of the target virtual accelerator is sent to a virtual machine corresponding to the target virtual accelerator, so as to trigger the virtual machine to query the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, and obtain an acceleration result generated after the data to be accelerated is accelerated.

[0050] Specifically, the daemon process in the host machine may use the eventfd mechanism of the Linux kernel to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator.

[0051] A second aspect of an embodiment of the present invention discloses a data transmission method, which is applied to a daemon process in a host machine, wherein the host machine has a virtual machine deployed thereon, and the host machine also has a hardware accelerator and at least one virtual accelerator configured for the virtual machine deployed thereon, the method comprising:

[0052] After the data to be accelerated is accelerated, an identifier of the target virtual accelerator is obtained;

[0053] Based on the identifier of the target virtual accelerator, an identifier of at least one unit item is added to a virtual input / output ring of the target virtual accelerator, so that the virtual machine can obtain an acceleration result generated after the data to be accelerated is accelerated based on the identifier of the at least one unit item, wherein the unit item stores information required to perform an acceleration operation on the data to be accelerated.

[0054] In one possible implementation, the hardware accelerator supports multiple virtual functions (VFs). After the accelerated data is accelerated and before obtaining the identifier of the target virtual accelerator, the method further includes:

[0055] Selecting an unused target VF from the multiple VFs, and establishing a binding relationship between the target virtual accelerator and the target VF;

[0056] The identifier of the target virtual accelerator is obtained from the binding relationship.

[0057] In a possible implementation, after the data to be accelerated is accelerated and before obtaining the identifier of the target virtual accelerator, the method further includes:

[0058] Record the ID of the target virtual accelerator.

[0059] In one possible implementation, the method of adding the identifier of at least one unit item to the virtual input / output ring of the target virtual accelerator based on the identifier of the target virtual accelerator so that the virtual machine obtains the acceleration result generated after the data to be accelerated is accelerated based on the identifier of the at least one unit item is specifically as follows:

[0060] adding, according to the identifier of the target virtual accelerator, the identifier of at least one unit item to the virtual input / output ring of the target virtual accelerator, and sending an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator, so that the virtual machine responds to the interrupt request, queries the identifier of at least one unit item in the virtual input / output ring of the target virtual accelerator, and obtains an acceleration result generated after the data to be accelerated is accelerated; or

[0061] Based on the identifier of the target virtual accelerator, the identifier of at least one unit item is added to the virtual input / output ring of the target virtual accelerator, so that the virtual machine automatically monitors the identifier of at least one unit item in the virtual input / output ring of the target virtual accelerator, and obtains, based on the identifier of at least one unit item, an acceleration result generated after the data to be accelerated is accelerated.

[0062] A third aspect of an embodiment of the present invention discloses a data transmission device, applied to a daemon process in a host machine, wherein the host machine has a virtual machine deployed thereon, and the host machine also has a hardware accelerator and at least one virtual accelerator configured for the virtual machine deployed thereon. The data transmission device includes a functional unit for executing some or all of the steps of any method of the first aspect of the embodiment of the present invention. The data transmission device can improve the transmission efficiency of data packets when executing some or all of the steps of any method of the first aspect.

[0063] A fourth aspect of an embodiment of the present invention discloses a data transmission device, applied to a daemon process in a host machine, wherein the host machine has a virtual machine deployed thereon, and the host machine also has a hardware accelerator and at least one virtual accelerator configured for the virtual machine deployed thereon. The data transmission device includes a functional unit for executing some or all of the steps of any method according to the second aspect of the embodiment of the present invention. The data transmission device can reduce CPU resource consumption when executing some or all of the steps of any method according to the second aspect.

[0064] A fifth aspect of the present invention discloses a host machine comprising a processor, a hardware accelerator, and a memory, wherein the memory is configured to store instructions, the processor is configured to execute the instructions, and the processor executes the instructions to perform some or all of the steps of any method according to the first aspect of the present invention. The host machine can improve data packet transmission efficiency when executing some or all of the steps of any method according to the first aspect.

[0065] A sixth aspect of the present invention discloses a host machine, comprising: a processor, a hardware accelerator, and a memory, wherein the memory is configured to store instructions, the processor is configured to execute the instructions, and the processor executes the instructions to perform some or all of the steps of any method according to the second aspect of the present invention. The host machine can improve data packet transmission efficiency when executing some or all of the steps of any method according to the second aspect.

[0066] A seventh aspect of an embodiment of the present invention discloses a computer storage medium, wherein the computer storage medium stores a program, and the program specifically includes instructions for executing part or all of the steps of any method of the first aspect of the embodiment of the present invention.

[0067] An eighth aspect of an embodiment of the present invention discloses a computer storage medium, wherein the computer storage medium stores a program, and the program specifically includes instructions for executing part or all of the steps of any method of the second aspect of the embodiment of the present invention.

[0068] In some feasible implementations, after adding the unit item identifier to the virtual input / output ring of the target virtual accelerator, the virtual machine can also monitor the virtual input / output ring of the target virtual accelerator to obtain the acceleration result generated after the accelerated data is processed. Specifically, the virtual machine can use a polling method to monitor the vring_used table of the virtual input / output ring of the target virtual accelerator in real time. If the vring_used table is updated, the virtual machine obtains the unit item identifier in the vring_used table, where the unit item has been accelerated. Furthermore, the virtual machine can obtain the virtual machine physical address storing the acceleration result from the vring_desc table of the virtual input / output ring based on the unit item identifier. Furthermore, the virtual machine can obtain the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result.

[0069] This approach generates no interruptions at all, preventing the virtual machine from interrupting service flow processing by executing interrupt handling operations, and thus improving VNF performance.

[0070] In some feasible implementations, the data structure used by the virtual machine to transmit the information required for acceleration operations occupies at least one element of the target virtual accelerator's virtual I / O ring, and a zero-copy solution is used for both transmission and reception. While this approach doesn't improve the throughput of the virtual I / O ring, it eliminates the need for memory copies in both directions, reducing CPU resource consumption compared to existing technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0072] Figure 1.1 This is a schematic diagram of the network architecture of an NFV system disclosed in an embodiment of the present invention;

[0073] Figure 1.2 This is a schematic diagram of a VM internal acceleration system architecture disclosed in an embodiment of the present invention;

[0074] Figure 1.3 This is a schematic diagram of a hypervisor internal acceleration system architecture disclosed in an embodiment of the present invention;

[0075] Figure 1.4 This is a schematic diagram of the network architecture of another NFV system disclosed in an embodiment of the present invention;

[0076] Figure 2 This is a flow chart of a data transmission method disclosed in an embodiment of the present invention;

[0077] Figure 2.1 This is a form of storing information required for performing an acceleration operation in Vring disclosed in an embodiment of the present invention;

[0078] Figure 2.2 This is another form of storing information required for performing acceleration operations in the Vring disclosed in an embodiment of the present invention;

[0079] Figure 3 is a flow chart of another data transmission method disclosed in an embodiment of the present invention;

[0080] Figure 4 is a flow chart of another data transmission method disclosed in an embodiment of the present invention;

[0081] Figure 5 It is a structural diagram of a data transmission device disclosed in an embodiment of the present invention;

[0082] Figure 6 is a structural diagram of another data transmission device disclosed in an embodiment of the present invention;

[0083] Figure 7 This is a structural diagram of a data transmission device disclosed in an embodiment of the present invention;

[0084] Figure 8 It is a schematic structural diagram of a host machine disclosed in an embodiment of the present invention;

[0085] Figure 9 It is a structural diagram of another host machine disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

[0086] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0087] The terms "first," "second," and "third," etc., in the specification and claims of the present invention and the accompanying drawings are used to distinguish between different items, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements, but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0088] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0089] The embodiments of the present invention disclose a data transmission method and apparatus, which can improve the transmission efficiency of data packets. Detailed descriptions are given below.

[0090] In order to better understand a data transmission method disclosed in an embodiment of the present invention, the network architecture applicable to the embodiment of the present invention is first described below.

[0091] See Figure 1.1 , Figure 1.1 1 is a schematic diagram of a network architecture of an NFV system disclosed in an embodiment of the present invention, wherein NFV (Virtualization, Network Function Virtualization). Figure 1.1 As shown, the NFV system includes: VNF (Virtualized Network Function), a virtual machine management program (Hypervisor) and general hardware.

[0092] Among them, VNF can include at least one VM (Virtual Manufacturing). Please refer to Figure 1.2 , Figure 1.2 This is a schematic diagram of a VM internal acceleration system architecture disclosed in an embodiment of the present invention. Figure 1.2As shown, the VM internal acceleration system includes a virtual network function application layer, an accelerator abstraction layer, an accelerator core layer, and a software input and output interface layer. The virtual network function application layer (Virtualization Network Function Applications) is for VMs that need to use virtual accelerators. The accelerator abstraction layer (Abstract Acceleration Layer, AAL) is mainly used to provide a common API (Application Programming Interface) interface layer for different virtual accelerators. The accelerator core layer (Acceleration Core, AC), such as DPDK (Data Plane Development Kit), ODP (Open Data Plane), or other high-performance acceleration software implementation frameworks, includes accelerator core layer specific interfaces (AC specific APIs, s-API) and front-end drivers configured for each virtual accelerator. A virtual accelerator is a virtualized form of a physical hardware accelerator and can be understood as a virtual hardware accelerator. Virtual machines can only see virtualized virtual accelerators, which are similar to virtual network cards and virtual disks. Examples of these virtual accelerators include VirtIO-crypto, VirtIO-IPsec, and VirtIO-compression. The software I / O interface (SIO) layer includes multiple virtual accelerator packet headers, such as the VirtIO-crypto header and the VirtIO-IPsec header. SIO, for example, is the interface between various virtual accelerator front-end drivers and back-end devices (hypervisors) for data transmission, such as the VirtIO (virtual I / O) interface.

[0093] The Hypervisor can simulate at least one virtual accelerator for each virtual machine. Figure 1.3 , Figure 1.3 This is a schematic diagram of a Hypervisor internal acceleration system architecture disclosed in an embodiment of the present invention. Figure 1.3As shown, the internal acceleration system of the Hypervisor includes a VirtIO backend accelerator, a VirtIO-based user-space interface, an accelerator core layer, and a physical accelerator layer. Among them, the VirtIO backend accelerator (backend device) is a virtual accelerator simulated by a virtual machine simulator (Qemu). The VirtIO-based user-space interface (User space based VirtIO interface, vHost-user) is a technology that adopts the vhost-user user-space solution to implement message forwarding based on the VirtIO interface through a high-speed data transmission channel between the virtual machine and the host. The accelerator core layer includes an accelerator core layer specified interface, hardware resource management, package management, and a general driver layer. Among them, the hardware resource management (hardware mgnt) supports ordinary hardware accelerators (referred to as single-queue hardware accelerators in the present invention) and hardware accelerators that support SR-IOV functions (referred to as multi-queue hardware accelerators in the present invention). For multi-queue hardware accelerators, a queue allocation and recovery mechanism is provided. The hardware accelerator that supports SR-IOV functions can virtualize multiple VFs (Virtual Functions), each VF corresponding to a hardware accelerator. Packet management (packet mgnt) leverages the AC's memory management mechanism to provide accelerated data packet identification for single-queue accelerators. The physical accelerator layer (Acceleration) includes various accelerator software, hardware, and CPU instruction acceleration resources.

[0094] General-purpose hardware includes, but is not limited to, CPUs (Central Processing Units) that can provide special instructions, SoC chips (System-on-a-Chip), and other hardware devices that can provide acceleration functions, such as GPUs (Graphics Processing Units) and FPGAs (Field-Programmable Gate Arrays). Acceleration refers to offloading some program functions to hardware for execution, thereby shortening program execution time.

[0095] See Figure 1.4 , Figure 1.4 This is a schematic diagram of the network architecture of an NFV system disclosed in an embodiment of the present invention, wherein: Figure 1.4 yes Figure 1.1 A specific form of. Figure 1.4As shown, each VM is configured with at least one virtual accelerator, and each virtual accelerator has a corresponding virtual accelerator front-end driver and Vring (Virtual I / O ring). The virtual accelerator front-end driver is located on the virtual machine side, and the virtual accelerator is located on the Hypervisor side. Figure 1.4 In the NFV system shown, the information required for data to be accelerated, sent by the VM's VNF, is driven by the virtual accelerator front-end. The virtual accelerator front-end driver assembles the information required for the data to be accelerated into the information required to perform the acceleration operation. The information required for performing the acceleration operation passes through the virtual accelerator's Vring, is parsed and processed by the daemon process, and is ultimately passed to the hardware accelerator. The hardware accelerator accelerates the data to be accelerated. The data to be accelerated may include, but is not limited to, network packets, storage packets, and files to be encrypted. The data to be accelerated is stored in memory (host memory or virtual machine memory). The daemon process polls and monitors the destination data packet generated after the accelerated data is processed. After the acceleration process is complete, the daemon process places the identifier of the destination data packet in the virtual accelerator's Vring usage table. The data packet is parsed and processed by the virtual accelerator front-end driver and ultimately passed to the VM's VNF. It should be noted that the information required to perform the acceleration operation does not include the data to be accelerated that needs to be accelerated, but only includes the information required to perform the acceleration operation, such as packet length, encryption and decryption algorithm type, key length, length of the data to be accelerated and related GPA (Guest Physical Address, virtual machine physical address, also known as client physical address), such as the GPA of the data to be accelerated, the GPA for storing the acceleration results, etc.

[0096] Optionally, if the hardware accelerator supports multiple VFs, when creating a virtual accelerator for the VM, an unused VF is immediately bound to the virtual accelerator on the Hypervisor side. In this way, the data packets received from the specified VF can notify the virtual machine corresponding to the virtual accelerator without the need for memory copying. Optionally, if the hardware accelerator is an ordinary single-queue hardware accelerator, when sending data packets, the Hypervisor side uses the specified location of the mbuf (Memory Buffer) structure (such as a 4-byte offset) to record the virtual machine's virtual accelerator identifier. After the hardware accelerator completes the accelerated processing of the data to be accelerated, the Hypervisor side retrieves the virtual accelerator identifier recorded in the mbuf structure and can notify the virtual machine corresponding to the virtual accelerator without the need for memory copying.

[0097] See Figure 2 , Figure 2This is a flow chart of a data transmission method disclosed in an embodiment of the present invention, wherein the method is written from multiple sides such as a virtual machine, a daemon process in a host machine, and a hardware accelerator, and the method adopts a bidirectional zero copy technology. Figure 2 As shown, the method may include the following steps.

[0098] 201. If the hardware accelerator supports multiple virtual functions (VFs), the daemon process in the host machine selects an unused target VF from the multiple VFs and establishes a binding relationship between the target virtual accelerator and the target VF.

[0099] In an embodiment of the present invention, a host machine is deployed with a virtual machine, a hardware accelerator, and at least one virtual accelerator configured for the virtual machine. The hardware accelerator can be a single-queue hardware accelerator or a multi-queue hardware accelerator (i.e., the hardware accelerator supports multiple virtual functions (VFs), with each VF corresponding to a hardware accelerator).

[0100] If the hardware accelerator supports multiple VFs, the daemon process in the host machine can select an unused target VF from the multiple VFs during the initialization phase and establish a binding relationship between the target virtual accelerator and the target VF, wherein the target VF can be any unused VF.

[0101] It should be noted that, in the embodiment of the present invention, multiple binding relationships can be established. After multiple binding relationships are established, the virtual accelerators do not interfere with each other and the performance is optimized.

[0102] As an optional implementation, before step 201, the method further includes the following steps:

[0103] 11) Start the daemon process and full polling service on the host machine.

[0104] 12) The daemon process on the host creates a memory buffer pool.

[0105] 13) Configure at least one virtual accelerator for the virtual machine.

[0106] 14) Virtual machine emulator (Qemu) creates a virtual machine.

[0107] 15) Qemu sends the physical memory address layout of the virtual machine to the daemon process on the host machine through the vhost-user protocol.

[0108] 16) The daemon process in the host machine establishes a mapping relationship between the GPA and the host physical address HPA, and also establishes a mapping relationship between the GPA and the host virtual address HVA according to the physical memory address layout of the virtual machine.

[0109] In this optional implementation, the daemon process in the host machine also serves as a service of the host machine and starts automatically after the host machine is turned on. After the daemon process in the host machine is started, it immediately scans the hardware accelerator, initializes the hardware accelerator management structure, creates a memory buffer pool, and registers the vhost-user server listening port. The administrator configures at least one virtual accelerator (which can be called a target virtual accelerator) for the virtual machine, and starts the QEMU process to create a virtual machine. The QEMU process sends a Unix message to the daemon process through the vhost-user protocol; after receiving the message sent by the QEMU process, the daemon process in the host machine creates a server-side virtual accelerator. The QEMU process sends the physical memory address layout of the virtual machine to the daemon process in the host machine through the vhost-user protocol. After receiving the message, the daemon process in the host machine establishes a mapping relationship between the GPA and the host physical address HPA based on the physical memory address layout of the virtual machine, and establishes a mapping relationship between the GPA and the host virtual address HVA.

[0110] 202. The virtual machine adds information required to perform the acceleration operation to a predefined data structure.

[0111] The information required to perform the acceleration operation may include but is not limited to the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address where the acceleration result is stored, and acceleration type parameters (such as algorithm type, operation type), etc.

[0112] Common acceleration functions include encryption and decryption, compression / decompression, audio and video encoding and decoding, and packet processing. For example, if a symmetric encryption operation with associated data is to be performed, the information that needs to be passed to the hardware accelerator (i.e., the information required to perform the acceleration operation) includes: the initialization vector (iv addr), the associated data (auth_data addr), the source data to be encrypted (src_data addr), the memory for storing the encryption result (dst_data addr), the memory for storing the digest result (digest_result addr), and the memory for storing the encryption, decryption, and verification success flags (inhdr addr). The data to be accelerated can include, but is not limited to, network packets, storage packets, and files to be encrypted. All data to be accelerated is stored in memory (host memory or VM memory).

[0113] In the prior art, such a data packet encryption and decryption requires six entries in the virtual accelerator's virtual input / output ring (Virtual I / O ring, Vring). Figure 2.1 , Figure 2.1 This is a storage format of information required for performing acceleration operations in Vring disclosed in an embodiment of the present invention. Figure 2.1 As shown in the figure, for example, the information required for acceleration is encryption and decryption data packets. Six data parameters need to be passed to the hardware accelerator, each of which occupies one Vring entry. Assuming the size of the Vring created for the encryption and decryption virtual accelerator is 4096, the maximum number of encryption and decryption packets that can be stored at one time is 682 (4096 / 6).

[0114] In an embodiment of the present invention, in order to improve the throughput of data packets, a data structure is pre-defined for the information required for each acceleration operation. The data structure includes the information required for the data to be accelerated, such as: the virtual machine physical address (Guest Physical Address, GPA) address and length information of the data to be accelerated, where GPA can also be called the client physical address.

[0115] Taking the encryption and decryption virtual accelerator as an example, the following data structure is defined for symmetric encryption and decryption operations:

[0116]

[0117] The virtualized network function (VNF) application simply passes the parameter information recorded in the struct virtio_crypto_sym_op_data to the front-end driver of the encryption and decryption virtual accelerator according to the above data structure. The front-end driver of the encryption and decryption virtual accelerator directly assigns the value of the struct virtio_crypto_sym_op_data data structure and then adds this data structure as a unit item (i.e., entry item) to the virtual accelerator's Vring. Therefore, for the encryption and decryption virtual accelerator, each symmetric encryption and decryption algorithm only needs to occupy one item in the Vring.

[0118] vring_desc.addr = GPA address of struct virtio_crypto_sym_op_data

[0119] vring_desc.len=sizeof(struct virtio_crypto_sym_op_data)

[0120] vring_desc.flag = ~NEXT

[0121] Please join us Figure 2.2 , Figure 2.2 This is another form of storing the information required for performing the acceleration operation in the Vring ring disclosed in the embodiment of the present invention. Figure 2.2It can be seen that this data structure occupies one unit item (i.e. one entry) of the virtual input / output ring of the virtual accelerator; a Vring of size 4096 can store 4096 encrypted and decrypted data packets at a time. Figure 2.2 The storage format of the source data in the Vring is relative to Figure 2.1 The traditional solution shown in the figure has a performance improvement of 5 times, effectively enhancing the data packet throughput of the virtual input / output ring.

[0122] 203. The virtual machine stores the data structure in the virtual input / output ring of the target virtual accelerator.

[0123] In the embodiment of the present invention, the target virtual accelerator is any one of multiple virtual accelerators configured for the virtual machine, and for the convenience of subsequent description, is referred to as the target virtual accelerator.

[0124] Specifically, the VM's VNF calls the virtual accelerator front-end driver API and passes the information required for acceleration (including the GPA of the data to be accelerated and the GPA of the acceleration results). The front-end driver allocates a memory buffer in the memory buffer pool and uses this information to construct the information required for acceleration. Finally, the front-end driver calls the VirtIO API and stores the GPA and length of the information required for acceleration in the vring_desc table of the Vring.

[0125] In this embodiment of the present invention, the Vring shared area has three tables: a vring_desc table for storing addresses of IO requests generated by virtual machines; a vring_avail table for indicating which items in vring_desc are available; and a vring_used table for indicating which items in vring_desc have been submitted to the hardware.

[0126] The vring_desc table stores the addresses of IO requests generated by the virtual machine in the virtual machine memory (such as the GPA address). Each row in this table contains four fields: Addr, len, flags, and next. As shown below:

[0127] struct vring_desc{

[0128] / *Address(guest-physical).* /

[0129] __virtio64 addr;

[0130] / *Length.* /

[0131] __virtio32 len;

[0132] / *The flags as indicated above.* /

[0133] __virtio16 flags;

[0134] / *We chain unused descriptors via this,too* /

[0135] __virtio16 next;

[0136] };

[0137] Addr stores the memory address of the IO request within the virtual machine, typically a GPA value; len represents the length of the IO request in memory; flags indicates whether the data in this row is readable or writable, and whether it is the last item in an IO request; each IO request may contain multiple rows in the vring_desc table, and the next field indicates the row of the next item in the IO request. Using next, multiple rows stored in vring_desc for an IO request are linked together into a linked list. When flag = ~VRING_DESC_F_NEXT, the linked list has reached its end.

[0138] For the vring_avail table, it stores the header position of the linked list of each IO request in vring_desc. The data structure is as follows:

[0139] struct vring_avail{

[0140] __virtio16 flags;

[0141] __virtio16 idx;

[0142] __virtio16 ring[];

[0143] };

[0144] Among them, in the vring_desc table, the position of the head of the linked list connected by the next field in the vring_desc table is stored in the ring[] array; idx points to the next available free position in the ring array; flags is a flag field.

[0145] For the vring_used table, after the data to be accelerated is processed, the daemon process on the host machine can update this data structure:

[0146] / *u32 is used here for ids for padding reasons.* /

[0147] struct vring_used_elem{

[0148] / *Index of start of used descriptor chain.* /

[0149] __virtio32 id;

[0150] / *Total length of the descriptor chain which was used(written to)* /

[0151] __virtio32 len;

[0152] };

[0153] struct vring_used{

[0154] __virtio16 flags;

[0155] __virtio16 idx;

[0156] struct vring_used_elem ring[];

[0157] };

[0158] The ring[] array in vring_uesd has two members: id and len. id represents the head node of the linked list of completed I / O requests in the vring_desc table; len represents the length of the linked list. idx points to the next available location in the ring array; and flags represents the flags.

[0159] 204. The daemon process in the host machine obtains information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator.

[0160] In this embodiment of the present invention, a daemon process in the host machine runs in vhost-user user mode, directly accessing the hardware accelerator in user mode without going through the kernel protocol stack, minimizing the number of context switches between kernel mode and user mode and reducing switching overhead. The daemon process in the host machine is located in the hypervisor.

[0161] Optionally, the specific implementation method of the daemon process in the host machine obtaining the information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator may be:

[0162] The daemon process in the host machine uses a full polling method to monitor the virtual input / output ring of each virtual accelerator in real time to obtain the information required for performing acceleration operations in the virtual input / output ring of the target virtual accelerator.

[0163] In this optional implementation, the daemon process in the host machine can use a full polling method to monitor the vring_desc table in the virtual input / output ring of each virtual accelerator in real time to obtain the information required for performing acceleration operations from the vring_desc table in the virtual input / output ring. This method reduces CPU resource consumption.

[0164] Optionally, the specific implementation method of the daemon process in the host machine obtaining the information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator may be:

[0165] The virtual machine sends an information acquisition notification carrying the identifier of the target virtual accelerator to the daemon process in the host machine. The daemon process in the host machine acquires information required for performing the acceleration operation from the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator.

[0166] In this optional implementation, specifically, the virtual machine sends an information acquisition notification carrying the identifier of the target virtual accelerator to the daemon process in the host machine. After receiving the information acquisition notification, the daemon process in the host machine retrieves information required for performing the acceleration operation from the vring_desc table of the virtual input / output ring of the target virtual accelerator based on the identifier of the target virtual accelerator.

[0167] 205. The daemon process in the host machine determines the host physical address of the data to be accelerated according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host physical address.

[0168] In the embodiment of the present invention, the hardware accelerator can only recognize the host physical address (HPA). The memory address transmitted by the virtual machine to the daemon process in the host machine is the guest physical address (GPA) of the data to be accelerated, which cannot be directly passed to the hardware accelerator for use.

[0169] During the initialization phase, the daemon process in the host machine has already established a mapping relationship between the GPA and the HPA. With this mapping relationship in place, subsequent processing of the data to be accelerated can be performed without memory copying (i.e., zero copy), with only a simple address translation. For example, the data to be accelerated is initially stored in the VM memory corresponding to the GPA. After the daemon process in the host machine establishes a mapping relationship between the GPA and the HPA, the VM does not need to copy the data to be accelerated in the VM memory to the memory buffer corresponding to the host virtual address (HVA). Instead, it only needs to convert the GPA to the HPA to obtain the data to be accelerated from the memory buffer corresponding to the HPA.

[0170] 206. The daemon process in the host machine queries the target VF bound to the target virtual accelerator from the preset binding relationship between the virtual accelerator and the VF.

[0171] In an embodiment of the present invention, a hardware accelerator that supports SR-IOV functionality can virtualize multiple VFs (Virtual Functions), with each VF corresponding to a hardware accelerator. SR-IOV (Single-Root I / O Virtualization) technology is a hardware-based virtualization solution that improves performance and scalability. The SR-IOV standard allows for efficient sharing of PCIe (Peripheral Component Interconnect Express) devices between virtual machines, and it is implemented in hardware to achieve I / O performance comparable to that of the host machine.

[0172] The two new function types in SR-IOV are: Physical Function (PF) A PCI function used to support SR-IOV functionality, as defined in the SR-IOV specification. The PF contains the SR-IOV capability structure used to manage SR-IOV functions. A PF is a fully functional PCIe function that can be discovered, managed, and processed like any other PCIe device. A PF has full configuration resources and can be used to configure or control PCIe devices. VF A function associated with a physical function. A VF is a lightweight PCIe function that can share one or more physical resources with a physical function and other VFs associated with the same physical function. A VF is only allowed to have configuration resources for its own behavior.

[0173] Each SR-IOV device can have one PF, and each PF can have up to 64,000 VFs associated with it. PFs can create VFs through registers that have properties designed specifically for this purpose.

[0174] In the embodiment of the present invention, the binding relationship between the virtual accelerator and the VF has been established in the initialization phase. At this time, the daemon process in the host machine can query the target VF bound to the target virtual accelerator from the preset binding relationship between the virtual accelerator and the VF.

[0175] 207. The daemon process in the host sends the host physical address of the data to be accelerated to the target VF.

[0176] Specifically, the daemon process in the host machine can call the Application Programming Interface (API) of the hardware accelerator to send the host physical address of the data to be accelerated to the target VF.

[0177] 208. The target VF obtains the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and performs an acceleration operation on the data to be accelerated.

[0178] In an embodiment of the present invention, after the target VF receives the host physical address of the data to be accelerated, the hardware accelerator driver will obtain the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address HPA of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0179] 209. After the data to be accelerated is accelerated, the daemon process in the host machine adds the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator in the binding relationship.

[0180] In the embodiment of the present invention, due to the use of zero-copy technology, when the VM sends the information required to perform the acceleration operation, it is not necessary to copy the data to be accelerated in the virtual machine memory corresponding to the GPA to the memory buffer corresponding to the HVA. Therefore, the data to be accelerated and the acceleration results generated after the accelerated data are accelerated are both stored in the virtual machine memory corresponding to the GPA. The daemon process in the host machine can poll and monitor whether the target VF has completed the acceleration processing operation on the data to be accelerated. If it is detected that it has been completed, the daemon process in the host machine can add the unit item identifier to the vring_used table of the virtual input / output ring of the target virtual accelerator based on the identifier of the target virtual accelerator in the binding relationship.

[0181] 210. The virtual machine monitors the virtual input / output ring of the target virtual accelerator to obtain an acceleration result generated after the to-be-accelerated data is accelerated.

[0182] Specifically, in this optional implementation, the virtual machine can poll the vring_used table of the target virtual accelerator's virtual input / output ring in real time. If the vring_used table is updated, the virtual machine obtains the identifier of a unit item in the vring_used table, where the unit item indicates that acceleration has been completed. Furthermore, based on the unit item identifier, the virtual machine can obtain the virtual machine physical address storing the acceleration result from the vring_desc table of the virtual input / output ring. Furthermore, the virtual machine can obtain the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result. Optionally, the virtual machine can also perform further processing on the acceleration result, such as sending the acceleration result to the network.

[0183] The automatic monitoring of the virtual input / output ring of the target virtual accelerator by the virtual machine is beneficial to reducing interruption overhead and saving resources.

[0184] As another optional implementation, step 210 may be omitted and replaced by the following steps:

[0185] 21) The daemon process in the host machine sends an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator;

[0186] 22) The virtual machine queries the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator;

[0187] 23) The virtual machine obtains the virtual machine physical address storing the acceleration result according to the identifier of the unit item, and obtains the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result.

[0188] In this optional embodiment, after the daemon process in the host machine adds the identifier of the accelerated unit item to the virtual input / output ring of the target virtual accelerator, the daemon process in the host machine can use the eventfd mechanism of the Linux kernel to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator. When the virtual machine is created, the Qemu process creates an eventfd (event handle) for the virtual accelerator's Vring ring.

[0189] After receiving the interrupt request, the virtual machine can stop executing the current program and instead query the identifier of the unit item in the vring_used table of the virtual input / output ring of the target virtual accelerator based on the identifier of the target virtual accelerator. Based on the identifier of the unit item, the virtual machine physical address storing the acceleration result is obtained from the vring_desc table of the virtual input / output ring of the target virtual accelerator. Furthermore, the virtual machine can obtain the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result.

[0190] It can be seen that the embodiment of the present invention adopts a two-way zero-copy scheme for sending and receiving (i.e., zero copy in the packet sending direction and zero copy in the packet receiving direction), and the entire accelerated data flow has zero copy in the entire path, with almost no additional CPU consumption. This allows the solution of the present invention to retain the advantages of semi-virtualization technology, such as the portability of VM and the portability of VNFC code (i.e., hardware insensitivity). Among them, zero copy in the packet sending direction means that in the process of the virtual machine sending the information required to perform the acceleration operation to the hardware accelerator, there is no need to copy the data to be accelerated in the virtual machine memory to the memory buffer, and zero copy in the packet receiving direction means that after the hardware accelerator has accelerated the data to be accelerated, the generated acceleration result does not need to be copied from the memory buffer to the virtual machine memory. Throughout the process, the data to be accelerated and the acceleration result are always in the virtual machine memory.

[0191] It should be noted that the daemon process in the above-mentioned host machine is applicable to various types of virtual machines.

[0192] exist Figure 2 In the described method flow, the information required to perform the acceleration operation sent by the virtual machine adopts a predefined data structure. This data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator. This can greatly enhance the throughput capacity of the virtual input / output ring. In a unit time, more data packets can be transmitted, thereby improving the transmission efficiency of data packets.

[0193] See Figure 3 , Figure 3 This is a flow chart of another data transmission method disclosed in an embodiment of the present invention, wherein the method is written from multiple sides such as a virtual machine, a daemon process in a host machine, and a hardware accelerator, and the method adopts a bidirectional copy technology. Figure 3 As shown, the method may include the following steps.

[0194] 301. The virtual machine adds information required to perform the acceleration operation to a predefined data structure.

[0195] 302. The virtual machine puts information required to perform the acceleration operation into the virtual input / output ring of the target virtual accelerator.

[0196] 303. The daemon process in the host machine obtains information required for performing acceleration operations in the virtual input / output ring of the target virtual accelerator.

[0197] 304. The daemon process in the host machine determines the host physical address of the data to be accelerated according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host physical address.

[0198] The above steps 301-304 can be specifically referred to Figure 2 It should be noted that, in the embodiment of the present invention, the hardware accelerator is a single-queue hardware accelerator.

[0199] 305. The daemon process in the host machine records the identifier of the target virtual accelerator.

[0200] Specifically, the daemon process in the host machine can record the identifier of the target virtual accelerator in a space offset by 4 bytes in the head of the structure of the memory buffer, where the memory buffer is any one of the memory buffer pools applied for during the initialization phase.

[0201] 306. The daemon process in the host machine sends the host physical address of the data to be accelerated to the hardware accelerator.

[0202] 307. The hardware accelerator obtains the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and performs an acceleration operation on the data to be accelerated.

[0203] 308. After the data to be accelerated is accelerated, the daemon process in the host machine adds the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the recorded identifier of the target virtual accelerator.

[0204] Specifically, after the data to be accelerated is processed by the hardware accelerator, the daemon process in the host machine can query the identifier of the target virtual accelerator recorded in the space offset 4 bytes from the structure header of the memory buffer, and add the identifier of the unit item for which acceleration has been completed to the vring_used table of the virtual input / output ring of the target virtual accelerator.

[0205] 309. The daemon process in the host machine sends an interrupt request carrying an identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator.

[0206] Specifically, the daemon process in the host machine can use the eventfd mechanism of the Linux kernel to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator. When the virtual machine is created, the Qemu process creates an eventfd (event handle) for the Vring ring of the virtual accelerator.

[0207] 310. The virtual machine queries the identifier of a unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator.

[0208] After receiving the interrupt request, the virtual machine may stop executing the current program and query the identifier of the unit item in the vring_used table of the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator.

[0209] 311. The virtual machine obtains the virtual machine physical address storing the acceleration result according to the identifier of the unit item, and obtains the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result.

[0210] Specifically, the virtual machine can retrieve the virtual machine physical address storing the acceleration result from the vring_desc table of the target virtual accelerator's virtual input / output ring based on the unit item identifier, and then retrieve the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result. Optionally, the virtual machine can also perform further processing on the acceleration result, such as sending the acceleration result to the network.

[0211] As another optional implementation, steps 309 to 311 may not be performed, and the following steps may be performed:

[0212] The virtual machine monitors the virtual input / output ring of the target virtual accelerator to obtain an acceleration result generated after the accelerated data is accelerated.

[0213] Specifically, in this optional implementation, the virtual machine can poll the vring_used table of the target virtual accelerator's virtual input / output ring in real time. If the vring_used table is updated, the virtual machine obtains the identifier of a unit item in the vring_used table, where the unit item indicates that acceleration has been completed. Furthermore, based on the unit item identifier, the virtual machine can obtain the virtual machine physical address storing the acceleration result from the vring_desc table of the virtual input / output ring. Furthermore, the virtual machine can obtain the acceleration result from the virtual machine memory corresponding to the virtual machine physical address storing the acceleration result. Optionally, the virtual machine can also perform further processing on the acceleration result, such as sending the acceleration result to the network.

[0214] The automatic monitoring of the virtual input / output ring of the target virtual accelerator by the virtual machine is beneficial to reducing interruption overhead and saving resources.

[0215] exist Figure 3 In the described method flow, the information required to perform the acceleration operation sent by the virtual machine adopts a predefined data structure. This data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator, which can greatly enhance the throughput capacity of the virtual input / output ring. More data packets are transmitted per unit time, thereby improving the transmission efficiency of data packets. At the same time, the hardware accelerator is a single-queue hardware accelerator, which uses a method of recording the identifier of the target virtual accelerator to achieve zero copy of the entire accelerated data flow path, with almost no additional CPU consumption. This also enables the solution of the present invention to retain the advantages of paravirtualization technology, such as the portability of VMs and the portability of VNFC codes (i.e., hardware insensitivity).

[0216] See Figure 4 , Figure 4 This is a flow chart of another data transmission method disclosed in an embodiment of the present invention, wherein the method is written from multiple sides such as a virtual machine, a daemon process in a host machine, and a hardware accelerator, and the method adopts a bidirectional copy technology. Figure 4 As shown, the method may include the following steps.

[0217] 401. If the hardware accelerator supports multiple virtual functions (VFs), the daemon process in the host machine selects an unused target VF from the multiple VFs and establishes a binding relationship between the target virtual accelerator and the target VF.

[0218] 402. The virtual machine adds information required to perform the acceleration operation to a predefined data structure.

[0219] 403. The virtual machine stores the data structure in a virtual input / output ring of the target virtual accelerator.

[0220] 404. The daemon process in the host machine obtains information required for performing acceleration operations in the virtual input / output ring of the target virtual accelerator.

[0221] 405. The daemon process in the host machine determines the host virtual address of the data to be accelerated in the virtual machine memory according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and the preset mapping relationship between the virtual machine physical address and the host virtual address.

[0222] In this embodiment of the present invention, the daemon process in the host machine can only recognize the HVA, but not the virtual machine physical address (GPA). Therefore, during the initialization phase, a mapping relationship between the virtual machine physical address (GPA) and the host virtual address (HVA) is pre-established. Once the daemon process in the host machine obtains the virtual machine physical address (GPA) of the data to be accelerated, it can determine the host virtual address of the data to be accelerated based on the established mapping relationship between the virtual machine physical address and the host virtual address.

[0223] It should be noted that, in the embodiment of the present invention, during the initialization phase, the mapping relationship between the virtual machine physical address GPA and the host physical address HPA is not established, and only the mapping relationship between the GPA and the HVA is established.

[0224] 406. The daemon process in the host machine copies the data to be accelerated to the memory buffer according to the host virtual address of the data to be accelerated in the memory of the virtual machine.

[0225] In the embodiment of the present invention, since the mapping relationship between the virtual machine physical address GPA and the host physical address HPA is not established, the daemon process in the host machine needs to copy the data to be accelerated to the memory buffer according to the host virtual address of the data to be accelerated in the virtual machine memory to facilitate subsequent address conversion.

[0226] 407. The daemon process in the host machine determines the host physical address of the data to be accelerated in the memory buffer according to the host virtual address of the data to be accelerated in the memory buffer and a preset mapping relationship between the host virtual address and the host physical address.

[0227] In an embodiment of the present invention, during the initialization phase, a mapping relationship between GPA and HPA is not established, and the hardware accelerator can only identify the host physical address HPA of the data to be accelerated. The daemon process in the host machine needs to convert the host virtual address HVA of the data to be accelerated in the memory buffer into the host physical address HPA of the data to be accelerated in the memory buffer that can be identified by the hardware accelerator.

[0228] Specifically, the daemon process in the host machine can query the HPA corresponding to the HVA of the data to be accelerated in the memory buffer according to the / proc / pid / pagemap file in the Linux system.

[0229] 408. The daemon process in the host sends the host physical address of the data to be accelerated to the target VF.

[0230] 409. The target VF obtains the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and performs an acceleration operation on the data to be accelerated.

[0231] 410. After the data to be accelerated is accelerated, the daemon process in the host machine copies the generated acceleration result to the virtual machine memory.

[0232] Specifically, after the data to be accelerated is accelerated, the daemon process in the host machine also needs to copy the generated acceleration result from the memory buffer to the virtual machine memory so that the virtual machine can subsequently obtain the acceleration result from the virtual machine memory.

[0233] 411. The daemon process in the host machine adds the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator.

[0234] 412. The virtual machine monitors the virtual input / output ring of the target virtual accelerator to obtain an acceleration result generated after the accelerated data is accelerated.

[0235] exist Figure 4 In the described method flow, the information required to perform the acceleration operation sent by the virtual machine adopts a predefined data structure. This data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator. This can greatly enhance the throughput capacity of the virtual input / output ring. In a unit time, more data packets can be transmitted, thereby improving the transmission efficiency of data packets.

[0236] See Figure 5 , Figure 5 is a structural diagram of a data transmission device disclosed in an embodiment of the present invention, wherein the data transmission device 500 can be used to perform Figure 2 For details of all or part of the steps in the disclosed data transmission method, please refer to Figure 2 As described above, I will not repeat it here. Figure 5 As shown, the data transmission device 500 may include:

[0237] An acquiring unit 501 is configured to acquire information required for performing an acceleration operation in a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator;

[0238] The information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address for storing the acceleration result, and the acceleration type parameter.

[0239] A determining unit 502 is configured to determine information that can be recognized by the hardware accelerator based on the information required to perform the acceleration operation;

[0240] The sending unit 503 is configured to send information that can be recognized by the hardware accelerator to the hardware accelerator. The hardware accelerator is configured to obtain data to be accelerated according to the information that can be recognized by the hardware accelerator and perform an acceleration operation on the data to be accelerated.

[0241] As an optional implementation manner, the determining unit 502 determines the information that can be recognized by the hardware accelerator according to the information required for performing the acceleration operation in the following manner:

[0242] Determining the host physical address of the data to be accelerated according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host physical address;

[0243] The sending unit 503 sends the information that can be recognized by the hardware accelerator to the hardware accelerator in the following manner:

[0244] Sending the host physical address of the data to be accelerated to the hardware accelerator;

[0245] The hardware accelerator is configured to obtain the data to be accelerated from a virtual machine memory corresponding to a virtual machine physical address of the data to be accelerated according to a host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0246] As an optional implementation, the hardware accelerator supports multiple virtual functions VF, Figure 5 The data transmission device 500 shown further includes:

[0247] a query unit 504 configured to query a target VF bound to the target virtual accelerator from a preset binding relationship between virtual accelerators and VFs after the determination unit 502 determines the host physical address of the data to be accelerated;

[0248] The sending unit 503 sends the host physical address of the data to be accelerated to the hardware accelerator in the following manner:

[0249] The host physical address of the data to be accelerated is sent to the target VF, and the target VF is used to obtain the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0250] As another optional implementation, Figure 5 The data transmission device 500 shown further includes:

[0251] The first adding unit 505 is configured to add the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator in the binding relationship after the data to be accelerated is accelerated.

[0252] As another optional implementation, Figure 5 The data transmission device 500 shown further includes:

[0253] An establishing unit 506 is configured to, before the acquiring unit 501 acquires the information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator, select an unused target VF from the multiple virtual functions VF if the hardware accelerator supports the multiple VFs, and establish a binding relationship between the target virtual accelerator and the target VF.

[0254] As an optional implementation, the sending unit 503 is further used to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator, so as to trigger the virtual machine to query the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, and obtain the acceleration result generated after the data to be accelerated is accelerated.

[0255] See Figure 6 , Figure 6 is a structural diagram of another data transmission device disclosed in an embodiment of the present invention, wherein the data transmission device 600 can be used to perform Figure 3 For details of all or part of the steps in the disclosed data transmission method, please refer to Figure 3 As described above, I will not repeat it here. Figure 6 As shown, the data transmission device 600 may include:

[0256] An acquiring unit 601 is configured to acquire information required for performing an acceleration operation in a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator;

[0257] The information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address for storing the acceleration result, and the acceleration type parameter.

[0258] A determining unit 602 is configured to determine information that can be recognized by the hardware accelerator based on the information required to perform the acceleration operation;

[0259] The sending unit 603 is configured to send information that can be recognized by the hardware accelerator to the hardware accelerator. The hardware accelerator is configured to obtain data to be accelerated according to the information that can be recognized by the hardware accelerator and perform an acceleration operation on the data to be accelerated.

[0260] As an optional implementation, Figure 6 The data transmission device 600 shown further includes:

[0261] The recording unit is configured to record the identifier of the target virtual accelerator before the sending unit 603 sends the host physical address of the data to be accelerated to the hardware accelerator.

[0262] As an optional implementation, Figure 6 The data transmission device 600 shown further includes:

[0263] The second adding unit 605 is configured to add the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the recorded identifier of the target virtual accelerator after the data to be accelerated is accelerated.

[0264] As an optional implementation, the sending unit 603 is further used to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator, so as to trigger the virtual machine to query the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, and obtain the acceleration result generated after the data to be accelerated is accelerated.

[0265] See Figure 7 , Figure 7 is a structural diagram of another data transmission device disclosed in an embodiment of the present invention, wherein the data transmission device 700 can be used to perform Figure 2 or Figure 4 For details of some steps in the disclosed data transmission method, please refer to Figure 2 or Figure 4 As described above, I will not repeat it here. Figure 7 As shown, the data transmission device 700 may include:

[0266] An acquiring unit 701 is configured to acquire information required for performing an acceleration operation in a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator;

[0267] The information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address for storing the acceleration result, and the acceleration type parameter.

[0268] A determining unit 702 is configured to determine information that can be recognized by the hardware accelerator based on the information required to perform the acceleration operation;

[0269] The sending unit 703 is configured to send information that can be recognized by the hardware accelerator to the hardware accelerator. The hardware accelerator is configured to obtain data to be accelerated according to the information that can be recognized by the hardware accelerator and perform an acceleration operation on the data to be accelerated.

[0270] As an optional implementation, the determining unit 702 includes:

[0271] a determination subunit 7021, configured to determine the host virtual address of the data to be accelerated in the virtual machine memory based on the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host virtual address;

[0272] The copy subunit 7022 is configured to copy the data to be accelerated to a memory buffer according to the host virtual address of the data to be accelerated in the virtual machine memory;

[0273] The determining subunit 7021 is further configured to determine the host physical address of the data to be accelerated in the memory buffer according to the host virtual address of the data to be accelerated in the memory buffer and a preset mapping relationship between the host virtual address and the host physical address;

[0274] The sending unit 703 is specifically configured to send the host physical address of the data to be accelerated to the hardware accelerator.

[0275] The hardware accelerator is configured to obtain the data to be accelerated from the memory buffer according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0276] As an optional implementation, Figure 7 The data transmission device 700 shown further includes:

[0277] The copy unit 704 is configured to copy the generated acceleration result to the virtual machine memory after the acceleration processing of the data to be accelerated is completed;

[0278] The third adding unit 705 is configured to add the identifier of the unit item to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator.

[0279] As an optional implementation, the sending unit 703 is further used to send an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator, so as to trigger the virtual machine to query the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, and obtain the acceleration result generated after the data to be accelerated is accelerated.

[0280] exist Figures 5 to 7 In the described data transmission device, the information required to perform the acceleration operation sent by the virtual machine still adopts a predefined data structure. This data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator. This can greatly enhance the throughput capacity of the virtual input / output ring. In a unit time, more data packets can be transmitted, thereby improving the transmission efficiency of data packets.

[0281] See Figure 8 , Figure 8 is a schematic diagram of the structure of a host machine disclosed in an embodiment of the present invention, wherein the host machine 800 can be used to execute Figures 2 to 4 For details of all or part of the steps in the disclosed data transmission method, please refer to Figures 2 to 4 As described above, I will not repeat it here. Figure 8 As shown, the host machine 800 may include: at least one processor 801, such as a CPU (Central Processing Unit), a hardware accelerator 802, and a memory 803, wherein the processor 801, the hardware accelerator 802, and the memory 803 are respectively connected to a communication bus. The memory 803 may be a high-speed RAM memory or a non-volatile memory. Those skilled in the art will understand that Figure 8 The structure of the host machine 800 shown in the figure does not constitute a limitation of the present invention. It can be a bus structure, a star structure, or a plurality of other structures. Figure 8 More or fewer components may be shown, or certain components may be combined, or the components may be arranged differently.

[0282] The processor 801 is the control center of the host machine 800 and may be a central processing unit (CPU). The processor 801 connects various parts of the entire host machine 800 using various interfaces and lines. The processor 801 runs or executes software programs and / or modules stored in the memory 803 and calls program codes stored in the memory 803 to perform the following operations:

[0283] Acquire information required for performing an acceleration operation in a virtual input / output ring of a target virtual accelerator, wherein the information required for performing the acceleration operation adopts a predefined data structure, and the data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator;

[0284] Determining information that can be recognized by the hardware accelerator based on the information required to perform the acceleration operation;

[0285] The information that can be recognized by the hardware accelerator is sent to the hardware accelerator, and the hardware accelerator is used to obtain data to be accelerated according to the information that can be recognized by the hardware accelerator, and perform an acceleration operation on the data to be accelerated.

[0286] The information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated, the length of the data to be accelerated, the virtual machine physical address for storing the acceleration result, and the acceleration type parameter.

[0287] Optionally, the processor 801 determines, based on the information required for performing the acceleration operation, the information that can be recognized by the hardware accelerator in the following manner:

[0288] Determining the host physical address of the data to be accelerated according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host physical address;

[0289] The processor 801 sends the information that the hardware accelerator can identify to the hardware accelerator in the following manner:

[0290] Sending the host physical address of the data to be accelerated to the hardware accelerator;

[0291] The hardware accelerator is configured to obtain the data to be accelerated from a virtual machine memory corresponding to a virtual machine physical address of the data to be accelerated according to a host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0292] Optionally, the hardware accelerator supports multiple virtual functions (VFs). After determining the host physical address of the data to be accelerated, the processor 801 may further call a program code stored in the memory 803 to perform the following operations:

[0293] Querying the target VF bound to the target virtual accelerator from the preset binding relationship between the virtual accelerator and the VF;

[0294] The processor 801 sending the host physical address of the data to be accelerated to the hardware accelerator includes:

[0295] The host physical address of the data to be accelerated is sent to the target VF, and the target VF is used to obtain the data to be accelerated from the virtual machine memory corresponding to the virtual machine physical address of the data to be accelerated according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0296] Optionally, the processor 801 may also call program code stored in the memory 803 to perform the following operations:

[0297] After the data to be accelerated is accelerated, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator in the binding relationship.

[0298] Optionally, before the processor 801 obtains the information required for performing the acceleration operation in the virtual input / output ring of the target virtual accelerator, it may also call the program code stored in the memory 803 to perform the following operations:

[0299] If the hardware accelerator supports multiple virtual functions (VFs), an unused target VF is selected from the multiple VFs, and a binding relationship between the target virtual accelerator and the target VF is established.

[0300] Optionally, before sending the host physical address of the data to be accelerated to the hardware accelerator, the processor 801 may further call a program code stored in the memory 803 to perform the following operations:

[0301] The identifier of the target virtual accelerator is recorded.

[0302] Optionally, the processor 801 may also call program code stored in the memory 803 to perform the following operations:

[0303] After the data to be accelerated is accelerated, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator according to the recorded identifier of the target virtual accelerator.

[0304] Optionally, the processor 801 determines, based on the information required for performing the acceleration operation, the information that can be recognized by the hardware accelerator in the following manner:

[0305] Determining the host virtual address of the data to be accelerated in the virtual machine memory according to the virtual machine physical address of the data to be accelerated in the information required to perform the acceleration operation and a preset mapping relationship between the virtual machine physical address and the host virtual address;

[0306] Copying the data to be accelerated to a memory buffer according to the host virtual address of the data to be accelerated in the virtual machine memory;

[0307] Determining the host physical address of the data to be accelerated in the memory buffer according to the host virtual address of the data to be accelerated in the memory buffer and a preset mapping relationship between the host virtual address and the host physical address;

[0308] The processor 801 sending the information that can be recognized by the hardware accelerator to the hardware accelerator includes:

[0309] The host physical address of the data to be accelerated is sent to the hardware accelerator.

[0310] The hardware accelerator is configured to obtain the data to be accelerated from the memory buffer according to the host physical address of the data to be accelerated, and perform an acceleration operation on the data to be accelerated.

[0311] Optionally, the processor 801 may also call program code stored in the memory 803 to perform the following operations:

[0312] After the data to be accelerated is accelerated, the generated acceleration result is copied to the memory of the virtual machine;

[0313] According to the identifier of the target virtual accelerator, the identifier of the unit item is added to the virtual input / output ring of the target virtual accelerator.

[0314] Optionally, after adding the identifier of the unit item to the virtual input / output ring of the target virtual accelerator, the processor 801 may further call a program code stored in the memory 803 to perform the following operations:

[0315] An interrupt request carrying an identifier of the target virtual accelerator is sent to a virtual machine corresponding to the target virtual accelerator, so as to trigger the virtual machine to query the identifier of the unit item in the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, and obtain an acceleration result generated after the data to be accelerated is accelerated.

[0316] exist Figure 8 In the described host machine, the information required to perform acceleration operations sent by the virtual machine still uses a predefined data structure. This data structure occupies a unit item of the virtual input / output ring of the target virtual accelerator. This can greatly enhance the throughput capacity of the virtual input / output ring. In a unit time, more data packets can be transmitted, thereby improving the transmission efficiency of data packets.

[0317] See Figure 9 , Figure 9 is a schematic diagram of the structure of another host machine disclosed in an embodiment of the present invention, wherein the host machine 900 can be used to execute Figures 2 to 4 For details of all or part of the steps in the disclosed data transmission method, please refer to Figures 2 to 4 As described above, I will not repeat it here. Figure 9 As shown, the host machine 900 may include: at least one processor 901, such as a CPU (Central Processing Unit), a hardware accelerator 902, and a memory 903, wherein the processor 901, the hardware accelerator 902, and the memory 903 are respectively connected to a communication bus. The memory 903 may be a high-speed RAM memory or a non-volatile memory. Those skilled in the art will understand that Figure 9 The structure of the host machine 900 shown in the figure does not constitute a limitation of the present invention. It can be a bus structure, a star structure, or a plurality of other structures. Figure 9 More or fewer components may be shown, or certain components may be combined, or the components may be arranged differently.

[0318] The processor 901 is the control center of the host machine 900 and may be a central processing unit (CPU). The processor 901 connects various parts of the entire host machine 900 using various interfaces and lines. The processor 901 runs or executes software programs and / or modules stored in the memory 903 and calls program codes stored in the memory 903 to perform the following operations:

[0319] After the data to be accelerated is accelerated, an identifier of the target virtual accelerator is obtained;

[0320] Based on the identifier of the target virtual accelerator, an identifier of at least one unit item is added to a virtual input / output ring of the target virtual accelerator, so that the virtual machine can obtain an acceleration result generated after the data to be accelerated is accelerated based on the identifier of the at least one unit item, wherein the unit item stores information required to perform an acceleration operation on the data to be accelerated.

[0321] Optionally, the hardware accelerator supports multiple virtual functions (VFs). After the accelerated data is processed, and before the processor 901 obtains the identifier of the target virtual accelerator, the processor 901 may call a program code stored in the memory 903 to perform the following operations:

[0322] Selecting an unused target VF from the multiple VFs, and establishing a binding relationship between the target virtual accelerator and the target VF;

[0323] The identifier of the target virtual accelerator is obtained from the binding relationship.

[0324] Optionally, after the data to be accelerated is accelerated and before the processor 901 obtains the identifier of the target virtual accelerator, the processor 901 may further call a program code stored in the memory 903 to perform the following operations:

[0325] Record the ID of the target virtual accelerator.

[0326] Optionally, the processor 801 adds the identifier of at least one unit item to the virtual input / output ring of the target virtual accelerator according to the identifier of the target virtual accelerator, so that the virtual machine obtains the acceleration result generated after the data to be accelerated is accelerated according to the identifier of the at least one unit item, specifically in the following manner:

[0327] adding, according to the identifier of the target virtual accelerator, the identifier of at least one unit item to the virtual input / output ring of the target virtual accelerator, and sending an interrupt request carrying the identifier of the target virtual accelerator to the virtual machine corresponding to the target virtual accelerator, so that the virtual machine responds to the interrupt request, queries the identifier of at least one unit item in the virtual input / output ring of the target virtual accelerator, and obtains an acceleration result generated after the data to be accelerated is accelerated; or

[0328] Based on the identifier of the target virtual accelerator, the identifier of at least one unit item is added to the virtual input / output ring of the target virtual accelerator, so that the virtual machine automatically monitors the identifier of at least one unit item in the virtual input / output ring of the target virtual accelerator, and obtains, based on the identifier of at least one unit item, an acceleration result generated after the data to be accelerated is accelerated.

[0329] exist Figure 9 In the described host machine, the data to be accelerated is initially stored in the virtual machine memory, and the acceleration result generated after the data to be accelerated is also stored in the virtual machine memory. The entire process does not require process copying, which reduces CPU resource usage.

[0330] It should be noted that for the aforementioned various method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and units involved are not necessarily required by this application.

[0331] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0332] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0333] The above disclosure is merely a preferred embodiment of the present invention and certainly cannot be used to limit the scope of the present invention. Therefore, equivalent changes made according to the claims of the present invention are still within the scope of the present invention.

Claims

1. A data transmission method, characterized in that: Applied to a virtual machine, the virtual machine is deployed on a host machine, the host machine is also deployed with a hardware accelerator and at least one virtual accelerator configured for the virtual machine, the method comprising: Adding information required for performing the acceleration operation to a predefined data structure; the information required for performing the acceleration operation does not include the data to be accelerated that needs to be accelerated; the information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated and the length of the data to be accelerated; The data structure is stored in a virtual input / output ring (Vring) of a target virtual accelerator, wherein the data structure occupies one unit entry of the virtual input / output ring of the target virtual accelerator.

2. The method according to claim 1, characterized in that The Vring of the target virtual accelerator includes three tables: The vring_desc table is used to store the addresses of IO requests generated by the virtual machine; The vring_avail table is used to indicate the available unit items in vring_desc; The vring_used table is used to indicate the unit items in vring_desc that have been submitted to the hardware.

3. The method according to claim 1 or 2, characterized in that The method further comprises: The virtual input / output ring of the target virtual accelerator is monitored to obtain an acceleration result generated after the data to be accelerated is accelerated.

4. The method according to claim 3, wherein monitoring the virtual input / output ring of the target virtual accelerator to obtain the acceleration result generated after the accelerated data is accelerated comprises: Using a polling method, the vring_used table of the virtual input / output ring of the target virtual accelerator is monitored in real time. If the vring_used table is updated, the identifier of the unit item in the vring_used table is obtained, wherein the unit item is the one that has been accelerated. According to the identifier of the unit item, the physical address of the virtual machine storing the acceleration result is obtained from the vring_desc table of the virtual input / output ring; The acceleration result is obtained from the virtual machine memory corresponding to the virtual machine physical address where the acceleration result is stored.

5. A data transmission device, characterized in that: include: an adding unit, configured to add information required for performing the acceleration operation into a predefined data structure; The information required for performing the acceleration operation does not include the data to be accelerated that needs to be accelerated; the information required for performing the acceleration operation includes the virtual machine physical address of the data to be accelerated and the length of the data to be accelerated; The storage unit is configured to store the data structure in a virtual input / output ring (Vring) of a target virtual accelerator, wherein the data structure occupies a unit entry of the virtual input / output ring of the target virtual accelerator.

6. The device according to claim 5, characterized in that The Vring of the target virtual accelerator includes three tables: The vring_desc table is used to store the addresses of IO requests generated by the virtual machine; The vring_avail table is used to indicate the available unit items in vring_desc; The vring_used table is used to indicate the unit items in vring_desc that have been submitted to the hardware.

7. The device according to claim 5 or 6, characterized in that The device further comprises: The monitoring unit is used to monitor the virtual input / output ring of the target virtual accelerator to obtain the acceleration result generated after the data to be accelerated is accelerated.

8. The device according to claim 7, wherein the monitoring unit is specifically configured to: The vring_used table of the virtual input / output ring of the target virtual accelerator is monitored in real time by polling. If the vring_used table is updated, the identifier of the unit item in the vring_used table is obtained, where: This unit item has been completed on an accelerated basis; According to the identifier of the unit item, the physical address of the virtual machine storing the acceleration result is obtained from the vring_desc table of the virtual input / output ring; The acceleration result is obtained from the virtual machine memory corresponding to the virtual machine physical address where the acceleration result is stored.

9. A computer storage medium storing a program, wherein the program specifically includes instructions for executing the method according to any one of claims 1 to 4.

10. A computer program product, which, when running on a computer, enables the computer to execute the method according to any one of claims 1 to 4.

11. An electronic device, configured to execute the method according to any one of claims 1 to 4.

Images