A network function virtualization system based on graphics processor acceleration optimization

Abstract

The application relates to a network function virtualization system based on graphics processor acceleration optimization, which comprises a GPU shared buffer opened in GPU memory, a network function service chain composed of multiple virtual network function modules, and the running mode of each virtual network function module adopts one of the following three modes: mode one, CPU running, mode two, GPU running, and mode three, GPU running in cooperation with the GPU shared buffer; the system designs a multi-flow GPU scheduling mode; when the network function service chain is a heterogeneous network function service chain, the heterogeneous network function service chain runs based on a heterogeneous service chain synchronization mechanism to realize data packet synchronization. Compared with the prior art, the application reduces the data volume of memory copying between VNFs, maximally utilizes hardware resources, and realizes data synchronization between heterogeneous VNFs.

Description

Technical Field

[0001] This invention relates to the field of network function virtualization technology, and in particular to a network function virtualization system based on graphics processor acceleration optimization. Background Technology

[0002] Network Function Virtualization (NFV) technology virtualizes network functions that previously could only operate on specific hardware onto a general-purpose platform. This allows software-defined network functions to replace traditional hardware network functions, making the implementation, deployment, and management of network functions more convenient. In an NFV system, a service chain is formed by various custom virtualized network functions (VNFs) to provide customized network services. The input of each VNF in the service chain is the output of the VNF above it; logically, a service chain can be viewed as a singly linked list. With increasing network bandwidth, improving the performance of NFV systems is crucial for providing high-quality network services.

[0003] Graphics Processing Units (GPUs) typically contain a large number of computing cores, making them ideal as parallel computing accelerators. For example, accelerating computationally intensive encryption algorithms frequently used in network services with GPUs can significantly improve performance. Therefore, introducing GPUs into Network Functions Virtualization (NFV) systems to optimize each Virtual Service Provider (VNF) in the service chain can improve the overall system performance. Compared to traditional CPU-based NFV systems, GPU-based NFV systems, while offering performance improvements, also face several challenges.

[0004] In an NFV system, how each VNF (Virtual Functions) utilizes the GPU directly impacts the system's final performance. In traditional GPU-based NFV systems, each VNF in the service chain independently uses the GPU. Each data packet is repeatedly transferred to the GPU memory via PCI-E as it is processed by different VNFs. The PCI-E transfer overhead is significant, and repeated PCI-E data transfers can diminish the performance gains from GPU acceleration, potentially leading to performance inferior to CPU-based NFV systems. Therefore, when using GPU-accelerated NFV systems, repeated PCI-E data transfers must be avoided. Furthermore, in traditional NFV system service chains, data packets need to be completely copied between VNFs, resulting in substantial memory copy overhead, which also affects overall system performance. This memory copy overhead can be optimized using zero-copy techniques.

[0005] In NFV systems, each VNF needs to copy different data to the GPU and its execution algorithm is not the same. Providing a separate implementation for each VNF would make the system too large and difficult to maintain. In traditional NFV systems, each VNF runs as a separate process. After a VNF utilizes the GPU, VNFs in different GPU contexts cannot access GPU data in other VNFs without using specific cross-GPU inter-process communication methods. Therefore, a mechanism is needed to allow different VNFs to be in the same GPU context and access GPU operations in a consistent manner.

[0006] Virtual Network Functions (VNFs) typically employ a multi-threaded execution mode. In traditional synchronous multi-threaded mode, VNFs need to wait for one batch of data packets to complete GPU operations before processing the next batch. Furthermore, this mode cannot alternate between CPU and GPU operations; when running GPU operations, the CPU can only block and wait, resulting in low hardware resource utilization and severely impacting overall system performance. Therefore, an efficient VNF ​​multi-threaded execution mechanism is needed to maximize the utilization of hardware resources.

[0007] For some I / O-intensive VNFs, such as routers, using the CPU for computation is more efficient than using the GPU. Therefore, each VNF needs to select the appropriate device to run on based on its computationally or I / O-intensive characteristics. When heterogeneity occurs in the service chain, some VNFs may run on the CPU, modifying data packets in the host memory, while other VNFs run on the GPU, modifying data packets in the GPU's video memory. This can lead to data inconsistency. While directly synchronizing the entire data packet between VNFs can solve this problem, it is limited by PCI-E transmission and will affect the overall system performance. Therefore, a heterogeneous VNF service chain data synchronization mechanism is needed. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a heterogeneous network function virtualization system based on graphics processor acceleration optimization.

[0009] The objective of this invention can be achieved through the following technical solutions:

[0010] A network function virtualization system based on graphics processor acceleration optimization, the system comprising:

[0011] GPU shared buffer: allocated in GPU video memory;

[0012] Network Function Service Chain: The network function service chain consists of multiple virtual network function modules. Each virtual network function module operates in one of the following three ways: Method 1: running using CPU; Method 2: running using GPU; Method 3: running using GPU and cooperating with GPU shared buffer.

[0013] The system is designed with a multi-pipeline GPU scheduling mode;

[0014] When a network function service chain includes at least two virtual network function modules with different operating modes, the network function service chain is called a heterogeneous network function service chain. The heterogeneous network function service chain performs data packet synchronization based on the heterogeneous service chain synchronization mechanism during operation.

[0015] Preferably, the system adopts a multi-process, multi-threaded hybrid programming model, with each virtual network function module and the network function virtualization system itself as separate processes, interacting with each other through lock-free queues and shared memory, and each virtual network function module adopting a multi-threaded programming mode.

[0016] Preferably, each virtual network function module includes two types of threads:

[0017] CPU stage processing thread: responsible for tasks including receiving, forwarding, preprocessing, and postprocessing data packets;

[0018] GPU stage processing thread: responsible for sending specific GPU operation requests to the GPU call execution process.

[0019] Preferably, the CPU stage processing thread and the GPU stage processing thread adopt a three-buffer alternating processing method, wherein the three buffers include a preprocessing buffer and a postprocessing buffer executed by the CPU stage processing thread, and a GPU processing buffer executed by the GPU stage processing thread.

[0020] Preferably, the heterogeneous service chain synchronization mechanism is as follows:

[0021] An independent runtime plan generator is set up, which determines the running mode and specific running scheme of each virtual network function module based on the configuration of the network function service chain. The running scheme includes read / write data domains, synchronization data domains, GPU shared buffer usage flags, and virtual network function algorithm input / output methods. The virtual network function modules obtain GPU kernel functions that satisfy the current running scheme based on their respective running schemes. When the virtual network function modules in the heterogeneous network function service chain run sequentially, the GPU kernel functions are executed to synchronize the data packets in the GPU shared buffer and CPU memory.

[0022] Preferably, the system is operated as follows:

[0023] The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and CPU memory.

[0024] Each virtual network functional module operates based on a defined operating mode and specific operating plan. During operation, data packets are synchronized based on a heterogeneous service chain synchronization mechanism until the last virtual network functional module completes operation.

[0025] The processed data packets are sent out through the data packet transceiver module.

[0026] Preferably, when all virtual network function modules in the network function service chain are operating in mode three, the specific operation method is as follows:

[0027] The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and determines the data packet pointer.

[0028] The GPU copy thread module sends the packet pointer information to the first virtual network function module on the network function service chain;

[0029] The virtual network function module sends the packet pointer information and GPU call request to the GPU scheduler to execute GPU operations. The virtual network function modules on the network function service chain process the packets and pass the packet pointer information in turn.

[0030] After the GPU call request in the network function service chain is completed, the GPU copy thread module copies the data packet processed by the GPU shared buffer to the data packet transceiver module and sends it out.

[0031] Preferably, the GPU copy thread module receives a fixed number of data packets as a batch each time. Before copying the data packets to the GPU shared buffer, it will form a group of batches into blocks according to the average size of the current batch of data packets, and copy the data packets into the GPU shared buffer in units of blocks. At the same time, it will record the data packet pointer information of each data packet in the GPU shared buffer.

[0032] Preferably, each virtual network function module uses a batch size as the smallest unit for processing data.

[0033] Preferably, after the data packet is processed by the network function service chain, the data packet forwarding module receives the pointer information of the data packet batch transmitted by the last virtual network function module, waits for all batches of the block to which the data packet batch belongs to be received, and then copies the data packet block together from the GPU shared buffer to the virtual network function module through the GPU copy thread module.

[0034] Compared with the prior art, the present invention has the following advantages:

[0035] This invention addresses the issue of redundant PCI-E data copying caused by multiple Virtual Network Function Modules (VNFs) individually occupying the GPU by providing a shared GPU memory buffer for multiple VNFs. This reduces the amount of data copied between VNFs and ensures that the order of data packets is not disrupted. Furthermore, it proposes a multi-pipeline GPU scheduling mode, allowing multiple VNFs to share a single GPU context. Multi-pipeline scheduling enables GPU and CPU to overlap, maximizing hardware resource utilization. Based on this, a heterogeneous service chain synchronization mechanism is proposed for heterogeneous network function service chains. This mechanism achieves data synchronization between heterogeneous VNFs at minimal cost while ensuring that each VNF operates optimally. Attached Figure Description

[0036] Figure 1 This is a diagram illustrating the overall architecture of the system in an embodiment of the present invention.

[0037] Figure 2 This is a diagram of the GPU shared buffer architecture in an embodiment of the present invention;

[0038] Figure 3 This is a schematic diagram of multi-pipeline GPU scheduling in an embodiment of the present invention. Detailed Implementation

[0039] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. Note that the following description of the embodiments is merely illustrative and is not intended to limit its applicability or use, nor is the present invention limited to the following embodiments.

[0040] Example

[0041] like Figure 1 As shown, this embodiment provides a network function virtualization system based on graphics processor acceleration optimization. The system includes:

[0042] GPU shared buffer: allocated in GPU video memory;

[0043] Network Function Service Chain: A network function service chain is composed of multiple virtual network function modules. Each virtual network function module can be run in one of the following three ways: Method 1: running using CPU; Method 2: running using GPU; Method 3: running using GPU and cooperating with GPU shared buffer.

[0044] The system is designed with a multi-pipeline GPU scheduling mode;

[0045] When a network function service chain includes at least two virtual network function modules with different operating modes, the network function service chain is called a heterogeneous network function service chain. The heterogeneous network function service chain synchronizes data packets based on the heterogeneous service chain synchronization mechanism during operation.

[0046] This invention addresses the issue of redundant PCI-E data copying caused by multiple Virtual Network Functions (VNFs) individually occupying the GPU by providing a shared GPU memory buffer for each VNF. This reduces the amount of data copied between VNFs and ensures that packet order is not disrupted. Simultaneously, the system employs a multi-pipeline GPU scheduling mode, allowing multiple VNFs to share a single GPU context. Multi-pipeline scheduling utilizes the GPU, enabling overlapping operation of the GPU and CPU to maximize hardware resource utilization. For heterogeneous service chains, a heterogeneous VNF service chain synchronization mechanism is proposed, achieving data synchronization between heterogeneous VNFs at minimal cost while ensuring optimal operation for each VNF.

[0047] Among them, the multi-pipeline GPU scheduling mode, through a programming model that combines multi-process and multi-thread, and with a three-buffer pipeline, enables VNF to efficiently utilize GPU computing while allowing the processor (CPU) to process read and write (IO) and other tasks in parallel, avoiding the latency overhead of synchronous execution.

[0048] Specifically:

[0049] The system employs a multi-process, multi-threaded hybrid programming model. Each virtual network function module and the network function virtualization system itself operate as separate processes, interacting via lock-free queues and shared memory. Each virtual network function module utilizes a multi-threaded programming model. Each virtual network function module includes two types of threads: CPU-stage processing threads, responsible for tasks such as packet reception, forwarding, preprocessing, and post-processing; and GPU-stage processing threads, responsible for sending specific GPU operation requests to the GPU execution process. The CPU-stage and GPU-stage processing threads use a three-buffer alternating processing method. The three buffers include a preprocessing buffer and a post-processing buffer for CPU-stage processing, and a GPU processing buffer for GPU-stage processing.

[0050] The heterogeneous VNF service chain synchronization mechanism addresses data inconsistency issues caused by heterogeneous VNFs on different devices by using a Running Plan Generator implemented with a deep search multi-way tree and a Dynamic Kernel implemented with dynamic pre-compiled commands, while also reducing the copy overhead associated with synchronizing data between VNFs.

[0051] Specifically, an independent runtime plan generator is set up, which determines the running mode and specific running scheme of each virtual network function module based on the configuration of the network function service chain. The running scheme includes reading and writing data domains, synchronizing data domains, GPU shared buffer usage flags, and virtual network function algorithm input and output methods. The virtual network function modules obtain GPU kernel functions that satisfy the current running scheme based on their respective running schemes. When the virtual network function modules in the heterogeneous network function service chain run in sequence, the GPU kernel functions are executed to synchronize the data packets in the GPU shared buffer and CPU memory.

[0052] The following is a detailed explanation of how the system operates:

[0053] The overall operation process of the system is as follows:

[0054] The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and CPU memory.

[0055] Each virtual network functional module operates based on a defined operating mode and specific operating plan. During operation, data packets are synchronized based on a heterogeneous service chain synchronization mechanism until the last virtual network functional module completes operation.

[0056] The processed data packets are sent out through the data packet transceiver module.

[0057] In a preferred embodiment, when all virtual network function modules in the network function service chain are operating in mode three, the specific operation method is as follows:

[0058] The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and determines the data packet pointer.

[0059] The GPU copy thread module sends the packet pointer information to the first virtual network function module on the network function service chain;

[0060] The virtual network function module sends the packet pointer information and GPU call request to the GPU scheduler to execute GPU operations. The virtual network function modules on the network function service chain process the packets and pass the packet pointer information in turn.

[0061] After the GPU call request in the network function service chain is completed, the GPU copy thread module copies the data packet processed by the GPU shared buffer to the data packet transceiver module and sends it out.

[0062] The GPU copy thread module receives a fixed number of data packets as a batch each time. Before copying the data packets into the GPU shared buffer, it divides a batch into blocks based on the average size of the current batch of data packets, and copies the data packets into the GPU shared buffer in blocks. At the same time, it records the data packet pointer information of each data packet in the GPU shared buffer.

[0063] Each virtual network module uses a batch size as the smallest unit for processing data.

[0064] After the data packet is processed by the network function service chain, the data packet forwarding module receives the pointer information of the data packet batch transmitted by the last virtual network function module. After all the batches of the block to which the data packet batch belongs have been received, the GPU copy thread module copies the data packet block together from the GPU shared buffer to the virtual network function module.

[0065] The following is a specific design example of this system:

[0066] In this embodiment, the GPU RX (GPU Data Receiver Module) is responsible for copying data packets to the GPU memory according to certain rules. The GPU RX module receives data packet descriptors from the network card transceiver module through 8 threads, with each thread receiving 128 descriptors at a time. In this embodiment, the number of data packets received by the GPU RX at one time, 128, is defined as a unit batch, serving as the smallest unit for system data transmission and reception, GPU data copying, and VNF data packet processing. When the GPU RX receives a unit batch of data, it parses each data packet descriptor to extract the data fields required by the VNF in the data packet, including the source IP address, destination IP address, source port, destination port, and data packet payload, and then caches them in a buffer.

[0067] During GPU RX initialization, by default, data packets are copied to the GPU in batches of one unit at a time. While receiving and parsing these batches, the average size of the data packets in that batch is calculated. This average size determines the number of batches copied to the GPU at once. In this embodiment, a batch copied to the GPU at one time is called a block. After one GPU copy, the number of batches in a block is reset, starting from the default value. In this embodiment, the average batch size S and the number of batches N in a block are related as follows: N = 2048 / S.

[0068] To ensure that the data packets copied back from the GPU are in the same order as those copied into the GPU, metadata such as the location of the first data packet in the GPU memory, its size, and its sequence number in the block are recorded during the parsing of unit batches. This metadata is used for processing in the final stage of the system.

[0069] Based on the number of GPU RX running threads, the GPU shared buffer is divided into an equal number of sub-regions, and the starting GPU address position of each sub-region is recorded. Based on the size of the data packets processed in each thread, the GPU address position of each data packet in the corresponding thread's GPU sub-region, offset by the data packet size, is recorded and stored in the data packet descriptor as the address position of that data packet in the GPU.

[0070] Each processed packet descriptor is flagged as NF_ACTION_TONF, indicating that the packet needs to be processed in subsequent steps. When the number of units in a block reaches a specified value, the GPU RX copies the data from the buffer to the corresponding sub-region in GPU memory and updates the GPU pointer position of the current thread's sub-region. Each thread's GPU sub-region is a circular buffer. After the GPU RX finishes copying, the packet descriptor is passed to the VNF through two circular queues for processing by the subsequent service chain. In this embodiment, the GPU RX inserts itself into the service chain based on the VNF's flag indicating that it has started using the GPU shared buffer; therefore, the GPU RX may start working from a position in the middle of the service chain.

[0071] After receiving the packet descriptor, the VNF preprocesses the data and sends a GPU execution request to the GPU execution process through the NF Request Ring. After waiting for the response from the NF Response Ring, it performs postprocessing on the data and then passes the packet descriptor to the next VNF.

[0072] After all VNFs on the service chain have processed their data, the packet descriptors are passed to the GPU TX module. In this embodiment, the module is divided into two types of threads: TX CPU threads and TX GPU threads. The TX CPU thread runs on an 8-way thread, receiving data from the service chain, receiving packet descriptors for one unit batch at a time and caching them. If GPU copying is performed on each received unit batch, the PCI-E transfer frequency will be too high, affecting the overall system performance. Therefore, in this embodiment, multiple unit batches of data in one block are transferred in a single PCI-E transfer, thereby improving PCI-E utilization. When the TXCPU thread receives a unit batch, it sends a GPU copy request to the TX GPU thread, which includes the metadata of the unit batch. The TX GPU thread marks the unit batch as COMPLETED and checks whether other unit batches under the block to which the unit batch belongs have also been marked as COMPLETED. If the check is successful, the block is copied to host memory, and the position of the data corresponding to each unit batch in host memory is recorded using offsets. A response is then sent to the corresponding TX CPU. Since all data within a block is contiguous in GPU memory, it can be ensured that all data copied to CPU memory is also contiguous. After receiving the response, the TX CPU thread performs post-processing and forwarding operations on the copied unit batch. In this embodiment, if data needs to be discarded, a discard flag is specified in the packet descriptor. The decision to discard data is made before forwarding through the network card, rather than discarding it within the service chain. This ensures that the data processed on the service chain is contiguous in GPU memory.

[0073] As attached Figure 2 As shown, all VNFs on the service chain share a single GPU shared buffer. GPU memory must be 2^n byte aligned, therefore, GPU memory allocation is performed to ensure 16-byte alignment. During the preprocessing phase, each VNF retrieves the GPU memory address (gpointer) stored in the GPU RX descriptor for each packet and copies it to GPU memory. When the Kernel function is executed on the GPU, each packet stored in the GPU shared buffer is obtained through the gpointer.

[0074] As attached Figure 1 As shown, the GPU execution process acts as an intermediary layer between the VNF and the GPU. It continuously polls a global VNF request queue to obtain requests from each VNF to execute the GPU, and performs the corresponding operation based on the type of request. In this embodiment, the main execution requests of the GPU execution proxy are as follows:

[0075] 1. REQ_HOST_MALLOC: Allocates memory space for locked pages on the host.

[0076] 2. REQ_GPU_MALLOC: Allocates memory space on the GPU.

[0077] 3. REQ_GPU_MEMCPY_HTOD_ASYNC: Asynchronously copies data from the host to the GPU.

[0078] 4. REQ_GPU_MEMCPY_DTOH_ASYNC: Asynchronously copies data from the GPU back to the host.

[0079] 5. REQ_GPU_LAUNCH_STREAM_ASYNC, asynchronously calls the kernel function on the GPU.

[0080] In addition to the requests mentioned above, there are also requests for VNF notification and synchronization. All VNFs are in the same CUDA context through the GPU call execution process. Each NF needs to send a GPU execution request to the GPU call execution process via the NF Request Ring. Each NF contains an NF Response Ring to obtain the GPU execution response. Each specific GPU execution step in the GPU call execution process is implemented using the CUDA Driver API, and after each execution, the time spent in the current execution is recorded through the CUDA stream callback function.

[0081] In the VNF execution pipeline, the execution steps of each VNF are abstracted into preprocessing, HtoD copy, Kernel function call, DtoH copy, and postprocessing. The preprocessing stage is responsible for resolving the pointer (gpointer) corresponding to each packet's location on the GPU. The postprocessing stage is responsible for updating the flag information for subsequent processing of the packet. HtoD copy mainly copies the GPU pointer (gpointer) from the packet descriptor to the GPU, while DtoH copy mainly copies the packet descriptor's flag information, such as the discard flag, back. These five VNF execution processes are abstracted into five interfaces: nf_preprocess, nf_htod_memcpy, nf_launch_kernel, nf_dtoh_memcpy, and nf_postprocessing. These five interfaces are implemented by the user according to the characteristics of each VNF. Each interface sends an execution request to the GPU execution process via the NF Request Ring and executes it. The algorithm for each VNF to be computed on the GPU needs to be written by the user in a .cu file, compiled into a .ptx file by nvcc, loaded into the system via cuModuleLoad, and then handed over to the GPU execution process for processing after being called by nf_launch_kernel.

[0082] As attached Figure 3 As shown, each VNF runs on two types of threads. One type of thread handles the preprocessing and post-processing stages of the VNF, running on the CPU; this is called the CPU-stage execution thread. The other type of thread handles H-to-D copying, Kernel calls, and D-to-H copying, running on the GPU; this is called the GPU-stage execution thread. These two types of threads constitute a VNF processing pipeline. The specific number of execution threads can be set by the user as needed. In this embodiment, each pipeline is executed by two threads.

[0083] Each VNF's processing pipeline contains three buffers. The current execution stage is determined by the state flag of each buffer. After completing the current execution stage, the state is updated to proceed to the next stage. The three buffers can simultaneously cover the preprocessing stage, GPU processing, and post-processing stage of the pipeline execution, thereby improving hardware utilization.

[0084] For heterogeneous service chains, a VNF runtime scheme generator and dynamic kernel functions are used to solve the data synchronization problem between CPU and GPU. In this embodiment, the system reads a predefined NFVs.json file, which specifies the number of VNFs in the service chain, the read / write data domain flags for each VNF, and the running device flag. Developers can use this file to define whether a VNF runs on the CPU or the GPU.

[0085] In this embodiment, all VNFs have three operating modes: CPU-based operation; GPU-based operation; and GPU-based operation in conjunction with a GPU shared buffer. The reason for further subdividing GPU devices is that some VNFs, such as routers, require less data copying when using only the GPU compared to when using the GPU shared buffer. The operation scheme generator encompasses these three modes using the VNF's data reading method, data writing method, and a flag indicating the use of the GPU shared buffer. There are two flags for VNF data reading: NEEDED and GPOINTER, indicating that the required data field is used directly at runtime and that a GPU pointer is used at runtime, respectively. There are also two flags for VNF data writing back: NEEDED and NONE, indicating that the required data field is written back and no data is written back, respectively. After permuting and combining the above definitions, it is easy to see that each VNF has four read / write operation modes. However, the mode where data reading is NEEDED and data writing back is NONE is incorrect because when data reading is NEEDED, the GPU shared buffer is not used. In this case, the data needs to be processed by the CPU or GPU before being copied and written back to the host memory. Therefore, each VNF has three operating modes:

[0086] 1. Read in data as NEEDED and write back data as NEEDED.

[0087] 2. Read in data as GPOINTER, write back data as NEEDED

[0088] 3. Read in data as GPOINTER and write back data as NONE.

[0089] For a given service chain, a ternary tree is generated based on the three operating modes described above. In this embodiment, Cost refers to the latency incurred by copying different data fields under a 1514-byte data packet. By pruning the generated ternary tree, we can obtain whether each VNF in the service chain uses the GPU shared buffer and the minimum overhead synchronization data field flag, thereby determining its optimal operating mode. Specifically, the pruning of the system mainly involves performing a depth-first search traversal of the tree to find the path with the minimum Cost from the root node to the leaf node, which is then used as the optimal operating scheme and output as a new JSON file.

[0090] In this embodiment, a dynamic kernel refers to a kernel that, based on the generated JSON file, enables the preprocessing, post-processing, and GPU execution kernel functions of each VNF to run in a specific mode. Specifically, the accompanying script in the execution scheme generator reads the JSON file and generates a specific header file that defines a series of define information indicating the execution method of each VNF. By recompiling each VNF, it enables it to run according to the mode specified in the JSON file.

[0091] The above embodiments are merely illustrative and do not constitute a limitation on the scope of the present invention. These embodiments can also be implemented in various other ways, and various omissions, substitutions, and modifications can be made without departing from the technical spirit of the present invention.

Claims

1. A network function virtualization system based on graphics processor acceleration optimization, characterized in that, The system includes: GPU shared buffer: allocated in GPU video memory; Network Function Service Chain: The network function service chain consists of multiple virtual network function modules. Each virtual network function module operates in one of the following three ways: Method 1: running using CPU; Method 2: running using GPU; Method 3: running using GPU and cooperating with GPU shared buffer. The system is designed with a multi-pipeline GPU scheduling mode; When a network function service chain includes at least two virtual network function modules with different operating modes, the network function service chain is called a heterogeneous network function service chain. The heterogeneous network function service chain performs data packet synchronization based on the heterogeneous service chain synchronization mechanism during operation. The heterogeneous service chain synchronization mechanism is as follows: An independent runtime plan generator is set up, which determines the running mode and specific running scheme of each virtual network function module based on the configuration of the network function service chain. The running scheme includes reading and writing data domains, synchronizing data domains, GPU shared buffer usage flags, and virtual network function algorithm input and output methods. The virtual network function modules obtain GPU kernel functions that satisfy the current running scheme based on their respective running schemes. When the virtual network function modules in the heterogeneous network function service chain run sequentially, the GPU kernel functions are executed to synchronize the data packets in the GPU shared buffer and CPU memory. The system operates as follows: The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and CPU memory. Each virtual network functional module operates based on a defined operating mode and specific operating plan. During operation, data packets are synchronized based on a heterogeneous service chain synchronization mechanism until the last virtual network functional module completes operation. The processed data packets are sent out through the data packet transceiver module.

2. The network function virtualization system based on graphics processor acceleration optimization according to claim 1, characterized in that, The system adopts a multi-process, multi-threaded hybrid programming model. Each virtual network function module and the network function virtualization system itself are treated as separate processes, and they interact with each other through lock-free queues and shared memory. Each virtual network function module adopts a multi-threaded programming mode.

3. A network function virtualization system based on graphics processor acceleration optimization according to claim 2, characterized in that, Each virtual network function module includes two types of threads: CPU stage processing thread: responsible for tasks including receiving, forwarding, preprocessing, and postprocessing data packets; GPU stage processing thread: responsible for sending specific GPU operation requests to the GPU call execution process.

4. A network function virtualization system based on graphics processor acceleration optimization according to claim 3, characterized in that, The CPU stage processing thread and the GPU stage processing thread use a three-buffer alternating processing method. The three buffers include a preprocessing buffer and a postprocessing buffer executed by the CPU stage processing thread, and a GPU processing buffer executed by the GPU stage processing thread.

5. A network function virtualization system based on graphics processor acceleration optimization according to claim 1, characterized in that, When all virtual network function modules in the network function service chain are operating in mode three, the specific operation method is as follows: The packet transceiver module receives data packets from external devices, and the GPU copy thread module copies the data packets to the GPU shared buffer and determines the data packet pointer. The GPU copy thread module sends the packet pointer information to the first virtual network function module on the network function service chain; The virtual network function module sends the packet pointer information and GPU call request to the GPU scheduler to execute GPU operations. The virtual network function modules on the network function service chain process the packets and pass the packet pointer information in turn. After the GPU call request in the network function service chain is completed, the GPU copy thread module copies the data packet processed by the GPU shared buffer to the data packet transceiver module and sends it out.

6. A network function virtualization system based on graphics processor acceleration optimization according to claim 5, characterized in that, The GPU copy thread module receives a fixed number of data packets as a batch each time. Before copying the data packets into the GPU shared buffer, it divides a batch into blocks based on the average size of the current batch of data packets, and copies the data packets into the GPU shared buffer in blocks. At the same time, it records the data packet pointer information of each data packet in the GPU shared buffer.

7. A network function virtualization system based on graphics processor acceleration optimization according to claim 6, characterized in that, Each virtual network module uses a batch size as the smallest unit for processing data.

8. A network function virtualization system based on graphics processor acceleration optimization according to claim 5, characterized in that, After the data packet is processed by the network function service chain, the data packet forwarding module receives the pointer information of the data packet batch transmitted by the last virtual network function module. After all the batches of the block to which the data packet batch belongs have been received, the GPU copy thread module copies the data packet block together from the GPU shared buffer to the virtual network function module.

Images