Self-adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic equipment based on VPP (Virtual Private Protocol)

Abstract

The invention provides a VPP-based adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic equipment, and the method comprises the steps: receiving to-be-processed data sent by a VPP application through a scheduler, and obtaining an encryption task type corresponding to the to-be-processed data through the scheduler; obtaining a scheduling parameter value of each hardware password device through a scheduler, and selecting a target hardware password device from the plurality of hardware password devices based on the scheduling parameter value of each hardware password device; sending the to-be-processed data to the target hardware password device through the scheduler; if the to-be-processed data is the to-be-encrypted data, performing encryption processing on the to-be-encrypted data through the target hardware password device; and if the to-be-processed data is the to-be-decrypted data, decrypting the to-be-decrypted data through the target hardware password device. By means of the scheme, the overall password operation performance of the system is improved, and high-performance encryption or decryption is achieved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP (Vector Packet Processing). Background Art

[0002] DPDK (Data Plane Development Kit) runs on an operating system (such as the Linux operating system) and is a collection of function libraries and drivers for fast packet processing, which improves data processing performance and throughput, and improves the efficiency of data plane applications. DPDK is a high-performance network driver component that provides a convenient, complete, and fast packet processing solution for data plane applications.

[0003] Based on the functions of DPDK, encryption or decryption of the data to be processed can be implemented based on DPDK. Since DPDK bypasses the kernel protocol stack of the operating system and can implement a high-performance network packet processing framework, the kernel protocol stack can also be bypassed when implementing encryption or decryption based on DPDK. However, although DPDK bypasses the kernel protocol stack, DPDK is only a network packet processing framework and does not have the ability to process complex network protocols. Therefore, during the encryption or decryption process, the overall cryptographic operation performance of the system is relatively poor. Summary of the invention

[0004] The present application provides an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on vector packet processing (VPP), which is used to adaptively schedule multiple hardware cryptographic devices. The method includes: Receiving the data to be processed sent by the VPP application through the scheduler, and obtaining the encryption task type corresponding to the data to be processed through the scheduler, wherein the encryption task type includes the cryptographic algorithm type and the data volume level; Obtaining the scheduling parameter value of each hardware cryptographic device through the scheduler, and selecting a target hardware cryptographic device from the multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device; wherein the multiple hardware cryptographic devices include a GPU hardware cryptographic device, a USB hardware cryptographic device and a PCIE hardware cryptographic device; the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device and the PCIE hardware cryptographic device through an OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through a DPDK link; the scheduling parameter value of the GPU hardware cryptographic device is determined based on the encryption task type, the performance parameter of the GPU hardware cryptographic device, the hardware load parameter of the GPU hardware cryptographic device and the link load parameter of the OpenSSL link; the scheduling parameter value of the USB hardware cryptographic device is determined based on the encryption task type, the performance parameter of the USB hardware cryptographic device, the hardware load parameter of the USB hardware cryptographic device and the link load parameter of the OpenSSL link; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the encryption task type, the performance parameter of the PCIE hardware cryptographic device, the hardware load parameter of the PCIE hardware cryptographic device, the link load parameter of the OpenSSL link and the link load parameter of the DPDK link; Sending the data to be processed to the target hardware cryptographic device through the scheduler; Among them, if the data to be processed is data to be encrypted, the data to be encrypted is encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted is decrypted by the target hardware cryptographic device.

[0005] The present application provides an adaptive scheduling and communication device for heterogeneous computing of hardware cryptographic devices based on vector packet processing (VPP), which is used to adaptively schedule multiple hardware cryptographic devices, including: A VPP application module, used to send the data to be processed and the encryption task type corresponding to the data to be processed to the scheduler; wherein the encryption task type includes the cryptographic algorithm type and the data volume level; A scheduler is used to receive the data to be processed and the encryption task type, obtain the scheduling parameter value of each hardware cryptographic device, and select a target hardware cryptographic device from the multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device; wherein the multiple hardware cryptographic devices include a GPU hardware cryptographic device, a USB hardware cryptographic device, and a PCIE hardware cryptographic device; the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device through an OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through a DPDK link; wherein the scheduling parameter value of the GPU hardware cryptographic device is based on the encryption task type, The performance parameters of the GPU hardware cryptographic device, the hardware load parameters of the GPU hardware cryptographic device, and the link load parameters of the OpenSSL link are determined; the scheduling parameter value of the USB hardware cryptographic device is determined based on the encryption task type, the performance parameters of the USB hardware cryptographic device, the hardware load parameters of the USB hardware cryptographic device, and the link load parameters of the OpenSSL link; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the encryption task type, the performance parameters of the PCIE hardware cryptographic device, the hardware load parameters of the PCIE hardware cryptographic device, the link load parameters of the OpenSSL link, and the link load parameters of the DPDK link; The scheduler is further used to send the data to be processed to the target hardware cryptographic device; Among them, if the data to be processed is data to be encrypted, the data to be encrypted is encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted is decrypted by the target hardware cryptographic device.

[0006] The present application provides an electronic device, including a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP.

[0007] The present application provides a computer program product, including a computer program, which, when executed by a processor, implements the adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP.

[0008] The present application provides a machine-readable storage medium, which stores machine-executable instructions that can be executed by a processor; wherein the processor is used to execute the machine-executable instructions to implement the above-mentioned adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP.

[0009] It can be seen from the above technical solutions that in the embodiment of the present application, under the VPP application, by deploying the DPDK link and the OpenSSL link, it is possible to simultaneously support GPU hardware cryptographic devices, USB hardware cryptographic devices, and PCIE hardware cryptographic devices, and the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device through the OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through the DPDK link. On this basis, by additionally deploying a scheduler, it is possible to select a target hardware cryptographic device from the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device, and send the data to be processed to the target hardware cryptographic device for encryption or decryption, thereby improving the overall cryptographic operation performance of the system and achieving high-performance encryption or decryption. It is possible to realize heterogeneous computing of hardware cryptographic devices based on VPP, integrate an adaptive mechanism into the scheduling algorithm, perform task scheduling based on performance parameters and load parameters, dynamically and efficiently allocate data packet processing tasks to appropriate hardware cryptographic devices (i.e., target hardware cryptographic devices), and take advantage of the heterogeneous computing framework to improve overall computing performance and computing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 It is a flow chart of the adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP; Figure 2 It is a schematic diagram of encryption and decryption based on the kernel protocol stack in this application; Figure 3 It is a schematic diagram of the association between VPP, DPDK and operating system in this application; Figure 4 It is a schematic diagram of the VPP-based encryption and decryption framework in this application; Figure 5A It is the registration diagram of the USB hardware password device in this application; Figure 5B It is a registration diagram of the GPU hardware cryptographic device in this application; Figure 5C It is the registration diagram of the PCIE hardware cryptographic device in this application; Figure 5D This is a schematic diagram of the implementation of the PCIE hardware cryptographic device in this application; Figure 5E It is a schematic diagram of the interface implementation of VFIO or UIO in this application; Figure 6 It is a flow chart of the adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP; Figure 7 It is a hardware structure diagram of an electronic device in one embodiment of the present application. DETAILED DESCRIPTION

[0011] In the embodiment of the present application, an adaptive scheduling and communication method (such as an adaptive scheduling and communication implementation method) for heterogeneous computing of hardware cryptographic devices based on VPP is proposed, which is used to adaptively schedule multiple hardware cryptographic devices. Figure 1 FIG. 4 is a flow chart of the method, which may include: Step 101: Receive the data to be processed sent by the VPP application through the scheduler, and obtain the encryption task type corresponding to the data to be processed through the scheduler, and the encryption task type may include the cryptographic algorithm type (used to indicate the type of the cryptographic algorithm) and the data volume level (used to indicate the size of the data volume).

[0012] Step 102: Obtain a scheduling parameter value of each hardware cryptographic device through a scheduler, and select a target hardware cryptographic device from multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device.

[0013] Exemplarily, the multiple hardware cryptographic devices may include but are not limited to GPU hardware cryptographic devices, USB hardware cryptographic devices, and PCIE hardware cryptographic devices. Based on this, the VPP application can communicate with the GPU hardware cryptographic device, USB hardware cryptographic device, and PCIE hardware cryptographic device respectively through the OpenSSL link, and the VPP application can communicate with the PCIE hardware cryptographic device through the DPDK link.

[0014] Exemplarily, the scheduling parameter value of the GPU hardware cryptographic device can be determined based on the encryption task type, the performance parameters of the GPU hardware cryptographic device, the hardware load parameters of the GPU hardware cryptographic device, and the link load parameters of the OpenSSL link. The scheduling parameter value of the USB hardware cryptographic device can be determined based on the encryption task type, the performance parameters of the USB hardware cryptographic device, the hardware load parameters of the USB hardware cryptographic device, and the link load parameters of the OpenSSL link. The scheduling parameter value of the PCIE hardware cryptographic device can be determined based on the encryption task type, the performance parameters of the PCIE hardware cryptographic device, the hardware load parameters of the PCIE hardware cryptographic device, the link load parameters of the OpenSSL link, and the link load parameters of the DPDK link.

[0015] Step 103: Send the data to be processed to the target hardware cryptographic device through the scheduler.

[0016] Exemplarily, if the data to be processed is data to be encrypted, the data to be encrypted may be encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted may be decrypted by the target hardware cryptographic device.

[0017] Exemplarily, the process of obtaining the scheduling parameter value of the GPU hardware cryptographic device, the scheduling parameter value of the USB hardware cryptographic device, and the scheduling parameter value of the PCIE hardware cryptographic device may include but is not limited to: The first initial weight, the second initial weight, and the third initial weight corresponding to the encryption task type are obtained from the configured weight table; wherein the weight table may include a correspondence between the encryption task type and the initial weight; the first initial weight may represent the probability that the GPU hardware cryptographic device is assigned to the data to be processed, the second initial weight may represent the probability that the USB hardware cryptographic device is assigned to the data to be processed, and the third initial weight may represent the probability that the PCIE hardware cryptographic device is assigned to the data to be processed. A first target weight is determined based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight, and a first performance score value is determined based on the first target weight; a second target weight is determined based on the current performance parameters of the USB hardware cryptographic device for the encryption task type and the second initial weight, and a second performance score value is determined based on the second target weight; a third target weight is determined based on the current performance parameters of the PCIE hardware cryptographic device for the encryption task type and the third initial weight, and a third performance score value is determined based on the third target weight.

[0018] The first hardware load score value is determined based on the current hardware load parameters of the GPU hardware cryptographic device, the second hardware load score value is determined based on the current hardware load parameters of the USB hardware cryptographic device, and the third hardware load score value is determined based on the current hardware load parameters of the PCIE hardware cryptographic device.

[0019] The OpenSSL link load score value is determined based on the current link load parameter of the OpenSSL link, and the first link load score value of the OpenSSL link load score value allocated to the GPU hardware cryptographic device, the second link load score value of the OpenSSL link load score value allocated to the USB hardware cryptographic device, and the third link load score value of the OpenSSL link load score value allocated to the PCIE hardware cryptographic device are determined. The DPDK link load score value is determined based on the current link load parameter of the DPDK link.

[0020] The scheduling parameter value of the GPU hardware cryptographic device can be determined based on the first performance score value, the first hardware load score value, and the first link load score value; the scheduling parameter value of the USB hardware cryptographic device can be determined based on the second performance score value, the second hardware load score value, and the second link load score value; the scheduling parameter value of the PCIE hardware cryptographic device can be determined based on the third performance score value, the third hardware load score value, the third link load score value, and the DPDK link load score value.

[0021] In a possible implementation, if the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted in parallel, and the data volume level in the encryption task type indicates that the data volume of the data to be processed is not less than the first threshold, then the first initial weight may be greater than the second initial weight, and the first initial weight may be greater than the third initial weight. If the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted in series, and the data volume level in the encryption task type indicates that the data volume of the data to be processed is not greater than the second threshold, and the second threshold is less than the first threshold, then the second initial weight may be greater than the first initial weight, and the third initial weight may be greater than the first initial weight.

[0022] Exemplarily, determining the first target weight based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight may include: sending a first request message to the GPU hardware cryptographic device through a scheduler, the first request message including the encryption task type, receiving a first response message returned by the GPU hardware cryptographic device through the scheduler, the first response message including the current performance parameters; the current performance parameters include a target processing number, the target processing number indicates the maximum amount of data processed in a unit cycle when the GPU hardware cryptographic device encrypts or decrypts the to-be-processed data of the encryption task type; wherein, if there is one GPU hardware cryptographic device, the target processing number is the maximum processing number supported by one GPU hardware cryptographic device, and if there are multiple GPU hardware cryptographic devices, the target processing number is the sum of the maximum processing numbers supported by multiple GPU hardware cryptographic devices; if the target processing number is greater than a third threshold, the first initial weight is increased to obtain a first target weight; if the target processing number is less than a fourth threshold, and the fourth threshold is less than the third threshold, the first initial weight is reduced to obtain the first target weight; if the target processing number is not greater than the third threshold and not less than the fourth threshold, the first initial weight is determined as the first target weight.

[0023] Alternatively, the historical performance data of the GPU hardware cryptographic device is input into a trained machine learning model to obtain a weight adjustment amount, and the first initial weight is adjusted based on the weight adjustment amount to obtain an adjusted weight; if the target processing number is greater than a third threshold, the adjusted weight can be increased to obtain a first target weight; if the target processing number is less than a fourth threshold, the adjusted weight can be reduced to obtain the first target weight; if the target processing number is not greater than the third threshold and not less than the fourth threshold, the adjusted weight can be determined as the first target weight; wherein the historical performance data may at least include historical performance parameters and actual processed data volume of the GPU hardware cryptographic device for encryption task types in a historical time period.

[0024] Exemplarily, determining the first hardware load score value based on the current hardware load parameter of the GPU hardware cryptographic device may include, but is not limited to: sending a second request message to the GPU hardware cryptographic device through a scheduler, receiving a second response message returned by the GPU hardware cryptographic device through the scheduler, the second response message may include the current hardware load parameter, and the current hardware load parameter may include, but is not limited to, device utilization and processing delay; wherein the device utilization may represent the ratio of the actual amount of data processed by the GPU hardware cryptographic device in a unit cycle to the maximum amount of data processed by the GPU hardware cryptographic device in a unit cycle, and the processing delay may represent the time from the start of data reception to the completion of data processing by the GPU hardware cryptographic device. Then, the first hardware load score value may be determined based on the device utilization and the processing delay.

[0025] Determining the OpenSSL link load score value based on the current link load parameters of the OpenSSL link includes: counting the current link load parameters of the OpenSSL link through a scheduler, the current link load parameters of the OpenSSL link include a first data processing rate, a first queue length, and a first memory occupancy size; the first data processing rate represents the current rate of data transmitted through the OpenSSL link, the first queue length represents the total amount of data waiting to be transmitted on the OpenSSL link, and the first memory occupancy size represents the total memory occupancy size of data waiting to be transmitted on the OpenSSL link. Determining the OpenSSL link load score value based on the first data processing rate, the first queue length, and the first memory occupancy size, the OpenSSL link load score value is proportional to the first data processing rate and inversely proportional to the first queue length and the first memory occupancy size.

[0026] Determining the DPDK link load score value based on the current link load parameters of the DPDK link may include but is not limited to: counting the current link load parameters of the DPDK link through the scheduler, the current link load parameters of the DPDK link include the second data processing rate, the second queue length, and the second memory occupancy size; the second data processing rate represents the current rate of data transmitted through the DPDK link, the second queue length represents the total amount of data waiting to be transmitted on the DPDK link, and the second memory occupancy size represents the total memory occupancy size of data waiting to be transmitted on the DPDK link. Determining the DPDK link load score value based on the second data processing rate, the second queue length, and the second memory occupancy size, the DPDK link load score value is proportional to the second data processing rate and inversely proportional to the second queue length and the second memory occupancy size.

[0027] Exemplarily, sending the data to be processed to the target hardware cryptographic device through the scheduler may include but is not limited to: if the target hardware cryptographic device is a GPU hardware cryptographic device, the data to be processed may be sent to the GPU transit firmware based on the OpenSSL link through the scheduler, and the data to be processed may be sent to the GPU hardware cryptographic device through the GPU transit firmware. Alternatively, if the target hardware cryptographic device is a USB hardware cryptographic device, the data to be processed may be sent to the USB transit firmware based on the OpenSSL link through the scheduler, and the data to be processed may be sent to the USB hardware cryptographic device through the USB transit firmware. Alternatively, if the target hardware cryptographic device is a PCIE hardware cryptographic device, and the link load parameter of the OpenSSL link is better than the link load parameter of the DPDK link, the data to be processed may be sent to the PCIE transit firmware based on the OpenSSL link through the scheduler, and the data to be processed may be sent to the PCIE hardware cryptographic device through the PCIE transit firmware; or, if the link load parameter of the DPDK link is better than the link load parameter of the OpenSSL link, the data to be processed may be sent to the PCIE transit firmware based on the DPDK link through the scheduler, and the data to be processed may be sent to the PCIE hardware cryptographic device through the PCIE transit firmware.

[0028] Exemplarily, the OpenSSL link includes, in sequence, an open secure socket layer encryption application programming interface OpenSSL Crypto API, an open secure socket layer engine OpenSSL Engine, and a kernel driver Kernel Driver of the operating system; the DPDK link includes, in sequence, a data plane development kit encryption library application programming interface DPDKCryptoDev API, an encryption library polling mode driver CryptoDev PMD, a virtual function input and output VFIO or a user space input and output UIO driver, and a data buffer.

[0029] It can be seen from the above technical solutions that in the embodiment of the present application, under the VPP application, by deploying the DPDK link and the OpenSSL link, it is possible to simultaneously support GPU hardware cryptographic devices, USB hardware cryptographic devices, and PCIE hardware cryptographic devices, and the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device through the OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through the DPDK link. On this basis, by additionally deploying a scheduler, it is possible to select a target hardware cryptographic device from the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device, and send the data to be processed to the target hardware cryptographic device for encryption or decryption, thereby improving the overall cryptographic operation performance of the system and achieving high-performance encryption or decryption. It is possible to realize heterogeneous computing of hardware cryptographic devices based on VPP, integrate an adaptive mechanism into the scheduling algorithm, perform task scheduling based on performance parameters and load parameters, dynamically and efficiently allocate data packet processing tasks to appropriate hardware cryptographic devices (i.e., target hardware cryptographic devices), and take advantage of the heterogeneous computing framework to improve overall computing performance and computing efficiency.

[0030] The above technical solutions of the embodiments of the present application are described below in combination with specific application scenarios.

[0031] For example, see Figure 2 As shown, it is a schematic diagram of encryption and decryption based on the kernel protocol stack. The application (such as APP1 or APP2, etc.) can call the USB hardware password device for encryption or decryption through the interface supported by the kernel protocol stack, or can call the PCIE hardware password device for encryption or decryption.

[0032] For example, the kernel protocol stack (kernel module) may include Driver, Crypto API (cryptographic service provider), Kernel and other modules. APP1 calls the USB interface through the Driver in the kernel protocol stack, and then calls the USB hardware cryptographic device for encryption or decryption, or APP1 calls the PCIE interface through the Driver in the kernel protocol stack, and then calls the PCIE hardware cryptographic device for encryption or decryption. APP2 calls the USB interface through the Crypto API and Driver in the kernel protocol stack, and then calls the USB hardware cryptographic device for encryption or decryption, or APP2 calls the PCIE interface through the Crypto API and Driver in the kernel protocol stack, and then calls the PCIE hardware cryptographic device for encryption or decryption. By calling the hardware cryptographic device, complex cryptographic operations can be implemented, thereby reducing the CPU load.

[0033] In the encryption and decryption process based on the kernel protocol stack, encryption and decryption need to be implemented based on the kernel protocol stack of the operating system. There are performance problems based on the kernel protocol stack, and the overall cryptographic operation performance of the system is relatively poor.

[0034] For example, DPDK runs based on the operating system. In order to solve the performance problem based on the kernel protocol stack, DPDK bypasses the kernel protocol stack of the operating system to implement a high-performance network packet processing framework. However, although DPDK bypasses the kernel protocol stack, DPDK is only a network packet processing framework and does not have the ability to process complex network protocols. In the encryption or decryption process based on DPDK, there is still a problem of poor overall cryptographic operation performance of the system, and encryption or decryption operations cannot be completed efficiently.

[0035] Based on DPDK, VPP implements a complete high-performance network framework by separating the control plane and the data plane. For example, VPP is a network protocol stack implementation that can run in user space, support multiple packet receiving methods, and implement framework scalability and switching / routing functions. Figure 3 FIG. 1 is a schematic diagram showing the association between VPP, DPDK, and an operating system (such as a Linux operating system).

[0036] Since the combination of VPP and DPDK can bypass the kernel protocol stack, network forwarding and processing performance are greatly improved. However, VPP only implements the interfaces of some hardware devices and is not compatible with hardware cryptographic devices (such as GPU hardware cryptographic devices, USB hardware cryptographic devices, and PCIE hardware cryptographic devices).

[0037] In response to the above findings, an adaptive scheduling and communication implementation method for heterogeneous computing of hardware cryptographic devices based on VPP is proposed in an embodiment of the present application, which can be applied to any electronic device that supports VPP applications and the VPP application has encryption or decryption requirements for the data to be processed.

[0038] In this embodiment, heterogeneous computing of hardware cryptographic devices based on VPP can be realized, and an adaptive mechanism is integrated into the scheduling algorithm to provide optimization strategies for various types of cryptographic operations on VPP, so as to give full play to the computing advantages of various hardware cryptographic devices and improve the overall computing performance of the system. Among them, adaptation refers to the process of automatically adjusting the processing method, processing sequence, processing parameters, boundary conditions or constraints according to the data characteristics of the data to be processed during the processing and analysis process, so that it is adapted to the statistical distribution characteristics and structural characteristics of the data to be processed to achieve the best processing effect. In addition, heterogeneous computing is a parallel and distributed computing that can coordinately use hardware cryptographic devices with different performance and structure to meet different computing needs, and can be executed in a way to obtain the maximum overall performance. In addition, the hardware cryptographic device is hardware that supports cryptographic algorithms, encapsulates the cryptographic operation process in hardware, and calls it through a software interface in the application. The hardware cryptographic device can reduce the burden of cryptographic operations on the CPU and improve the cryptographic operation rate.

[0039] See also Figure 4 As shown, it is a schematic diagram of the encryption and decryption framework based on VPP. In the encryption and decryption process based on VPP, multiple hardware cryptographic devices can be adaptively scheduled to complete encryption and decryption, that is, a target hardware cryptographic device is adaptively selected from multiple hardware cryptographic devices, and the target hardware cryptographic device is called to complete encryption and decryption.

[0040] Exemplarily, multiple hardware cryptographic devices may include, but are not limited to, GPU (Graphic Processing Unit) hardware cryptographic devices, USB (Universal Serial Bus) hardware cryptographic devices, and PCIE (Peripheral Component Interconnect Express) hardware cryptographic devices, and there is no restriction on the types of such hardware cryptographic devices. Among them, the GPU hardware cryptographic device may be a hardware cryptographic device implemented based on the GPU, which is a specialized graphics core processor that can perform parallel computing. The USB hardware cryptographic device may be a hardware cryptographic device implemented based on the USB, and the USB interface is a serial port bus standard. The PCIE hardware cryptographic device may be a hardware cryptographic device implemented based on the PCIE, and the PCIE interface is a high-speed serial computer expansion bus standard.

[0041] Exemplarily, VPP applications have encryption requirements or decryption requirements for data to be processed. For example, if the data to be processed is data to be encrypted, the VPP application has an encryption requirement for the data to be encrypted, and the VPP application needs to call the hardware cryptographic device to complete the encryption operation on the encrypted data. Alternatively, if the data to be processed is data to be decrypted, the VPP application has a decryption requirement for the data to be decrypted, and the VPP application needs to call the hardware cryptographic device to complete the decryption operation on the decrypted data.

[0042] See also Figure 4 As shown in the figure, the VPP application can communicate with the GPU hardware cryptographic device through an OpenSSL (Open Secure Socket Layer) link (the OpenSSL link is a transmission link that supports OpenSSL), that is, the VPP application is connected to the GPU transit firmware (such as GPU Firmware) through the OpenSSL link, and the GPU transit firmware is connected to the GPU hardware cryptographic device (such as GPU Crypto Device). The VPP application can communicate with the USB hardware cryptographic device through the OpenSSL link, that is, the VPP application is connected to the USB transit firmware (such as USB Firmware) through the OpenSSL link, and the USB transit firmware is connected to the USB hardware cryptographic device (such as USB Crypto Device). The VPP application can communicate with the PCIE hardware cryptographic device through the OpenSSL link, that is, the VPP application is connected to the PCIE transit firmware (such as PCIE Firmware) through the OpenSSL link, and the PCIE transit firmware is connected to the PCIE hardware cryptographic device (such as PCIE Crypto Device). In addition, the VPP application can communicate with the PCIE hardware cryptographic device through the DPDK link (the DPDK link is a transmission link that supports DPDK), that is, the VPP application is connected to the PCIE transit firmware through the DPDK link, and the PCIE transit firmware is connected to the PCIE hardware cryptographic device.

[0043] For example, OpenSSL is a software package for implementing secure communications. It consists of a set of cryptographic function libraries that use cryptographic algorithms to protect the confidentiality, integrity, and authentication of data, and supports symmetric encryption, asymmetric encryption, digital signatures, and certificate management. DPDK is a high-performance network driver component that provides a simple, convenient, complete, and fast packet processing solution for data plane applications.

[0044] exist Figure 4In the OpenSSL link, OpenSSL Crypto API (Open Secure Sockets Layer Application Programming Interface, API is Application Programming Interface), OpenSSL Engine (Open Secure Sockets Layer Engine), and Kernel Driver of the operating system (such as Linux operating system). In this way, the VPP application can connect to the GPU transit firmware, USB transit firmware, and PCIE transit firmware through OpenSSL Crypto API, OpenSSL Engine, and Kernel Driver respectively.

[0045] For example, OpenSSL Crypto API is a Crypto API that supports OpenSSL. The function of Crypto API is that Crypto API is a built-in security suite that implements advanced encryption, decryption, certificate management, and digital signature functions, and provides developers with basic tools for processing public key infrastructure, such as certificate management, digital signature, data encryption, and hashing operations. In this embodiment, when the VPP application sends the data to be processed to the hardware cryptographic device through the OpenSSL link, the data to be processed will pass through the OpenSSL Crypto API, and the OpenSSL Crypto API will perform related operations, and there is no restriction on this operation method.

[0046] OpenSSL Engine is an Engine that supports OpenSSL. Engine is an extension mechanism of the OpenSSL library, allowing users or developers to extend the functionality of OpenSSL through custom cryptographic algorithms, encryption algorithms, random number generators, etc. Engine exists in the form of a shared library (dynamic link library) and can be loaded and used when OpenSSL is running, providing a more flexible and customized encryption solution. In this embodiment, when the VPP application sends the data to be processed to the hardware cryptographic device through the OpenSSL link, the data to be processed will pass through the OpenSSL Engine, and the OpenSSL Engine will perform related operations.

[0047] Kernel Driver is the kernel driver of the operating system, which can also be called a kernel driver. Kernel Driver is responsible for controlling hardware devices and managing system resources so that the operating system can communicate with the hardware. In this embodiment, when the VPP application sends the data to be processed to the hardware cryptographic device through the OpenSSL link, the data to be processed will pass through the Kernel Driver, and the Kernel Driver will perform related operations.

[0048] exist Figure 4 In the DPDK link, the DPDK CryptoDev API (data plane development kit cryptographic library application programming interface), CryptoDev PMD (cryptographic library polling mode driver), VFIO Driver (virtual function input and output driver) or UIO Driver (user space input and output driver), data buffer, data buffer includes receive data buffer (RX Ring) and send data buffer (TX Ring). In this way, the VPP application is connected to the PCIE transit firmware through the DPDK CryptoDev API, CryptoDev PMD, VFIO Driver or UIO Driver, and data buffer (RX Ring and TX Ring).

[0049] DPDK CryptoDev API is a CryptoDev API that supports DPDK. DPDK CryptoDev API is a software library of DPDK, which provides a unified API for various software and hardware CryptoDev engines with different algorithms, hiding various highly optimized Crypto implementation details from users. DPDK CryptoDev has a unified implementation of asymmetric enqueue and dequeue to ensure the optimization of hardware Crypto operation efficiency. In this embodiment, when the VPP application sends the data to be processed to the hardware cryptographic device through the DPDK link, the data to be processed will pass through the DPDK CryptoDev API, and the DPDK CryptoDev API will perform related operations.

[0050] CryptoDev PMD (Poll Mode Driver, also known as polling mode driver) is the polling mode driver of the encryption library. CryptoDev PMD consists of an API provided by a driver running in user space, which can configure devices and their respective queues. CryptoDev PMD directly accesses the RX descriptor (RX Ring) and TX descriptor (TXRing), and no interrupts (except link status change interrupts) are generated, which can ensure fast reception, processing and transmission of data packets in user space applications. In this embodiment, when the VPP application sends the data to be processed to the hardware cryptographic device through the DPDK link, the data to be processed will pass through CryptoDev PMD, and CryptoDev PMD will perform related operations.

[0051] VFIO Driver (Virtual Function Input Output Driver) or UIO Driver (Userspace Input Output Driver) is used to complete the operation and configuration of the device in the user space, and is the basis for DPDK to implement PMD. UIO Driver is a user-mode driver framework provided by the Linux kernel, which can run device drivers in user space without recompiling the kernel. A small kernel module can be maintained in the kernel. VFIO Driver is a user-mode driver framework that can safely expose device I / O and interrupts to user space. User-mode processes can directly use VFIO Driver to access hardware, thereby completing the device driver framework in user space. In this embodiment, in the process of the VPP application sending the data to be processed to the hardware cryptographic device through the DPDK link, the data to be processed will pass through the VFIO Driver or UIO Driver, and the VFIO Driver or UIO Driver will perform related operations.

[0052] For the RX Ring and TX Ring of the data buffer, the TX Ring is the sending data buffer. When the VPP application sends the data to be processed to the hardware cryptographic device through the DPDK link, the data to be processed can be cached in the TXRing. In addition, the RX Ring is the receiving data buffer. When the hardware cryptographic device sends the processed data (that is, the data that has been encrypted or decrypted) to the VPP application through the DPDK link, the processed data can be cached in the RX Ring.

[0053] exist Figure 4 In the present invention, considering that CryptoDev PMD, VFIO Driver or UIO Driver is applicable to PCIE but not to GPU and USB, VPP applications can communicate with PCIE hardware cryptographic devices through DPDK links. However, VPP applications do not communicate with GPU hardware cryptographic devices through DPDK links, and VPP applications do not communicate with USB hardware cryptographic devices through DPDK links.

[0054] In one possible implementation, to support Figure 4 The framework shown enables the VPP application to communicate with the hardware cryptographic device through the OpenSSL link or the DPDK link. The following methods can be used: 1. OpenSSL Crypto API for OpenSSL link. In order to implement the OpenSSL Crypto API for OpenSSL link so that the VPP application can communicate with the hardware cryptographic device through the OpenSSL link, the hardware cryptographic device can be registered in the OpenSSL Engine to achieve the conversion between the standard interface and the hardware interface.

[0055] For the registration process of USB hardware password devices, see Figure 5A The figure shows a registration diagram of a USB hardware password device. Figure 5A The hardware is a USB hardware password device, the USB hardware password device includes a USB host controller and a USB device, and the USB device includes a hardware password module and a USB device controller.

[0056] Kernel space can include USB controller driver, USB device driver, USBFS (USB File System), USB core and USB node ( / dev / usb). For example, USBFS is a virtual file system used for communication between user space and kernel space. It can abstract USB devices into files in the file system, so that users can access USB devices by reading and writing files. USB node is a device node created for USB devices, and the device node is a special file located in the / dev directory. The device node allows user space programs to communicate with USB devices. User space can include user-mode drivers, OpenSSL Engine (Open Secure Sockets Layer Engine) and applications.

[0057] Through the cooperation between the USB hardware cryptographic device, kernel space and user space, the USB hardware cryptographic device can be registered in the OpenSSL Engine to realize the conversion between the standard interface and the hardware interface, and then the VPP application can communicate with the USB hardware cryptographic device through the OpenSSL link. There is no restriction on this implementation process, and the VPP application can communicate with the USB hardware cryptographic device through the OpenSSL link.

[0058] exist Figure 5A In the USB device, the USB device controller and hardware cryptographic module contained in the USB device can complete the hardware functions, receive the encryption and decryption instructions sent from the kernel space, complete the USB protocol decoding and encryption and decryption operations, and then send the calculation results through the USB protocol. The kernel space can complete the registration of the USB hardware cryptographic device, and the OpenSSL Engine is responsible for completing the protocol conversion of data writing. Finally, in the VPP application, the interface is called to communicate with the USB hardware cryptographic device through the OpenSSL link.

[0059] For the registration process of GPU hardware cryptographic devices, see Figure 5B The figure shows a registration diagram of a GPU hardware cryptographic device. Figure 5B The hardware is a GPU hardware cryptographic device, the GPU hardware cryptographic device includes a PCIE bridge and a GPU device, and the GPU device is connected to the PCIE bridge through a PCIE bus.

[0060] The kernel space can include Root Complex, PCIE device driver, GPU kernel-mode driver and CPU. For example, Root Complex is one of the core components of the PCIE bus architecture, responsible for managing external I / O devices. The CPU can be connected to the PCIE bus through Root Complex and eventually connected to all PCIE devices. For example, Root Complex is used to manage external I / O devices, Root Complex is used to initialize devices, and Root Complex is used for resource allocation. User space can include GPU user-mode driver, OpenSSL Engine (Open Secure Sockets Layer Engine) and applications.

[0061] Through the cooperation between the GPU hardware cryptographic device, kernel space and user space, the GPU hardware cryptographic device can be registered in the OpenSSL Engine to achieve the conversion between the standard interface and the hardware interface, and then the VPP application can communicate with the GPU hardware cryptographic device through the OpenSSL link. There is no restriction on this implementation process, and the VPP application can communicate with the GPU hardware cryptographic device through the OpenSSL link.

[0062] exist Figure 5B In the figure, the GPU hardware cryptographic device includes a GPU computing unit (located inside the GPU device, not shown in the figure). By configuring it in the GPU user mode driver, it can be configured for cryptographic computing related functions and follow and implement the same Engine interface as the USB hardware cryptographic device.

[0063] For the registration process of PCIE hardware cryptographic devices, see Figure 5C As shown, it is a registration diagram of PCIE hardware cryptographic device. Figure 5CThe hardware is a PCIE hardware cryptographic device, which includes a PCIE bridge and a PCIE device, and the PCIE device is connected to the PCIE bridge through a PCIE bus. The kernel space may include a Root Complex, a PCIE device driver, a Crypto driver (i.e., an encryption driver, such as a Linux-based Crypto driver), and a CPU. The user space may include a Crypto user-mode driver, an OpenSSL Engine, and applications.

[0064] Through the cooperation between the PCIE hardware cryptographic device, kernel space and user space, the PCIE hardware cryptographic device can be registered in the OpenSSL Engine to realize the conversion between the standard interface and the hardware interface, and then the VPP application can communicate with the PCIE hardware cryptographic device through the OpenSSL link. There is no restriction on this implementation process, and the VPP application can communicate with the PCIE hardware cryptographic device through the OpenSSL link.

[0065] 2. DPDK CryptoDev API for DPDK links.

[0066] For PCIE hardware cryptographic devices, in addition to using OpenSSL Engine (see Figure 5C As shown in Figure 1), the kernel-mode driver of the PCIE hardware cryptographic device can also implement the interface of VFIO or UIO, and implement the custom data interface of the DPDKCryptoDev API so that it can be called in the polling program of the CryptoDev PMD. On this basis, the DPDK CryptoDev API of the DPDK link can be implemented to enable the VPP application to communicate with the PCIE hardware cryptographic device through the DPDK link.

[0067] For the implementation process of PCIE hardware cryptographic devices, see Figure 5D As shown, it is a schematic diagram of the implementation of PCIE hardware cryptographic device. Figure 5DThe hardware is a PCIE hardware cryptographic device, and the PCIE hardware cryptographic device may include a PCIE bridge, a PCIE device, a UIO kernel-mode driver, and a DMA (Direct Memory Access), and the PCIE device and the PCIE bridge may be connected via a PCIE bus, the DMA and the PCIE bridge may be connected via a PCIE bus, and the DMA and the PCIE device may be directly connected. The kernel space may include a UIO kernel-mode driver and a VFIO kernel-mode driver. The user space may include a UIO user-mode driver, a VFIO user-mode driver, VPP Crypto (i.e., a VPP encryption component), DPDK CryptoDev (i.e., DPDK CryptoDevAPI, i.e., a DPDK encryption library application programming interface), and a VPP application.

[0068] Through the cooperation between PCIE hardware cryptographic devices, kernel space and user space, the DPDK CryptoDev API of the DPDK link can be implemented, and then the VPP application can communicate with the PCIE hardware cryptographic device through the DPDK link (that is, using Figure 5D The framework implements the communication process), and there is no restriction on this implementation process. The VPP application can communicate with the PCIE hardware cryptographic device through the DPDK link.

[0069] For PCIE hardware cryptographic devices, the kernel-mode driver of the PCIE hardware cryptographic device can also implement the VFIO or UIO interface, see Figure 5E The figure shows a schematic diagram of the interface implementation of VFIO or UIO.

[0070] Create a Crypto Dev (crypto library) device in the VPP application through the rte_cryptodev_pmd_create (runtime environment crypto library polling mode driver creation) function. The Crypto Dev device needs to implement the enqueue_burst (batch queue entry) and dequeue_burst (batch queue exit) related interfaces.

[0071] The Crypto Dev device receives data from the RX Ring (receive data buffer), and the Crypto Dev device sends data through the TXRing (transmit data buffer), and then completes the interaction with the PCIE hardware cryptographic device. In the RX Ring, the first response status message can be called the head response status message (RSP Head), and so on, the last response status message can be called the tail response status message (RSP Tail). In the TX Ring, the first data request message can be called the head data request message (REQ Head), and so on, the last data request message can be called the tail data request message (REQTail).

[0072] In the PCIE hardware cryptographic device, there are PCIE cores (PCIE Core), hardware cores of several cryptographic algorithms or FPGA software cores, such as Asymmetric Cipher Core (core of asymmetric cryptography), Symmetric Cipher Core (core of symmetric cryptography), Hasher Cipher Core (core of hash cryptography), etc. In addition, the data format is encapsulated and decapsulated through the Encap (encapsulation protocol) core and the Decap (decapsulation protocol) core to realize the data interaction between the cryptographic algorithm core and the VPP application. At the same time, the Encap / Decap core can complete the data format encapsulation / decapsulation that conforms to the OpenSSL Engine interface.

[0073] Based on the above VPP-based encryption and decryption framework, in the embodiment of this application, see Figure 4 As shown, you can also deploy a scheduler. The scheduler is located between the VPP application and the OpenSSL link. The scheduler is located between the VPP application and the DPDK link. The scheduler can be a hardware-implemented scheduler or a software-implemented scheduler. There is no restriction on this implementation method. In this way, when the VPP application communicates with hardware cryptographic devices such as GPU, USB, and PCIE through the OpenSSL link, it needs to pass through the scheduler first. When the VPP application communicates with the PCIE hardware cryptographic device through the DPDK link, it needs to pass through the scheduler first.

[0074] By implementing an additional scheduler in VPP (i.e., an adaptive heterogeneous task scheduler), it is possible to achieve adaptive task scheduling and load balancing of hardware cryptographic devices, and assign tasks to the most suitable hardware cryptographic devices (hereinafter referred to as target hardware cryptographic devices) according to the encryption task type, thereby improving computing efficiency.

[0075] For example, based on factors such as the encryption task type (such as the cryptographic algorithm type and the data volume level, which can also be called the cryptographic operation scale), computing delay requirements, and load conditions, a target hardware cryptographic device is selected from all hardware cryptographic devices, and the task is assigned to the target hardware cryptographic device.

[0076] By implementing an additional scheduler in VPP and using a scheduling algorithm to allocate tasks, the scheduling algorithm can schedule tasks from the perspectives of performance and load conditions, thereby balancing performance and load and achieving adaptive scheduling of heterogeneous computing frameworks, that is, being able to incorporate an adaptive mechanism into the scheduling algorithm.

[0077] In the embodiment of the present application, an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP is proposed, see Figure 6 FIG. 4 is a flow chart of the method, which may include: Step 601: The VPP application sends to-be-processed data and an encryption task type corresponding to the to-be-processed data to the scheduler. The to-be-processed data is data to be encrypted or data to be decrypted. The encryption task type may include a cryptographic algorithm type (used to indicate the type of the cryptographic algorithm) and a data volume level (used to indicate the size of the data volume).

[0078] For example, the cryptographic algorithm type can be a parallel cryptographic algorithm or a serial cryptographic algorithm. The parallel cryptographic algorithm means that the hardware cryptographic device can encrypt or decrypt multiple data to be processed in parallel, and the serial cryptographic algorithm means that the hardware cryptographic device can encrypt or decrypt multiple data to be processed serially.

[0079] For example, the data volume level can be the first level, the second level or the third level (of course, there can be more data volume levels). The first level indicates that the data volume of the data to be processed is not less than the first threshold, that is, the data volume of the data to be processed is a large-scale data volume, and the data to be processed is relatively large. The third level indicates that the data volume of the data to be processed is not greater than the second threshold, and the second threshold is less than the first threshold, that is, the data volume of the data to be processed is a small-scale data volume, and the data to be processed is relatively small. The second level indicates that the data volume of the data to be processed is between the second threshold and the first threshold, that is, the data volume of the data to be processed is a medium-scale data volume.

[0080] Step 602: The scheduler receives the data to be processed and the encryption task type sent by the VPP application.

[0081] Step 603: The scheduler obtains the current performance parameters of the GPU hardware cryptographic device for the encryption task type, the scheduler obtains the current performance parameters of the USB hardware cryptographic device for the encryption task type, and the scheduler obtains the current performance parameters of the PCIE hardware cryptographic device for the encryption task type.

[0082] Exemplarily, the scheduler sends a first request message to the GPU hardware cryptographic device, and the first request message includes the encryption task type. After receiving the first request message, the GPU hardware cryptographic device obtains the current performance parameters of the GPU hardware cryptographic device for the encryption task type, and returns a first response message to the scheduler, and the first response message includes the current performance parameters. The scheduler receives the first response message returned by the GPU hardware cryptographic device, and obtains the current performance parameters from the first response message.

[0083] For example, the current performance parameters may include but are not limited to the target processing times, and the target processing times indicates the maximum amount of data that can be processed in a unit period when the GPU hardware cryptographic device encrypts or decrypts the pending data of the encryption task type, such as the number of cryptographic operations per second (the unit period is 1 second). The target processing times is a theoretical performance indicator of the GPU hardware cryptographic device, indicating the total processing capacity of the GPU hardware cryptographic device. For example, assuming that the target processing times of the encryption task type is 100, it means that the GPU hardware cryptographic device can process data at most 100 times per second when encrypting or decrypting the pending data of the encryption task type, and the target processing times is related to the capabilities of the GPU hardware cryptographic device.

[0084] When the GPU hardware cryptographic device encrypts or decrypts pending data of different encryption task types, the target processing times may be different. Therefore, the GPU hardware cryptographic device can obtain the encryption task type from the first request message, and then send the target processing times corresponding to the encryption task type to the scheduler.

[0085] For example, if there is one GPU hardware cryptographic device, the GPU hardware cryptographic device is the smallest hardware entity used to implement encryption and decryption, has encryption and decryption resources, and can complete encryption and decryption, then the target processing number is the maximum processing number supported by a GPU hardware cryptographic device. The maximum processing number supported by the GPU hardware cryptographic device is a theoretical performance indicator, which is related to the capability of the GPU hardware cryptographic device and is a fixed value. The maximum processing number supported by the GPU hardware cryptographic device is obtained, and the target processing number is known.

[0086] If there are multiple GPU hardware cryptographic devices, the target processing times is the sum of the maximum processing times supported by all GPU hardware cryptographic devices, that is, the maximum processing times supported by each GPU hardware cryptographic device can be obtained, and then the sum of these maximum processing times is calculated to obtain the target processing times.

[0087] Exemplarily, the scheduler sends a first request message to the USB hardware cryptographic device, and the first request message includes the encryption task type. After receiving the first request message, the USB hardware cryptographic device obtains the current performance parameters of the USB hardware cryptographic device for the encryption task type, and returns a first response message to the scheduler, and the first response message includes the current performance parameters. The scheduler receives the first response message returned by the USB hardware cryptographic device, and obtains the current performance parameters from the first response message.

[0088] Exemplarily, the scheduler sends a first request message to the PCIE hardware cryptographic device, and the first request message includes the encryption task type. After receiving the first request message, the PCIE hardware cryptographic device obtains the current performance parameters of the PCIE hardware cryptographic device for the encryption task type, and returns a first response message to the scheduler, and the first response message includes the current performance parameters. The scheduler receives the first response message returned by the PCIE hardware cryptographic device, and obtains the current performance parameters from the first response message.

[0089] Step 604: The scheduler obtains the current hardware load parameters of the GPU hardware cryptographic device, the current hardware load parameters of the USB hardware cryptographic device, and the current hardware load parameters of the PCIE hardware cryptographic device.

[0090] Exemplarily, the scheduler sends a second request message to the GPU hardware cryptographic device. After receiving the second request message, the GPU hardware cryptographic device obtains the current hardware load parameters of the GPU hardware cryptographic device and returns a second response message to the scheduler, and the second response message includes the current hardware load parameters of the GPU hardware cryptographic device. The scheduler receives the second response message returned by the GPU hardware cryptographic device and obtains the current hardware load parameters of the GPU hardware cryptographic device from the second response message.

[0091] For example, the current hardware load parameters may include device utilization and processing delay. In addition to device utilization and processing delay, the current hardware load parameters may also include data such as throughput and power consumption.

[0092] The device utilization rate can be expressed as the ratio of the actual amount of data processed by the GPU hardware cryptography device in a unit cycle to the maximum amount of data processed by the GPU hardware cryptography device in a unit cycle. Taking a unit cycle of 1 second as an example, if the actual amount of data processed by the GPU hardware cryptography device in 1 second is 200, it means that the GPU hardware cryptography device processes 200 data to be processed in 1 second (which can be the average value over a period of time). The maximum amount of data processed is the total processing capacity of the GPU hardware cryptography device. Assuming that the maximum amount of data processed by the GPU hardware cryptography device in 1 second is 500, it means that the GPU hardware cryptography device processes a maximum of 500 data to be processed in 1 second. On this basis, the device utilization rate of the GPU hardware cryptography device can be 40%.

[0093] The processing delay can represent the time from the start of data reception to the completion of data processing by the GPU hardware cryptographic device. For example, if the GPU hardware cryptographic device receives the data to be processed at time t1, and the data to be processed is processed at time t2, then the time when data reception starts is time t1, the time when data processing is completed is time t2, and the processing delay of the GPU hardware cryptographic device is t2-t1. The average value of the processing delay over a period of time can be calculated and used as the processing delay of the GPU hardware cryptographic device.

[0094] Exemplarily, the scheduler sends a second request message to the USB hardware password device. After receiving the second request message, the USB hardware password device obtains the current hardware load parameter of the USB hardware password device and returns a second response message to the scheduler, and the second response message includes the current hardware load parameter of the USB hardware password device. The scheduler receives the second response message returned by the USB hardware password device, and obtains the current hardware load parameter of the USB hardware password device from the second response message.

[0095] Exemplarily, the scheduler sends a second request message to the PCIE hardware cryptographic device. After receiving the second request message, the PCIE hardware cryptographic device obtains the current hardware load parameters of the PCIE hardware cryptographic device and returns a second response message to the scheduler, and the second response message includes the current hardware load parameters of the PCIE hardware cryptographic device. The scheduler receives the second response message returned by the PCIE hardware cryptographic device and obtains the current hardware load parameters of the PCIE hardware cryptographic device from the second response message.

[0096] Step 605: The scheduler counts the current link load parameters of the OpenSSL link.

[0097] For example, when the VPP application sends data to be processed to the hardware cryptographic device through the OpenSSL link, the data to be processed needs to pass through the scheduler, so the scheduler can count the current link load parameters of the OpenSSL link. For example, the current link load parameters of the OpenSSL link may include but are not limited to the first data processing rate, the first queue length, and the first memory usage size, which are not limited.

[0098] For example, the first data processing rate (the rate at which the OpenSSL link processes data packets) indicates the current rate of data transmitted through the OpenSSL link, that is, the current data transmission rate of the OpenSSL link, which indicates how much data is currently transmitted per second through the OpenSSL link. The average value of the data transmission rate over a period of time can be counted, and the average value of the data transmission rate can be used as the first data processing rate.

[0099] For example, the first queue length (i.e., the length of the queue of data packets waiting to be processed) indicates the total amount of data waiting to be transmitted on the OpenSSL link. For example, when transmitting data through the OpenSSL link, the data is first stored in the queue, and each data in the queue is read in turn and transmitted on the OpenSSL link. In this way, the total amount of data remaining in the queue can be counted, and this total amount of data is used as the first queue length.

[0100] For example, the first memory usage size (i.e., memory usage) indicates the total memory usage size of data waiting to be transmitted on the OpenSSL link. For example, when transmitting data through the OpenSSL link, it is necessary to cache data in a specified storage medium (such as memory), and read each data in the memory in turn to transmit on the OpenSSL link. The memory size occupied by the statistics can be counted, and the memory size is used as the first memory usage size.

[0101] Step 606: The scheduler counts the current link load parameters of the DPDK link.

[0102] When the VPP application sends the data to be processed to the hardware cryptographic device through the DPDK link, the data to be processed needs to pass through the scheduler. Therefore, the scheduler can count the current link load parameters of the DPDK link. For example, the current link load parameters of the DPDK link may include but are not limited to the second data processing rate, the second queue length, and the second memory occupancy size. The second data processing rate represents the current rate of data transmitted through the DPDK link, the second queue length represents the total amount of data waiting to be transmitted on the DPDK link, and the second memory occupancy size represents the total memory occupancy size of data waiting to be transmitted on the DPDK link.

[0103] Step 607: The scheduler obtains the first initial weight, the second initial weight, and the third initial weight corresponding to the encryption task type from the configured weight table. The first initial weight represents the probability that the GPU hardware cryptographic device is assigned to the data to be processed, the second initial weight represents the probability that the USB hardware cryptographic device is assigned to the data to be processed, and the third initial weight represents the probability that the PCIE hardware cryptographic device is assigned to the data to be processed.

[0104] Exemplarily, the scheduler may pre-configure a weight table, which may include a correspondence between encryption task types and initial weights. For example, see Table 1, which is an example of the weight table.

[0105] Table 1

[0106] For each encryption task type in the weight table, the initial weight corresponding to the encryption task type can be configured based on experience, and there is no restriction on this. For example, the sum of all initial weights can be a fixed value (such as 1), for example, initial weight a1+initial weight a2+initial weight a3=1.

[0107] In a possible implementation, for encryption tasks of large-scale parallel cryptographic algorithm types (such as CTR), the data to be processed is preferentially assigned to the GPU hardware cryptographic device. For encryption tasks of small-scale serial cryptographic algorithm types, the data to be processed is preferentially assigned to the USB hardware cryptographic device or the PCIE hardware cryptographic device. Based on the above ideas, if the cryptographic algorithm type in the encryption task type a indicates that the data to be processed is encrypted or decrypted in parallel, that is, the cryptographic algorithm type is a parallel cryptographic algorithm, and the data volume level in the encryption task type a indicates that the data volume of the data to be processed is not less than the first threshold, that is, the data volume level is the first level (indicating a large-scale data volume), then the initial weight a1 can be greater than the initial weight a2, and the initial weight a1 can be greater than the initial weight a3. If the cryptographic algorithm type in the encryption task type b indicates that the data to be processed is encrypted or decrypted serially, that is, the cryptographic algorithm type is a serial cryptographic algorithm, and the data volume level in the encryption task type b indicates that the data volume of the data to be processed is not greater than the second threshold, that is, the data volume level is the third level (indicating a small-scale data volume), then the initial weight b2 can be greater than the initial weight b1, and the initial weight b3 can be greater than the initial weight b1. For encryption task types in other situations, such as the cryptographic algorithm type is a parallel cryptographic algorithm, the data volume level is the second level or the third level, the cryptographic algorithm type is a serial cryptographic algorithm, the data volume level is the first level or the second level, the initial weight can be configured arbitrarily.

[0108] Exemplarily, after obtaining the encryption task type corresponding to the data to be processed, the scheduler can query the weight table shown in Table 1 by the encryption task type to obtain the first initial weight, the second initial weight and the third initial weight corresponding to the encryption task type. Obviously, if the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted in parallel, and the data volume level in the encryption task type indicates that the data volume of the data to be processed is not less than the first threshold, then the first initial weight is greater than the second initial weight, and the first initial weight is greater than the third initial weight, so that the data to be processed is preferentially allocated to the GPU hardware cryptographic device to fully utilize the parallel encryption task processing advantages of the GPU hardware cryptographic device. Alternatively, if the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted serially, and the data volume level in the encryption task type indicates that the data volume of the data to be processed is not greater than the second threshold, then the second initial weight is greater than the first initial weight, and the third initial weight is greater than the first initial weight, so that the data to be processed is preferentially allocated to the USB hardware cryptographic device or the PCIE hardware cryptographic device.

[0109] Step 608: The scheduler determines a first target weight based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight, and determines a first performance score value based on the first target weight. The scheduler determines a second target weight based on the current performance parameters of the USB hardware cryptographic device for the encryption task type and the second initial weight, and determines a second performance score value based on the second target weight. The scheduler determines a third target weight based on the current performance parameters of the PCIE hardware cryptographic device for the encryption task type and the third initial weight, and determines a third performance score value based on the third target weight.

[0110] In a possible implementation, the current performance parameter of the GPU hardware cryptographic device for the encryption task type may include a target processing number. If the target processing number is greater than a third threshold value (which can be configured based on experience, such as the sum of the maximum processing times supported by three GPU hardware cryptographic devices), it indicates that the performance of the GPU hardware cryptographic device has improved, the processing efficiency (computational amount / computational time) of the GPU hardware cryptographic device in the current period has been significantly improved, and the GPU hardware cryptographic device may have expansion and other situations (i.e., the number of GPU hardware cryptographic devices has increased). Therefore, the first initial weight is increased to obtain the first target weight, and the first target weight indicates the probability that the GPU hardware cryptographic device is assigned to data to be processed, that is, the probability that the GPU hardware cryptographic device is assigned to data to be processed increases. In addition, if the target processing number is less than a fourth threshold value (configured based on experience, such as the sum of the maximum processing times supported by two GPU hardware cryptographic devices), and the fourth threshold value is less than the third threshold value, it indicates that the performance of the GPU hardware cryptographic device has deteriorated, the processing efficiency (computational amount / computational time) of the GPU hardware cryptographic device in the current period has decreased, and the GPU hardware cryptographic device may have shrinkage and other situations (i.e., the number of GPU hardware cryptographic devices has decreased). Therefore, the first initial weight is reduced to obtain the first target weight, that is, the probability that the GPU hardware cryptographic device is assigned to data to be processed has decreased.

[0111] If the target processing times is not greater than the third threshold and not less than the fourth threshold, it means that the performance of the GPU hardware cryptographic device remains unchanged and the processing efficiency in the current period remains unchanged. Therefore, the first initial weight is determined as the first target weight, that is, the probability that the GPU hardware cryptographic device is assigned data to be processed remains unchanged.

[0112] After obtaining the first target weight, the first target weight can be a value between 0-1. The scheduler can use the first target weight as the first performance score value, or use a certain algorithm to process the first target weight to obtain the first performance score value. The first performance score value is a value between 0-1.

[0113] In a possible implementation, the scheduler can pre-train a machine learning model (such as a deep learning model or a neural network model, etc.), the input data of the machine learning model is the historical performance data of the GPU hardware cryptographic device, the output data of the machine learning model is the weight adjustment amount, and there is no restriction on the network structure of the machine learning model, and there is no restriction on the training process of the machine learning model. In this way, the first initial weight can be dynamically adjusted by analyzing the historical performance data through the machine learning model.

[0114] The scheduler can obtain historical performance data of the GPU hardware cryptographic device, such as historical performance data of the GPU hardware cryptographic device over the past period of time. The historical performance data may include historical performance parameters and actual processed data volume of the GPU hardware cryptographic device for the encryption task type in the historical time period.

[0115] For example, historical performance parameters may include historical processing times, and the historical processing times represent the maximum amount of data processed in a unit cycle when the GPU hardware cryptographic device encrypts or decrypts the pending data of the encryption task type, such as the number of processing times per second. The historical processing times are similar to the target processing times, and the difference between the two is that the historical processing times can represent the processing times in the historical time period, while the target processing times can represent the processing times in the current time period. Obviously, when the number of GPU hardware cryptographic devices increases or decreases, the historical processing times and the target processing times may be different.

[0116] The actual processed data volume indicates the amount of data processed by the GPU hardware cryptographic device for the encryption task type in the historical time period, such as how much data is processed per second, which can be the average value of the historical time period.

[0117] On this basis, the historical performance data of the GPU hardware cryptographic device can be input into the machine learning model to obtain the weight adjustment amount. There is no restriction on the processing process of the machine learning model, and the machine learning model can output the weight adjustment amount. The weight adjustment amount can be a positive value. For example, when the historical performance data indicates that the performance is better, and the actual amount of data processed indicates that the data is less, the GPU hardware cryptographic device can process more data, so the weight adjustment amount can be a positive value. Alternatively, the weight adjustment amount can be a negative value. For example, when the historical performance data indicates that the performance is poor, and the actual amount of data processed indicates that the data is more, the GPU hardware cryptographic device cannot meet the data processing requirements, so the weight adjustment amount can be a negative value. Alternatively, the weight adjustment amount can be 0. For example, when the historical performance data indicates that the performance is moderate, and the actual amount of data processed indicates that the data is moderate, the GPU hardware cryptographic device can just process the current amount of data, so the weight adjustment amount can be 0.

[0118] After obtaining the weight adjustment amount, the first initial weight may be adjusted based on the weight adjustment amount to obtain an adjusted weight. For example, the adjusted weight may be the sum of the first initial weight and the weight adjustment amount.

[0119] Since the current performance parameter includes the target processing times, if the target processing times is greater than the third threshold, the adjusted weight is increased to obtain the first target weight. Alternatively, if the target processing times is less than the fourth threshold, the adjusted weight is reduced to obtain the first target weight. Alternatively, if the target processing times is not greater than the third threshold and not less than the fourth threshold, the adjusted weight is determined as the first target weight. After obtaining the first target weight, the scheduler may use the first target weight as the first performance score value, or may use a certain algorithm to process the first target weight to obtain the first performance score value, and there is no restriction on this.

[0120] In summary, the scheduler can obtain the first performance score value corresponding to the GPU hardware cryptographic device. Similarly, the scheduler can also obtain the second performance score value corresponding to the USB hardware cryptographic device and the third performance score value corresponding to the PCIE hardware cryptographic device, which will not be repeated here. Obviously, the scheduler can dynamically adjust the target weights of different hardware cryptographic devices according to real-time performance data, automatically increase the target weight of a hardware cryptographic device in task allocation, and allocate more suitable tasks to the hardware cryptographic device.

[0121] Step 609: The scheduler determines a first hardware load score value based on the current hardware load parameters of the GPU hardware cryptographic device, determines a second hardware load score value based on the current hardware load parameters of the USB hardware cryptographic device, and determines a third hardware load score value based on the current hardware load parameters of the PCIE hardware cryptographic device.

[0122] For example, the current hardware load parameters of the GPU hardware cryptographic device include device utilization and processing delay, and the first hardware load score value may be determined based on the device utilization and the processing delay.

[0123] For example, the first hardware load score value is inversely proportional to the device utilization rate. The smaller the device utilization rate, the smaller the load of the GPU hardware cryptographic device. The larger the first hardware load score value, the greater the possibility that the GPU hardware cryptographic device is used as the target hardware cryptographic device. The first hardware load score value is inversely proportional to the processing delay. The smaller the processing delay, the smaller the load of the GPU hardware cryptographic device. The larger the first hardware load score value, the greater the possibility that the GPU hardware cryptographic device is used as the target hardware cryptographic device.

[0124] Regarding how to determine the first hardware load score value based on device utilization and processing delay, there is no limitation in this embodiment. For example, the first hardware load score value can be obtained by performing a weighted operation on the device utilization and processing delay, as long as the first hardware load score value is inversely proportional to the device utilization and processing delay.

[0125] To sum up, the scheduler can obtain the first hardware load score value corresponding to the GPU hardware cryptographic device. Similarly, the scheduler can also obtain the second hardware load score value corresponding to the USB hardware cryptographic device and the third hardware load score value corresponding to the PCIE hardware cryptographic device, which will not be repeated here.

[0126] Step 610: The scheduler determines an OpenSSL link load score value based on the current link load parameter of the OpenSSL link. The scheduler determines a first link load score value allocated to the GPU hardware cryptographic device among the OpenSSL link load score values. The scheduler determines a second link load score value allocated to the USB hardware cryptographic device among the OpenSSL link load score values. And, the scheduler determines a third link load score value allocated to the PCIE hardware cryptographic device among the OpenSSL link load score values.

[0127] For example, the current link load parameters of the OpenSSL link may include a first data processing rate, a first queue length, and a first memory occupancy size, so that the scheduler can determine the OpenSSL link load score value based on the first data processing rate, the first queue length, and the first memory occupancy size.

[0128] For example, the OpenSSL link load score value is proportional to the first data processing rate. The larger the first data processing rate, the smaller the load on the OpenSSL link. The larger the OpenSSL link load score value, the greater the possibility of transmitting the data to be processed through the OpenSSL link. The OpenSSL link load score value is inversely proportional to the first queue length. The larger the first queue length, the larger the load on the OpenSSL link. The smaller the OpenSSL link load score value, the smaller the possibility of transmitting the data to be processed through the OpenSSL link. The OpenSSL link load score value is inversely proportional to the first memory usage size. The larger the first memory usage size, the larger the load on the OpenSSL link. The smaller the OpenSSL link load score value, the smaller the possibility of transmitting the data to be processed through the OpenSSL link.

[0129] Exemplarily, the first allocation weight of the GPU hardware password device, the second allocation weight of the USB hardware password device, and the third allocation weight of the PCIE hardware password device can be pre-configured. There is no restriction on these allocation weights, and the sum of the first allocation weight, the second allocation weight, and the third allocation weight can be 1.

[0130] For example, the first allocation weight, the second allocation weight, and the third allocation weight are all 1 / 3. For another example, the first allocation weight is 0.5, and the second allocation weight and the third allocation weight are all 0.25.

[0131] Exemplarily, the product value of the OpenSSL link load score value and the first allocation weight is used as the first link load score value of the GPU hardware cryptographic device. The product value of the OpenSSL link load score value and the second allocation weight is used as the second link load score value of the USB hardware cryptographic device. The product value of the OpenSSL link load score value and the third allocation weight is used as the third link load score value of the PCIE hardware cryptographic device.

[0132] Step 611: The scheduler determines a DPDK link load score value based on the current link load parameters of the DPDK link. For example, the current link load parameters of the DPDK link may include a second data processing rate, a second queue length, and a second memory occupancy size. Thus, the scheduler may determine the DPDK link load score value based on the second data processing rate, the second queue length, and the second memory occupancy size.

[0133] For example, the DPDK link load score value may be proportional to the second data processing rate, that is, the greater the second data processing rate, the greater the DPDK link load score value. The DPDK link load score value may be inversely proportional to the second queue length, that is, the greater the second queue length, the smaller the DPDK link load score value. The DPDK link load score value may be inversely proportional to the second memory footprint, that is, the greater the second memory footprint, the smaller the DPDK link load score value.

[0134] Step 612: The scheduler obtains the scheduling parameter value of each hardware cryptographic device.

[0135] Exemplarily, the scheduler can determine the scheduling parameter value of the GPU hardware cryptographic device based on the first performance score value of the GPU hardware cryptographic device, the first hardware load score value of the GPU hardware cryptographic device, and the first link load score value of the GPU hardware cryptographic device. Obviously, the scheduling parameter value is proportional to the first performance score value, the scheduling parameter value is proportional to the first hardware load score value, and the scheduling parameter value is proportional to the first link load score value. For example, a weighted operation is performed on the first performance score value, the first hardware load score value, and the first link load score value to obtain the scheduling parameter value of the GPU hardware cryptographic device.

[0136] The scheduler can determine the scheduling parameter value of the USB hardware password device based on the second performance score value of the USB hardware password device, the second hardware load score value of the USB hardware password device, and the second link load score value of the USB hardware password device. Obviously, the scheduling parameter value is proportional to the second performance score value, the scheduling parameter value is proportional to the second hardware load score value, and the scheduling parameter value is proportional to the second link load score value. For example, the second performance score value, the second hardware load score value, and the second link load score value are weighted to obtain the scheduling parameter value of the USB hardware password device.

[0137] The scheduler can determine the scheduling parameter value of the PCIE hardware cryptographic device based on the third performance score value of the PCIE hardware cryptographic device, the third hardware load score value of the PCIE hardware cryptographic device, the third link load score value of the PCIE hardware cryptographic device, and the DPDK link load score value. Obviously, the scheduling parameter value is proportional to the third performance score value, the scheduling parameter value is proportional to the third hardware load score value, the scheduling parameter value is proportional to the third link load score value, and the scheduling parameter value is proportional to the DPDK link load score value. For example, the third performance score value, the third hardware load score value, the third link load score value, and the DPDK link load score value are weighted to obtain the scheduling parameter value of the PCIE hardware cryptographic device.

[0138] Step 613: Based on the scheduling parameter value of each hardware cryptographic device, the scheduler selects a target hardware cryptographic device from multiple hardware cryptographic devices. For example, the scheduler determines the hardware cryptographic device with the largest scheduling parameter value and selects the hardware cryptographic device with the largest scheduling parameter value as the target hardware cryptographic device.

[0139] Step 614: The scheduler sends the data to be processed to the target hardware cryptographic device.

[0140] Exemplarily, if the target hardware cryptographic device is a GPU hardware cryptographic device, the scheduler can send the data to be processed to the GPU transit firmware based on the OpenSSL link, without restricting the transmission process of this OpenSSL link, and send the data to be processed to the GPU hardware cryptographic device through the GPU transit firmware.

[0141] Exemplarily, if the target hardware cryptographic device is a USB hardware cryptographic device, the scheduler can send the data to be processed to the USB transit firmware based on the OpenSSL link, without restricting the transmission process of the OpenSSL link, and send the data to be processed to the USB hardware cryptographic device through the USB transit firmware.

[0142] Exemplarily, if the target hardware cryptographic device is a PCIE hardware cryptographic device, and the link load parameter of the OpenSSL link is better than the link load parameter of the DPDK link (i.e., the link load parameter of the OpenSSL link is greater than the link load parameter of the DPDK link), the scheduler can send the data to be processed to the PCIE transit firmware based on the OpenSSL link, without restricting the transmission process of the OpenSSL link, and send the data to be processed to the PCIE hardware cryptographic device through the PCIE transit firmware. Or, If the link load parameter of the DPDK link is better than the link load parameter of the OpenSSL link (that is, the link load parameter of the DPDK link is greater than the link load parameter of the OpenSSL link), the scheduler can send the data to be processed to the PCIE transit firmware based on the DPDK link, without restricting the transmission process of this DPDK link, and send the data to be processed to the PCIE hardware cryptographic device through the PCIE transit firmware.

[0143] Exemplarily, after receiving the data to be processed, if the data to be processed is data to be encrypted, the target hardware cryptographic device encrypts the data to be encrypted and returns the encryption result (i.e., encrypted data) to the VPP application, without any restriction on this transmission process.

[0144] Alternatively, after receiving the data to be processed, if the data to be processed is data to be decrypted, the target hardware cryptographic device decrypts the data to be decrypted and returns the decoding result (i.e., the decrypted data) to the VPP application, and there is no restriction on this transmission process.

[0145] As can be seen from the above technical solutions, in the embodiment of the present application, under the VPP application, by deploying the DPDK link and the OpenSSL link, GPU hardware cryptographic devices, USB hardware cryptographic devices and PCIE hardware cryptographic devices can be supported at the same time. By additionally deploying the scheduler, the overall cryptographic operation performance of the system can be improved, and high-performance encryption or decryption can be achieved. It is possible to realize heterogeneous computing of hardware cryptographic devices based on VPP, integrate adaptive mechanisms into the scheduling algorithm, perform task scheduling based on performance parameters and load parameters, and dynamically and efficiently allocate data packet processing tasks to target hardware cryptographic devices. It is possible to take advantage of the advantages of the heterogeneous computing framework to improve overall computing performance and computing efficiency. It is possible to realize intelligent load balancing based on heterogeneous computing, realize adaptive heterogeneous computing mechanisms in VPP, and dynamically and efficiently allocate data packet processing tasks to target hardware cryptographic devices according to the type of encryption tasks, data characteristics and load conditions, thereby improving computing efficiency. According to the computing advantages of each hardware cryptographic device and the real-time load conditions of each hardware cryptographic device and core, resource allocation is optimized to improve overall system performance. It can support a variety of hardware cryptographic devices, such as GPU hardware cryptographic devices, USB hardware cryptographic devices, and PCI E hardware cryptographic devices, allowing users to choose the most suitable hardware cryptographic devices according to their own needs and hardware resources to improve flexibility. By utilizing different types of hardware cryptographic devices, performance and cost can be better balanced. For example, GPU hardware cryptographic devices are suitable for processing a large number of parallel encryption tasks, and USB hardware cryptographic devices provide convenient plug-and-play functions. When multiple hardware cryptographic devices are available, encryption tasks can be evenly distributed to avoid overloading a single node. Task scheduling is performed based on performance and load conditions, and changes in the system operation status are monitored in real time. For example, when the type of encryption task changes from serial tasks to large-scale parallel tasks, the scheduling algorithm can automatically sense and adjust the task allocation strategy, complete device communication according to different types of hardware cryptographic devices, and take advantage of the heterogeneous computing framework to improve the overall computing performance of the system.

[0146] Based on the same application concept as the above method, an adaptive scheduling and communication device for heterogeneous computing of hardware cryptographic devices based on VPP is proposed in an embodiment of the present application, which is used to adaptively schedule multiple hardware cryptographic devices. The device includes: a VPP application module, which is used to send to-be-processed data and the encryption task type corresponding to the to-be-processed data to a scheduler; wherein the encryption task type includes a cryptographic algorithm type and a data volume level; a scheduler, which is used to receive the to-be-processed data and the encryption task type, obtain the scheduling parameter value of each hardware cryptographic device, and select a target hardware cryptographic device from the multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device; wherein the multiple hardware cryptographic devices include a GPU hardware cryptographic device, a USB hardware cryptographic device and a PCIE hardware cryptographic device; the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device and the PCIE through an OpenSSL link. The VPP application communicates with the PCIE hardware cryptographic device through a DPDK link; wherein the scheduling parameter value of the GPU hardware cryptographic device is determined based on the encryption task type, the performance parameters of the GPU hardware cryptographic device, the hardware load parameters of the GPU hardware cryptographic device, and the link load parameters of the OpenSSL link; the scheduling parameter value of the USB hardware cryptographic device is determined based on the encryption task type, the performance parameters of the USB hardware cryptographic device, the hardware load parameters of the USB hardware cryptographic device, and the link load parameters of the OpenSSL link; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the encryption task type, the performance parameters of the PCIE hardware cryptographic device, the hardware load parameters of the PCIE hardware cryptographic device, the link load parameters of the OpenSSL link, and the link load parameters of the DPDK link; The scheduler is further used to send the data to be processed to the target hardware cryptographic device; Among them, if the data to be processed is data to be encrypted, the data to be encrypted is encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted is decrypted by the target hardware cryptographic device.

[0147] Exemplarily, when the scheduler obtains the scheduling parameter value of the GPU hardware cryptographic device, the scheduling parameter value of the USB hardware cryptographic device, and the scheduling parameter value of the PCIE hardware cryptographic device, it is specifically used to: obtain the first initial weight, the second initial weight, and the third initial weight corresponding to the encryption task type from the configured weight table; wherein the weight table includes the corresponding relationship between the encryption task type and the initial weight; the first initial weight represents the probability that the GPU hardware cryptographic device is assigned to the data to be processed, the second initial weight represents the probability that the USB hardware cryptographic device is assigned to the data to be processed, and the third initial weight represents the probability that the PCIE hardware cryptographic device is assigned to the data to be processed; Determine a first target weight based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight, and determine a first performance score value based on the first target weight; determine a second target weight based on the current performance parameters of the USB hardware cryptographic device for the encryption task type and the second initial weight, and determine a second performance score value based on the second target weight; determine a third target weight based on the current performance parameters of the PCIE hardware cryptographic device for the encryption task type and the third initial weight, and determine a third performance score value based on the third target weight; Determine a first hardware load score value based on the current hardware load parameters of the GPU hardware cryptographic device, determine a second hardware load score value based on the current hardware load parameters of the USB hardware cryptographic device, and determine a third hardware load score value based on the current hardware load parameters of the PCIE hardware cryptographic device; Determine an OpenSSL link load score value based on a current link load parameter of the OpenSSL link, and determine a first link load score value allocated to the GPU hardware cryptographic device, a second link load score value allocated to the USB hardware cryptographic device, and a third link load score value allocated to the PCIE hardware cryptographic device among the OpenSSL link load score values; Determining a DPDK link load score value based on a current link load parameter of the DPDK link; The scheduling parameter value of the GPU hardware cryptographic device is determined based on the first performance score value, the first hardware load score value and the first link load score value; the scheduling parameter value of the USB hardware cryptographic device is determined based on the second performance score value, the second hardware load score value and the second link load score value; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the third performance score value, the third hardware load score value, the third link load score value and the DPDK link load score value.

[0148] Based on the same application concept as the above method, the present application embodiment proposes an electronic device, see Figure 7 As shown, it includes: a processor 71 and a machine-readable storage medium 72, the machine-readable storage medium 72 stores machine-executable instructions that can be executed by the processor 71; the processor 71 is used to execute the machine-executable instructions to implement an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP.

[0149] Based on the same application concept as the above method, an embodiment of the present application also provides a machine-readable storage medium, on which a number of computer instructions are stored. When the computer instructions are executed by a processor, an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP can be implemented.

[0150] The above-mentioned machine-readable storage medium may be any electronic, magnetic, optical or other physical storage device, which may contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium may be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as optical disk, DVD, etc.), or similar storage medium, or a combination thereof.

[0151] Based on the same application concept as the above method, an embodiment of the present application also provides a computer program product, which may include a computer program, and when the computer program is executed by a processor, it implements an adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on VPP.

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

[0153] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. An adaptive scheduling and communication method for heterogeneous computing of hardware cryptographic devices based on vector packet processing (VPP), which is used to adaptively schedule multiple hardware cryptographic devices, characterized in that: The method comprises: Receiving the data to be processed sent by the VPP application through the scheduler, and obtaining the encryption task type corresponding to the data to be processed through the scheduler, wherein the encryption task type includes the cryptographic algorithm type and the data volume level; Obtaining the scheduling parameter value of each hardware cryptographic device through the scheduler, and selecting a target hardware cryptographic device from the multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device; wherein the multiple hardware cryptographic devices include a GPU hardware cryptographic device, a USB hardware cryptographic device and a PCIE hardware cryptographic device; the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device and the PCIE hardware cryptographic device through an OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through a DPDK link; the scheduling parameter value of the GPU hardware cryptographic device is determined based on the encryption task type, the performance parameter of the GPU hardware cryptographic device, the hardware load parameter of the GPU hardware cryptographic device and the link load parameter of the OpenSSL link; the scheduling parameter value of the USB hardware cryptographic device is determined based on the encryption task type, the performance parameter of the USB hardware cryptographic device, the hardware load parameter of the USB hardware cryptographic device and the link load parameter of the OpenSSL link; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the encryption task type, the performance parameter of the PCIE hardware cryptographic device, the hardware load parameter of the PCIE hardware cryptographic device, the link load parameter of the OpenSSL link and the link load parameter of the DPDK link; Sending the data to be processed to the target hardware cryptographic device through the scheduler; Among them, if the data to be processed is data to be encrypted, the data to be encrypted is encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted is decrypted by the target hardware cryptographic device.

2. The method according to claim 1, characterized in that The process of obtaining the scheduling parameter value of the GPU hardware cryptographic device, the scheduling parameter value of the USB hardware cryptographic device, and the scheduling parameter value of the PCIE hardware cryptographic device specifically includes: Obtaining a first initial weight, a second initial weight, and a third initial weight corresponding to the encryption task type from a configured weight table; wherein the weight table includes a correspondence between the encryption task type and the initial weight; the first initial weight represents a probability that the GPU hardware cryptographic device is assigned data to be processed, the second initial weight represents a probability that the USB hardware cryptographic device is assigned data to be processed, and the third initial weight represents a probability that the PCIE hardware cryptographic device is assigned data to be processed; Determine a first target weight based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight, and determine a first performance score value based on the first target weight; determine a second target weight based on the current performance parameters of the USB hardware cryptographic device for the encryption task type and the second initial weight, and determine a second performance score value based on the second target weight; determine a third target weight based on the current performance parameters of the PCIE hardware cryptographic device for the encryption task type and the third initial weight, and determine a third performance score value based on the third target weight; Determine a first hardware load score value based on the current hardware load parameters of the GPU hardware cryptographic device, determine a second hardware load score value based on the current hardware load parameters of the USB hardware cryptographic device, and determine a third hardware load score value based on the current hardware load parameters of the PCIE hardware cryptographic device; Determine an OpenSSL link load score value based on a current link load parameter of the OpenSSL link, and determine a first link load score value allocated to the GPU hardware cryptographic device, a second link load score value allocated to the USB hardware cryptographic device, and a third link load score value allocated to the PCIE hardware cryptographic device among the OpenSSL link load score values; Determining a DPDK link load score value based on a current link load parameter of the DPDK link; The scheduling parameter value of the GPU hardware cryptographic device is determined based on the first performance score value, the first hardware load score value and the first link load score value; the scheduling parameter value of the USB hardware cryptographic device is determined based on the second performance score value, the second hardware load score value and the second link load score value; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the third performance score value, the third hardware load score value, the third link load score value and the DPDK link load score value.

3. The method according to claim 2, characterized in that If the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted in parallel, and the data amount level in the encryption task type indicates that the amount of the data to be processed is not less than a first threshold, then the first initial weight is greater than the second initial weight, and the first initial weight is greater than the third initial weight; If the cryptographic algorithm type in the encryption task type indicates that the data to be processed is encrypted or decrypted serially, and the data amount level in the encryption task type indicates that the data amount of the data to be processed is not greater than the second threshold, and the second threshold is less than the first threshold, then the second initial weight is greater than the first initial weight, and the third initial weight is greater than the first initial weight.

4. The method according to claim 2, characterized in that: The determining of the first target weight based on the current performance parameter of the GPU hardware cryptographic device for the encryption task type and the first initial weight specifically includes: Sending a first request message to the GPU hardware cryptographic device through a scheduler, wherein the first request message includes the encryption task type; receiving a first response message returned by the GPU hardware cryptographic device through the scheduler, wherein the first response message includes the current performance parameter; the current performance parameter includes a target processing number, wherein the target processing number indicates the maximum amount of data processed within a unit cycle when the GPU hardware cryptographic device encrypts or decrypts the to-be-processed data of the encryption task type; wherein, if there is one GPU hardware cryptographic device, the target processing number is the maximum processing number supported by one GPU hardware cryptographic device; and if there are multiple GPU hardware cryptographic devices, the target processing number is the sum of the maximum processing numbers supported by multiple GPU hardware cryptographic devices; If the target processing times is greater than a third threshold, the first initial weight is increased to obtain a first target weight; if the target processing times is less than a fourth threshold, and the fourth threshold is less than the third threshold, the first initial weight is reduced to obtain a first target weight; if the target processing times is not greater than the third threshold and not less than the fourth threshold, the first initial weight is determined as the first target weight; Alternatively, the historical performance data of the GPU hardware cryptographic device is input into a trained machine learning model to obtain a weight adjustment amount, and the first initial weight is adjusted based on the weight adjustment amount to obtain an adjusted weight; if the target processing number is greater than a third threshold, the adjusted weight is increased to obtain the first target weight; if the target processing number is less than a fourth threshold, the adjusted weight is reduced to obtain the first target weight; if the target processing number is not greater than the third threshold and not less than the fourth threshold, the adjusted weight is determined as the first target weight; The historical performance data at least includes historical performance parameters and actual processed data volume of the GPU hardware cryptographic device for the encryption task type in a historical time period.

5. The method according to claim 2, characterized in that: The determining of the first hardware load score value based on the current hardware load parameter of the GPU hardware cryptographic device includes: Sending a second request message to the GPU hardware cryptographic device through a scheduler, and receiving a second response message returned by the GPU hardware cryptographic device through the scheduler, wherein the second response message includes the current hardware load parameter, and the current hardware load parameter includes device utilization and processing delay; wherein the device utilization represents the ratio of the actual amount of data processed by the GPU hardware cryptographic device in a unit cycle to the maximum amount of data processed by the GPU hardware cryptographic device in a unit cycle, and the processing delay represents the time from the start of data reception to the completion of data processing by the GPU hardware cryptographic device; The first hardware load score value is determined based on the device utilization and the processing delay.

6. The method according to claim 2, characterized in that The determining of the OpenSSL link load score value based on the current link load parameter of the OpenSSL link comprises: The current link load parameters of the OpenSSL link are counted by the scheduler, and the current link load parameters of the OpenSSL link include a first data processing rate, a first queue length, and a first memory occupancy size; the first data processing rate represents the current rate of data transmitted through the OpenSSL link, the first queue length represents the total amount of data waiting to be transmitted on the OpenSSL link, and the first memory occupancy size represents the total memory occupancy size of data waiting to be transmitted on the OpenSSL link; Determine the OpenSSL link load score value based on the first data processing rate, the first queue length, and the first memory occupancy size, wherein the OpenSSL link load score value is proportional to the first data processing rate and inversely proportional to the first queue length and the first memory occupancy size; The determining of the DPDK link load score value based on the current link load parameter of the DPDK link includes: counting the current link load parameter of the DPDK link through a scheduler, wherein the current link load parameter of the DPDK link includes a second data processing rate, a second queue length, and a second memory occupancy size; the second data processing rate represents the current rate of data transmitted through the DPDK link, the second queue length represents the total amount of data waiting to be transmitted on the DPDK link, and the second memory occupancy size represents the total memory occupancy size of data waiting to be transmitted on the DPDK link; The DPDK link load score value is determined based on the second data processing rate, the second queue length, and the second memory occupancy size, wherein the DPDK link load score value is proportional to the second data processing rate and inversely proportional to the second queue length and the second memory occupancy size.

7. The method according to claim 1, characterized in that The sending the to-be-processed data to the target hardware cryptographic device through the scheduler includes: If the target hardware cryptographic device is the GPU hardware cryptographic device, sending the data to be processed to the GPU transit firmware based on the OpenSSL link through the scheduler, and sending the data to be processed to the GPU hardware cryptographic device through the GPU transit firmware; If the target hardware cryptographic device is the USB hardware cryptographic device, the data to be processed is sent to the USB transit firmware based on the OpenSSL link by the scheduler, and the data to be processed is sent to the USB hardware cryptographic device by the USB transit firmware; If the target hardware cryptographic device is the PCIE hardware cryptographic device, and the link load parameter of the OpenSSL link is better than the link load parameter of the DPDK link, the data to be processed is sent to the PCIE transit firmware based on the OpenSSL link through the scheduler, and the data to be processed is sent to the PCIE hardware cryptographic device through the PCIE transit firmware; or, if the link load parameter of the DPDK link is better than the link load parameter of the OpenSSL link, the data to be processed is sent to the PCIE transit firmware based on the DPDK link through the scheduler, and the data to be processed is sent to the PCIE hardware cryptographic device through the PCIE transit firmware.

8. The method according to any one of claims 1 to 7, characterized in that: The OpenSSL link includes an open secure socket layer encryption application programming interface OpenSSL Crypto API, an open secure socket layer engine OpenSSL Engine, and a kernel driver Kernel Driver of an operating system in sequence; The DPDK link includes in sequence the data plane development kit encryption library application programming interface DPDK CryptoDevAPI, the encryption library polling mode driver CryptoDev PMD, the virtual function input and output VFIO or the user space input and output UIO driver, and the data buffer.

9. An adaptive scheduling and communication device for heterogeneous computing of hardware cryptographic devices based on vector packet processing (VPP), used for adaptive scheduling of multiple hardware cryptographic devices, characterized in that: include: A VPP application module, used to send the data to be processed and the encryption task type corresponding to the data to be processed to the scheduler; wherein the encryption task type includes the cryptographic algorithm type and the data volume level; A scheduler is used to receive the data to be processed and the encryption task type, obtain the scheduling parameter value of each hardware cryptographic device, and select a target hardware cryptographic device from the multiple hardware cryptographic devices based on the scheduling parameter value of each hardware cryptographic device; wherein the multiple hardware cryptographic devices include a GPU hardware cryptographic device, a USB hardware cryptographic device, and a PCIE hardware cryptographic device; the VPP application communicates with the GPU hardware cryptographic device, the USB hardware cryptographic device, and the PCIE hardware cryptographic device through an OpenSSL link, and the VPP application communicates with the PCIE hardware cryptographic device through a DPDK link; wherein the scheduling parameter value of the GPU hardware cryptographic device is based on the encryption task type, The performance parameters of the GPU hardware cryptographic device, the hardware load parameters of the GPU hardware cryptographic device, and the link load parameters of the OpenSSL link are determined; the scheduling parameter value of the USB hardware cryptographic device is determined based on the encryption task type, the performance parameters of the USB hardware cryptographic device, the hardware load parameters of the USB hardware cryptographic device, and the link load parameters of the OpenSSL link; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the encryption task type, the performance parameters of the PCIE hardware cryptographic device, the hardware load parameters of the PCIE hardware cryptographic device, the link load parameters of the OpenSSL link, and the link load parameters of the DPDK link; The scheduler is further used to send the data to be processed to the target hardware cryptographic device; Among them, if the data to be processed is data to be encrypted, the data to be encrypted is encrypted by the target hardware cryptographic device; or, if the data to be processed is data to be decrypted, the data to be decrypted is decrypted by the target hardware cryptographic device.

10. The device according to claim 9, characterized in that The scheduler obtains the scheduling parameter value of the GPU hardware cryptographic device, the scheduling parameter value of the USB hardware cryptographic device, and the scheduling parameter value of the PCIE hardware cryptographic device for: Obtaining a first initial weight, a second initial weight, and a third initial weight corresponding to the encryption task type from a configured weight table; wherein the weight table includes a correspondence between the encryption task type and the initial weight; the first initial weight represents a probability that the GPU hardware cryptographic device is assigned data to be processed, the second initial weight represents a probability that the USB hardware cryptographic device is assigned data to be processed, and the third initial weight represents a probability that the PCIE hardware cryptographic device is assigned data to be processed; Determine a first target weight based on the current performance parameters of the GPU hardware cryptographic device for the encryption task type and the first initial weight, and determine a first performance score value based on the first target weight; determine a second target weight based on the current performance parameters of the USB hardware cryptographic device for the encryption task type and the second initial weight, and determine a second performance score value based on the second target weight; determine a third target weight based on the current performance parameters of the PCIE hardware cryptographic device for the encryption task type and the third initial weight, and determine a third performance score value based on the third target weight; Determine a first hardware load score value based on the current hardware load parameters of the GPU hardware cryptographic device, determine a second hardware load score value based on the current hardware load parameters of the USB hardware cryptographic device, and determine a third hardware load score value based on the current hardware load parameters of the PCIE hardware cryptographic device; Determine an OpenSSL link load score value based on a current link load parameter of the OpenSSL link, and determine a first link load score value allocated to the GPU hardware cryptographic device, a second link load score value allocated to the USB hardware cryptographic device, and a third link load score value allocated to the PCIE hardware cryptographic device among the OpenSSL link load score values; Determining a DPDK link load score value based on a current link load parameter of the DPDK link; The scheduling parameter value of the GPU hardware cryptographic device is determined based on the first performance score value, the first hardware load score value and the first link load score value; the scheduling parameter value of the USB hardware cryptographic device is determined based on the second performance score value, the second hardware load score value and the second link load score value; the scheduling parameter value of the PCIE hardware cryptographic device is determined based on the third performance score value, the third hardware load score value, the third link load score value and the DPDK link load score value.

Images